highaltitude.log.20090127

[00:00] <Laurenceb> what does that do?
[00:00] <hallam> :P
[00:01] <Laurenceb> correlates ?
[00:01] <hallam> I'm joking
[00:02] <Laurenceb> oh lol
[00:02] <hallam> but overall it is pretty good, and you can really tell that it's meant for DSP rather than just general processing
[00:04] <hallam> yeah with carrier aiding (which, if you set the IF to 0, automatically corrects for the wrong crystal effect) you can turn the DLL gain way down and get rid of a lot of code phase noise
[00:06] <Laurenceb> nice
[00:06] <Laurenceb> yeah I need to try this in matlab
[00:07] <Laurenceb> so turn ddl gain down then correct the prn clock using the carrier clock?
[00:07] <Laurenceb> ie prn_clock+=aiding_gain*(carrier_clock-prn_clock)
[00:07] <hallam> er
[00:07] <hallam> maybe
[00:08] <Laurenceb> or just have it equal?
[00:08] <hallam> prn_phase_rate = kdll*dll_disc + carrier_aid; %units: samples per millisecond
[00:08] <Laurenceb> with a correction based on the DLL discriminator
[00:08] <hallam> carrier_aid=-(((carrier_freq / (2*pi)))/1575.42E6)*Nsp;
[00:08] <Laurenceb> yeah
[00:08] <Laurenceb> ok
[00:08] <Laurenceb> right time to try it in matlab
[00:08] <Laurenceb> need to find a fast machine :P
[00:09] <hallam> if you go to 4MSps everything's faster
[00:09] <Laurenceb> I'll try 8 and see f I can improve the accuracy any more
[00:09] <Laurenceb> but 6m is really at the limit of gps anyway
[00:09] <hallam> right
[00:09] <hallam> hm
[00:10] <hallam> if we both take samples at the same time
[00:10] <hallam> we could do DGPS
[00:10] <Laurenceb> hehe
[00:10] <hallam> I was getting code phase standard deviation of 0.03 chips, about 10 meters
[00:10] <Laurenceb> wow
[00:11] <Laurenceb> matlab was giving ~150m
[00:11] <Laurenceb> well... on prn32
[00:11] <hallam> yeah that was on prn32
[00:11] <Laurenceb> amazing
[00:12] <Laurenceb> borre is pathetic
[00:12] <Laurenceb> :P
[00:12] <hallam> heh
[00:12] <hallam> my copy is sitting unopened in college
[00:12] <Laurenceb> where did you order from?
[00:12] <hallam> I might open it for the nav solution stuff, vector maths and linear algebra aren't my strong point
[00:12] <hallam> amazon
[00:13] <Laurenceb> yeah me too
[00:13] <hallam> 7 meters on prn11
[00:14] <Laurenceb> any idea how to setup X forwarding on my laptop?
[00:15] <hallam> windows?
[00:15] <hallam> xming
[00:15] <hallam> did you get the DVD I sent yet?
[00:15] <Laurenceb> no ubuntu
[00:15] <Laurenceb> ooh havent checked
[00:15] <Laurenceb> thanks
[00:15] <hallam> it should be there
[00:16] <Laurenceb> yeah
[00:16] <Laurenceb> I've been getting my icom working
[00:16] <hallam> but for forwarding on ubuntu, I think probably just ssh -X username@server
[00:16] <hallam> linux is not my forte though
[00:16] <Laurenceb> yeah, I was trying to workout how to connect to my machine
[00:16] <Laurenceb> remotely
[00:16] <hallam> oh
[00:16] <hallam> I'm not sure if there's anything more to it than that
[00:16] <Laurenceb> ok
[00:17] <Laurenceb> but if I set it up under windoze, you could use the sampler remotely
[00:17] <hallam> easy to try, just ssh -X somewhere else, then from there ssh -X back home
[00:17] <hallam> heh
[00:17] <Laurenceb> view from my window is poor
[00:18] <hallam> it's crazy that they save the files in that format
[00:18] <Laurenceb> yeah, 8 times the filesize
[00:18] <Laurenceb> should be possible to rewrite
[00:18] <hallam> I think there is different software available that works better
[00:19] <Laurenceb> oh?
[00:19] <Laurenceb> I looked but couldnt find anything
[00:21] <hallam> http://kom.aau.dk/project/softgps/frontEnd.php
[00:21] <hallam> I haven't tried it
[00:23] edmoore|away (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[00:23] <Laurenceb> thanks
[00:24] <hallam> don't know if it works with the version 2 sampler, but it was published fairly recently
[00:26] <Laurenceb> how do you adjust for crystal error?
[00:26] <Laurenceb> as the doppler will have an error interoduced by the local osc on the front end
[00:27] <hallam> the two effects cancel
[00:27] <Laurenceb> oh as the crystal is used for sampling?
[00:27] <hallam> yeah
[00:27] <hallam> if you wanted the true doppler you'd take (IF - carrier)/L1
[00:27] <Laurenceb> but the IF !=0
[00:28] <hallam> but by setting IF=0 you get a doppler that's much larger than the true doppler
[00:28] <Laurenceb> oh.... but 34.8KHz is theoretically correct?
[00:28] <Laurenceb> erm 38.4
[00:28] <Laurenceb> ok I kind of get it
[00:28] <hallam> by exactly the right amount to cancel the fact that you take 8184 samples per ms instead of 8183.9
[00:28] <hallam> on the IC the crystal is used both to create the LO and to drive the ADC sampling
[00:28] <Laurenceb> do I use doppler-38.4KHz ?
[00:28] <hallam> do it like the code I pasted
[00:29] <Laurenceb> so I dont?
[00:29] <hallam> no
[00:29] <hallam> you basically pretend you're using the chip as it was designed, with the correct crystal
[00:29] <Laurenceb> yeah I see why
[00:29] <hallam> except for acquisition
[00:30] <hallam> that's also nice because it means the code will work unchanged with the correct circuit
[00:35] <Laurenceb> I dont get it
[00:35] <Laurenceb> surely if the doppler=0, you need a prn clock still
[00:35] <Laurenceb> that code would give a prn clock of zero
[00:35] <hallam> right
[00:36] <Laurenceb> surely we need prn_clock=prn_clock_theoretical*(1+doppler/L1_carrier)
[00:36] <hallam> if you're not moving relative to the satellite, and your "milliseconds" are in sync with its
[00:36] <hallam> then the prn phase doesn't change
[00:36] <Laurenceb> prn_clock+=gain*discriminator
[00:36] <Laurenceb> whats wrong with that code?
[00:36] <hallam> oh, you have a 2nd order DLL?
[00:37] <Laurenceb> yes
[00:37] <hallam> you could try that
[00:37] <hallam> my 1st order one works beautifully with carrier aiding though
[00:37] <hallam> I experimented with a 2nd order one, without much success
[00:37] <Laurenceb> yeah I dont get it
[00:37] <hallam> ok
[00:37] <hallam> so
[00:37] <hallam> absent all sources of error
[00:38] <hallam> just the carrier aiding would be sufficient
[00:38] <hallam> right?
[00:38] <hallam> no DLL at all
[00:38] <Laurenceb> yes
[00:38] <hallam> so what my DLL does
[00:38] <hallam> it looks at the early - late correlation
[00:38] <hallam> if it seems that the signal is arriving early, it moves backward in time a small fraction of a chip
[00:38] <hallam> and vice versa
[00:39] <hallam> then I have
[00:39] <Laurenceb> prn_phase_rate = kdll*dll_disc + carrier_aid;
[00:39] <hallam> http://www.mibbit.com/pb/5rM5TD
[00:39] <Laurenceb> thats not what that does
[00:40] <Laurenceb> I think you've got the wrong end of the stick
[00:40] <hallam> the DLL doesn't try to establish a steady rate of change
[00:40] <Laurenceb> prn_phase_rate = kdll*dll_disc + carrier_aid; is second order
[00:40] <Laurenceb> ok
[00:40] <Laurenceb> well I think if it does its more stable
[00:40] <Laurenceb> oh hang on
[00:41] <Laurenceb> not if you use carrier aiding
[00:41] <hallam> right
[00:41] <hallam> systems with an integrator in are inherently less stable than those without
[00:41] <Laurenceb> hmm I'll see how it goes
[00:41] <Laurenceb> yeah
[00:43] <hallam> http://pastebin.com/d5d76c4a2 this is my tracking code at the moment, for reference
[00:45] <Laurenceb> ok
[00:45] <Laurenceb> just a sec need to try this
[00:53] <Laurenceb> so you use carrier frequencies, not dopplers?
[00:53] <hallam> wellll
[00:53] <hallam> if the IF is zero, they're the same thing
[00:53] <hallam> right?
[00:54] <Laurenceb> yeah
[00:54] <Laurenceb> and whats your gain from the discrimunator?
[00:54] <Laurenceb> DLL disc
[00:54] <hallam> top of the file, 6E-4 I think
[00:55] <Laurenceb> prn_phase_rate = kdll*dll_disc + carrier_aid;
[00:55] <hallam> it used to have to be about ten times that without the aiding
[00:55] <Laurenceb> aha
[00:55] <Laurenceb> ok
[00:57] <Laurenceb> codeNco=-carrFreq*1.023E6/1575.42E6 + DLLdisc*6E-4;
[00:58] <Laurenceb> codeFreq=1.023E6-codeNco;
[00:58] <Laurenceb> is what I'm using
[00:58] <hallam> what's your DLL discriminator?
[00:58] <hallam> and what does codeFreq do
[01:00] <Laurenceb> codeFreq is the code clock frequency
[01:00] <Laurenceb> DLL discriminator is a decoherent one
[01:00] <Laurenceb> based on abs of early, prompt and late
[01:00] <hallam> ok
[01:01] <hallam> I don't totally follow how your NCO works
[01:01] <hallam> but did you try it?
[01:01] <Laurenceb> yes
[01:01] <Laurenceb> it doesnt work
[01:02] <hallam> the gain might not work with your disc
[01:03] <Laurenceb> yeah I was going to say
[01:03] <Laurenceb> need to be about 1
[01:03] <Laurenceb> maybe a bit more
[01:04] <Laurenceb> I'll try 1
[01:05] <Laurenceb> discriminator gives an output of +-1
[01:05] <Laurenceb> *in range of
[01:05] <hallam> ok
[01:06] <Laurenceb> so the maximum possible frequency alteration is 1 chip/sec
[01:06] <Laurenceb> whic sounds sensible
[01:07] <Laurenceb> maybe a few times greater would be good
[01:10] <Laurenceb> still doesnt work
[01:10] <Laurenceb> interestingly it stays 1 chip out of phase for 0.05 seconds
[01:10] <Laurenceb> no 1/2 chips out
[01:13] <hallam> sounds like what you'd get with aiding but no DLl at all
[01:16] <Laurenceb> I'll try increasing the gain to 10
[01:16] <hallam> be careful
[01:16] <hallam> you might rip a hole in the space-time continuum
[01:24] <Laurenceb> oops
[01:24] <Laurenceb> think the gain has the wrong sign
[01:24] <Laurenceb> durrrrrrrr
[01:26] <hallam> fail
[01:26] <hallam> don't you just hate it when that happens
[01:27] <Laurenceb> hehe
[01:28] <hallam> I bet you can make the carrier aiding even better by filtering the carrier frequency first
[01:30] <hallam> How do you think I can simulate high acceleration to make sure the PLL tracks?
[01:31] <hallam> maybe add a term to the carrier NCO?
[01:31] <Laurenceb> maybe
[01:31] <hallam> that won't simulate the vibration fucking the crystal, but still
[01:31] <Laurenceb> I think a combined gps and imu is going to have to be quite different
[01:31] <Laurenceb> in tracking loop design
[01:32] <hallam> hm, I'm not sure
[01:32] <Laurenceb> yeah
[01:32] <hallam> I don't think it would have to be too different
[01:32] <Laurenceb> the early-late business limits things quite a bit
[01:32] <hallam> I think you'd just add terms like I did for carrier aiding
[01:32] <Laurenceb> decoherent tracking would be nice
[01:32] <Laurenceb> yeah maybe
[01:32] <hallam> well you can actually do decoherent with e-l
[01:33] <hallam> let me find the paper
[01:33] <Laurenceb> but it would be nice to be able to stick the bins straight into the kalman filter
[01:33] <Laurenceb> hmm if you find the angle of prompt and rotate?
[01:33] <hallam> http://www.novatel.com/Documents/Papers/File2.pdf page 4
[01:33] <Laurenceb> ahh novatel
[01:33] <hallam> ?
[01:34] <Laurenceb> we use their receivers to check antennas
[01:34] <Laurenceb> they have 50Hz modules
[01:35] <hallam> nice
[01:36] <hallam> that is quite rapid
[01:37] <Laurenceb> yeah, guess once every nav bit
[01:38] <hallam> I'd like to try some RTK stuff
[01:40] <Laurenceb> theres always dithered
[02:16] <Laurenceb> hallam: I dint get why but I have to take out the 38.4Khz to make it work
[02:16] <Laurenceb> it seems to be tracking very well now, even on 32
[02:16] <Laurenceb> but only without the 38.4Khz
[02:17] <Laurenceb> which should surely remain in if its a crystal error
[02:26] <Laurenceb> lol http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2009/1/26/1232934694312/26.01.09-Martin-Rowson-on-001.jpg
[02:50] <fergusnoble> hallam: whats the gps progress?
[02:51] <Laurenceb> hallam: its about 50m out
[02:51] <Laurenceb> I think theres an issue with it still
[02:55] <Laurenceb> yeah theres a residual range error of ~30m
[02:56] <Laurenceb> from the DLL - obviously the estimate from the carrier is incorrect
[03:12] <Laurenceb> oh sampling frequency has changed
[04:03] <hallam> hey
[04:03] <hallam> sorry, yeah, that's the whole point
[04:03] <hallam> Laurenceb / fergusnoble : C tracker works!!!
[04:03] <fergusnoble> oh bloody great!
[04:03] <Laurenceb> nice
[04:03] <fergusnoble> with all the fancy carrier stuff?
[04:04] <Laurenceb> so its getting data bits?
[04:04] <hallam> yes
[04:04] <Laurenceb> and its doing 010101 fudging?
[04:04] <hallam> only in the early-late PRN, which I've been doing for ages in matlab anyway
[04:04] <Laurenceb> and carrier lookup
[04:05] <Laurenceb> from 4 samples of a squarewave?
[04:05] <hallam> the carrier generation is still naive
[04:05] <hallam> but it does put it into interleaved chunks
[04:05] <Laurenceb> ok
[04:05] <hallam> all the processing is done interleaved
[04:05] <Laurenceb> are you doing the techniuqe for reading 32 bit words?
[04:05] <Laurenceb> ie. shifting two words to interleave
[04:06] <hallam> yes
[04:06] <Laurenceb> nice :P
[04:06] <hallam> er
[04:06] <hallam> hang on, what do you mean?
[04:06] <hallam> btw you are both very bad for staying up so late
[04:06] <Laurenceb> so you have 16 samples in a word
[04:07] <hallam> yeah
[04:07] <Laurenceb> hehe
[04:07] <Laurenceb> and you want to be able to shift one sample along
[04:07] <hallam> oh right
[04:07] <hallam> the Fergus metho
[04:07] <hallam> d
[04:07] <Laurenceb> not 16 at a tine
[04:07] <hallam> yeah
[04:07] <hallam> it uses that
[04:07] <Laurenceb> hehe sounds like some theorem
[04:07] <Laurenceb> cool
[04:10] Action: Laurenceb still cant get his code to work
[04:10] <hallam> :(
[04:10] <hallam> which code is that?
[04:11] <Laurenceb> codeNc0=carrFreq/1540 -codeError
[04:11] <Laurenceb> codeFreq=1.023E6+codeNco
[04:12] <Laurenceb> its off by 38.4Khz
[04:12] <hallam> is this a modified version of Borres?
[04:12] <Laurenceb> if I subtract that from carrFreq, it works, but the ranges are off by 50m
[04:12] <Laurenceb> yes
[04:12] <Laurenceb> 50m corresponds to about20Hz error on carrFreq
[04:12] <hallam> is he already compensating somewhere for the fact that the sample rate isn't an integer multiple of the PRN chiprate?
[04:12] <Laurenceb> which sounds sensible for crystal error
[04:13] <Laurenceb> well all I can find is a few lines at the top to convert the carrr freq and prn freq using sample rate
[04:13] <Laurenceb> but sample rate will be in error with everything else
[04:13] <Laurenceb> so it should work
[04:14] <Laurenceb> crystal error just leads to a doppler on everything
[04:16] <hallam> well
[04:17] <hallam> the crystal does two things
[04:17] <hallam> it provides the L1 oscillator
[04:17] <hallam> it also drives the sampling clock
[04:17] <hallam> the first of those leads to doppler
[04:18] <hallam> the second leads to something like doppler, but on the code phase
[04:18] <Laurenceb> yes, hence why you correct the code clock
[04:18] <hallam> I think maybe you're correcting it twice
[04:18] <Laurenceb> where?
[04:19] <hallam> either correct it once and use the true doppler for carrier aiding (IF-carrier), or don't correct it and use the apparent doppler for carrier aiding (0-carrier)
[04:19] <hallam> I'm doing the second method
[04:19] <Laurenceb> oh
[04:20] <hallam> of course I haven't tried finding nav solutions yet
[04:20] <hallam> but I don't think it should cause a problem
[04:20] <Laurenceb> but a zero doppler sat will generate nothing for carrier aiding
[04:20] <Laurenceb> which is incorrect
[04:20] <Laurenceb> as the crystal error will effect the sampling rate
[04:20] <Laurenceb> oh 0-carrier
[04:21] <hallam> with my method
[04:21] <hallam> a sat that has zero true doppler (zero true range rate)
[04:21] <hallam> will have an apparent doppler of 38kHz
[04:21] <Laurenceb> got you
[04:21] <Laurenceb> maybe thats not the case with this code - I thought it was
[04:21] <Laurenceb> but yeah your method is what I was trying to do
[04:22] <hallam> wow SV32 is so weak at the end
[04:22] <Laurenceb> I guess it must have been multipath
[04:23] <Laurenceb> and very sensitive to sat position
[04:23] <Laurenceb> bouncing through the building or something
[04:24] <Laurenceb> I have it constant for the first 10 or maybe 15 seconds
[04:27] <hallam> I can track it to the end, but only just
[04:27] <hallam> the smoothed absolute value of the prompt correlation is only about 20% more than what you get for noise
[04:29] <Laurenceb> its about twice as much with the code here
[04:29] <hallam> even at the end?
[04:29] <Laurenceb> yes
[04:29] <hallam> hmm
[04:29] <Laurenceb> at the beginning its about as strong as the others
[04:30] <hallam> okay yeah I was using too high a value for the noise floor
[04:30] <hallam> but it's still pretty damn weak
[04:30] <Laurenceb> yeah, lots of the individual samples are flipped
[04:31] <Laurenceb> but if you average 20 samples for each data bit the data should come out fine
[04:32] <hallam> I do
[04:32] <hallam> now here's something weird
[04:32] <hallam> I had t
[04:32] <hallam> I had to put a DLL in my nav bit filter
[04:33] <hallam> for 3 of the sats, one of the nav bits in the middle of the data was only 19 PRNs long
[04:33] <hallam> not at the same time or anything
[04:33] <hallam> I'm really stumped about that one
[04:34] <Laurenceb> maybe something lost lock
[04:34] <Laurenceb> no
[04:34] <Laurenceb> you could never chuck that many samples
[04:35] <Laurenceb> we are using the right code?
[04:35] <Laurenceb> do your samples switch straing from 1 to -1 at the nav bits?
[04:35] <Laurenceb> *straight
[04:36] <hallam> it's pretty clear
[04:36] <hallam> hang on I'll get a screenshot
[04:43] <Laurenceb> my DLL is very noisy
[04:43] <Laurenceb> how much noise was there on the 1ms DLL outputs?
[04:43] <Laurenceb> with carrier aiding?
[05:07] <hallam> very little I think
[05:07] <hallam> because I had the gain so low, it couldn't be large
[05:08] <hallam> anyway about that nav bit going out of sync thing, it seems to have fixed itself
[05:09] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) got netsplit.
[05:11] zeusbot_ joined #highaltitude.
[05:12] Nick change: zeusbot_ -> zeusbot
[05:12] smealum (n=smealum@smea.servebeer.com) got netsplit.
[05:12] epictetus (n=pattm@static-71-174-73-53.bstnma.fios.verizon.net) got netsplit.
[05:12] epictetus (n=pattm@71.174.73.53) joined #highaltitude.
[05:12] smealum (n=smealum@smea.servebeer.com) returned to #highaltitude.
[05:13] SpeedEvil (n=jfkjdjkf@tor/regular/SpeedEvil) got netsplit.
[05:13] smealum (n=smealum@smea.servebeer.com) got netsplit.
[05:13] gordonjcp (n=gordonjc@symmetria.fi) got netsplit.
[05:13] jiffe97 (n=jiffe2@209.159.247.189) got netsplit.
[05:13] dh (i=dh@bsd.ee) got netsplit.
[05:13] gordonjcp (n=gordonjc@81.19.112.24) joined #highaltitude.
[05:13] dh__ (i=dh@bsd.ee) joined #highaltitude.
[05:14] jiffe97 (n=jiffe2@209.159.247.189) returned to #highaltitude.
[05:14] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) got netsplit.
[05:15] jiffe97 (n=jiffe2@209.159.247.189) got netsplit.
[05:15] epictetus (n=pattm@71.174.73.53) got netsplit.
[05:15] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) returned to #highaltitude.
[05:16] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) got netsplit.
[05:16] Ebola (i=ebola@unaffiliated/ebola) got netsplit.
[05:16] jiffe97 (n=jiffe2@209.159.247.189) returned to #highaltitude.
[05:16] smealum (n=smealum@smea.servebeer.com) returned to #highaltitude.
[05:16] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) returned to #highaltitude.
[05:17] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-7c44751c262f9479) got netsplit.
[05:21] Ebola (i=ebola@goatse.co.uk) joined #highaltitude.
[05:21] Nick change: Ebola -> Guest86755
[05:24] SpeedEvil (n=jfkjdjkf@tor/regular/SpeedEvil) got lost in the net-split.
[05:24] dh (i=dh@bsd.ee) got lost in the net-split.
[05:26] epictetus (n=pattm@71.174.73.53) got lost in the net-split.
[05:30] zeusbot joined #highaltitude.
[05:30] #highaltitude: mode change '+ns ' by zelazny.freenode.net
[05:31] #highaltitude: mode change '-s+tc ' by ChanServ!ChanServ@services.
[05:31] -:#highaltitude- *** Notice -- TS for #highaltitude changed from 1233034233 to 1233034128
[05:31] #highaltitude: mode change '+s-tc ' by irc.freenode.net
[05:31] jiffe88 (n=jiffe2@209.159.247.189) joined #highaltitude.
[05:31] Tiger^ (i=tygrys@moo.pl) joined #highaltitude.
[05:31] smealum (n=smealum@smea.servebeer.com) joined #highaltitude.
[05:31] #highaltitude: mode change '-s+tc ' by ChanServ!ChanServ@services.
[05:32] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) joined #highaltitude.
[05:37] epictetus (n=pattm@static-71-174-73-53.bstnma.fios.verizon.net) joined #highaltitude.
[05:39] dh_ (i=dh@bsd.ee) joined #highaltitude.
[05:39] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/session) joined #highaltitude.
[05:40] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[05:41] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) joined #highaltitude.
[05:42] gordonjcp (n=gordonjc@symmetria.fi) joined #highaltitude.
[05:42] borism (n=boris@195-50-211-250-dsl.krw.estpak.ee) joined #highaltitude.
[05:43] <Laurenceb> hallam: I fixed the problem
[05:44] <Laurenceb> there were some settings in the settings file to change
[05:44] Ebola (i=ebola@goatse.co.uk) joined #highaltitude.
[05:44] <Laurenceb> PRN32 is about 150% stronger
[05:44] <Laurenceb> so it looks good
[05:44] Nick change: Ebola -> Guest43341
[05:44] <Laurenceb> 32 is way above the noise now
[05:45] <Laurenceb> just doing a position solution now
[05:45] <Laurenceb> this is all 1 bit btw
[05:45] <hallam> what were the settigns?
[05:45] <hallam> also, grr
[05:45] <Laurenceb> the clock frequency
[05:45] <hallam> that cacode function in C doesn't work
[05:45] <Laurenceb> has to be the theoretic value
[05:45] <Laurenceb> I know
[05:45] <hallam> ok
[05:45] <Laurenceb> I couldnt fix it
[05:45] <hallam> it works for some of the PRNs
[05:46] <hallam> but not all
[05:46] <hallam> wtf
[05:46] <Laurenceb> you have to setup the right sat
[05:46] <Laurenceb> oh
[05:46] <Laurenceb> whatttt
[05:46] <Laurenceb> check the lookup table against the matlab
[05:46] <Laurenceb> but I'm sure I checked it...
[05:47] <Laurenceb> let me know what the problem was if you find it
[05:47] <hallam> will do
[05:55] <hallam> table's right
[06:01] <Laurenceb> altitude=5m off street level
[06:04] <Laurenceb> http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=%4052.20208311,0.1181777778&sll=52.200926,0.119305&sspn=0.011889,0.038624&ie=UTF8&ll=52.202073,0.11821&spn=0.000186,0.000603&t=h&z=21&iwloc=addr
[06:04] <Laurenceb> about 4m out accounting for building scew
[06:06] <Laurenceb> the standard deviation is about 50m for the 1ms position fixes
[06:06] <Laurenceb> but its a distorted disc
[06:07] <Laurenceb> with a better geometery and more sats it should be down to 10m or less
[06:11] <Laurenceb> not bad at all
[06:11] Action: Laurenceb drops a smart bomb on hallam
[06:11] <hallam> please, put me out of my misery
[06:12] <hallam> I totally don't get wtf is wrong with the PRN generation
[06:12] <Laurenceb> yeah I spent quite a while on it
[06:12] <Laurenceb> and coundnt see anything
[06:13] <Laurenceb> sv--; should account for the mismatch between array indexes in c and matlab
[06:13] <Laurenceb> but you need to put in sv=sv-2;
[06:13] <Laurenceb> sv-=2;
[06:13] <Laurenceb> to make it work
[06:13] <Laurenceb> I'm sure the lookup table was just copied and pasted
[06:14] <hallam> I checked the lookup table, it's right
[06:14] <hallam> sv-=2 works for 11, 13 and 32
[06:14] <hallam> but not 23
[06:15] <hallam> for which there doesn't seem to be any value that works
[06:15] <Laurenceb> very odd
[06:15] <Laurenceb> maybe some peculiarity to the way the registers are setup
[06:19] <hallam> ah fuck it I'll hard-code them
[06:20] <Laurenceb> hehe
[06:20] <Laurenceb> this is odd: position solution are jumping between seperate descreet points
[06:20] <Laurenceb> that are shifting as a function of time
[06:22] <Laurenceb> it doesnt appear to have a periodicity related to the nav data or anything
[06:23] <Laurenceb> maybe the newton raphson implementation is a bit screwy
[06:23] <Laurenceb> its almost as if the position solver is oscillating
[06:27] <Laurenceb> yeah looks like it is
[06:27] <hallam> what would cause that?
[06:27] <hallam> just a shitty solver?
[06:27] <Laurenceb> the noise - excursions from the oscillation - is really small
[06:27] <Laurenceb> certainly less that 1meter standard dev
[06:27] <Laurenceb> perobably cm
[06:28] <Laurenceb> I'm not sure
[06:28] <Laurenceb> it was stable before
[06:28] <Laurenceb> but I havent tried running it at lower speeds with the carrier aiding
[06:29] <Laurenceb> but it could have been doing something similar before at 1Khz - it would have been hidden in the noise then
[06:29] <Laurenceb> oscillation is +-50m
[06:29] <Laurenceb> noise before was +-100m
[06:30] <Laurenceb> the solver generates a huge stream of errors at 1Khz, but it doesnt diverge
[06:33] <Laurenceb> we need a small box with blackfin board + power + hacked sige sampler + lcd on the front
[06:33] <Laurenceb> :D
[06:36] <Laurenceb> need to replace it with a kalman filter
[06:36] <Laurenceb> then you can do other cool things like input pseudorange noise based on amplitude for example
[06:37] <Laurenceb> and instead of DOP you'll have realistic errors on position
[06:37] <Laurenceb> (excluding ionosphere)
[06:38] <hallam> you've gone a bit over my head I'm afraid
[06:38] <hallam> just doing some fake acceleration, it can take a few tens of g okay
[06:38] <Laurenceb> newton raphson is kind of like a simplified extended kalman
[06:38] <Laurenceb> how are you simulating?
[06:38] <hallam> carrier_freq = carrier_freq + fake_accel_doppler;
[06:39] <hallam> (after it's already been incremented by the results of the PLL)
[06:39] <Laurenceb> right
[06:39] <hallam> hmm it doesn't like more than about 20g
[06:39] <Laurenceb> odd
[06:39] <Laurenceb> it shouldnt be that stable
[06:40] <Laurenceb> 1G gives a doppler shift of about 50Hz/sec right?
[06:41] <hallam> yes
[06:42] <hallam> SV11 deals with it better
[06:42] <Laurenceb> hmm guess its a function of pull in time
[06:42] <Laurenceb> yes, just looking at my plots
[06:42] <hallam> I was trying on 32
[06:42] <Laurenceb> try 13
[06:43] <Laurenceb> hmm damping ratio gets important here I think
[06:44] <hallam> more PLL gain does the trick
[06:44] <Laurenceb> I'd imagine that the max g goes with noise_bandwidth^2
[06:45] <hallam> but I left the noise bandwidth at 25Hz
[06:45] <hallam> according to calcLoopCoeffs
[06:45] <Laurenceb> odd
[06:45] <Laurenceb> I think there are only really two defining coefficients
[06:46] <hallam> yeah
[06:46] <hallam> I think maybe calcLoopCoeffs is full of shit
[06:46] <Laurenceb> the notes here look at behaviour with gain at 1 as I understand it
[06:46] <Laurenceb> damping ratio is odd
[06:47] <hallam> e.g. the actual gain is the reciprocal of what you give to calcLoopCoeffs as the gain
[06:47] <Laurenceb> smaller damping ratio kind of makes it more twitchy
[06:47] <hallam> it seems with a bit more gain, SV11 can cope with 100g
[06:47] <Laurenceb> lol
[06:47] <hallam> but I haven't had any luck with 32 at more than 10g
[06:47] <hallam> the rocket will be 50, so it's kind of important
[06:47] <Laurenceb> gps guided tank shells
[06:48] <Laurenceb> they do exist
[06:48] <hallam> yeah but they probably don't keep a lock during ignition
[06:48] <Laurenceb> no
[06:48] <hallam> if nothing else, the barrel would block the signal
[06:48] <Laurenceb> they are loaded just before firing
[06:48] <Laurenceb> from a handheald unit
[06:49] <Laurenceb> I saw it on tv
[06:49] <Laurenceb> the guy who wrote the detonation firmware had to activate it
[06:49] <Laurenceb> while everyone else stood a few hundered meters back :P
[06:50] <Laurenceb> they could have been joking - it was the discovery channel
[06:50] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[06:50] <hallam> heh
[06:50] <hallam> hwo do they actuate?
[06:51] <hallam> hi Simon-MPFH
[06:51] <Laurenceb> there are spring loaded fins on the back
[06:51] <Laurenceb> but they didnt really let us see that bit
[06:51] <Laurenceb> only the tronics
[06:52] <hallam> sweet, got SV32 to cope with 50g
[06:52] <Laurenceb> wow
[06:52] <hallam> eh, for 15 seconds anyway
[06:52] <Laurenceb> yeah I didnt realise - max g goes with noise bandwidth ^2
[06:54] <hallam> I guess I should stop procrastinating and get the nav solution working
[06:54] <Laurenceb> noise bandwidth of 30Hz should give up to 50Hz
[06:54] <Laurenceb> erm g
[06:55] <Laurenceb> daming ration its a question of setting time and overshoot
[06:55] <Laurenceb> *damping
[06:55] <hallam> it could easily be accelerometer-aided though
[06:55] <Laurenceb> you want a low overshoot for high g
[06:56] <Laurenceb> which results in larger settling time
[06:56] <Laurenceb> and a high damping ratio
[06:56] <Laurenceb> yeah
[06:56] <Laurenceb> ideally it would all be part of the same kalman filter
[06:56] <Laurenceb> but I'm not sure if thats possible
[06:57] <Laurenceb> so bins in and position, velocity and new nco for carrier and phase out
[06:57] <hallam> even if the accelerometer only tells it to within a couple of g, that's more than enough
[06:57] <Laurenceb> yeah
[06:57] <Laurenceb> I was just thinking really really optimal
[06:57] <hallam> sure
[06:57] <Laurenceb> but its not really needed
[06:58] <Laurenceb> you can get such good data with gps
[06:58] <hallam> am I right in thinking that with carrier aiding, if the PLL works then the DLL will too? (under high g)
[06:58] <Laurenceb> yes
[06:58] <hallam> nice
[06:59] <hallam> I think some of the crystal-getting-squashed effects should cancel for the same reason that the wrong-crystal effects do
[06:59] <Laurenceb> yeah
[06:59] Action: hallam wonders if the mystery of cacode.c will ever be solved
[06:59] <hallam> it's a lookup table now
[07:00] <Laurenceb> hehe thats the way to go
[07:00] <Laurenceb> its going to have to be anyway at some point
[07:00] <hallam> I really ought to at least pack it so it's better than 1 bit per byte
[07:00] <hallam> but flash is cheap
[07:01] <Laurenceb> I'm thinking keep the dll and pll, then input pseudorange and amplitudes into a kalman filter
[07:01] <Laurenceb> maybe use accels to correct the pll
[07:02] <Laurenceb> should be insanely good
[07:02] <Laurenceb> basically just ionospheric error
[07:02] <Laurenceb> theres tropospheric correction in here
[07:02] <Laurenceb> might want to have some correction scaling with altitude
[07:02] <hallam> heh
[07:03] <hallam> "in order to solve the ionospheric error problem, we will only operate above the ionosphere"
[07:03] <Laurenceb> its only a meter or so
[07:03] <Laurenceb> - troposphere
[07:03] <Laurenceb> hey what happened to the stratosphere
[07:03] <hallam> no error there
[07:03] <Laurenceb> hmmm its air
[07:03] <Laurenceb> therfore an error
[07:04] <hallam> I guess it's not dense enough to have troposphere-like effects, but also not full of ions and shit like the ionosphere is
[07:04] <Laurenceb> yeah maybe
[07:05] <Laurenceb> well it already beats sirf2 no problems
[07:05] <hallam> heh
[07:06] <hallam> those suckers with their 200mW processor in a receiver the size of a postage stamp
[07:07] <Laurenceb> how much power is a blackfin?
[07:08] <hallam> eh, half a watt or so
[07:08] <hallam> depends on what it's doing (SDRAM etc)
[07:08] <hallam> not crippling but it's not the most efficient chip on the planet
[07:09] <Laurenceb> yeah
[07:09] <Laurenceb> thats only 200ma or so
[07:10] <hallam> yeah, actually less than that a lot of the time
[07:11] <hallam> I think I was measuring around 120mA average at 3.3V
[07:12] <Laurenceb> same oas a sirf2
[07:12] <hallam> we don't know for sure that it can run on a blackfin yet
[07:12] <hallam> oh I guess I should come up with a better way to generate the carrier
[07:12] <Laurenceb> hehe sure it will
[07:12] <Laurenceb> yeah
[07:12] <Laurenceb> use the 4 lookup technique
[07:12] <Laurenceb> with the u16 pointer
[07:13] <Laurenceb> thats shifted then the 2 msb used
[07:13] <Laurenceb> u16 carrierphase
[07:13] <Laurenceb> carrierphase+=carrierfreq;
[07:13] <hallam> and ignore the transition thing?
[07:13] <Laurenceb> yeah
[07:14] <hallam> ok I'll see how it goes
[07:14] <Laurenceb> shouldnt make a big difference
[07:19] <Laurenceb> for the solution, id try a 4 conponent state vector extended kalman filter
[07:20] <Laurenceb> or maybe 6 state
[07:20] <Laurenceb> x,y,z,u,v,w,delta_time
[07:20] <Laurenceb> piss easy to integrate into an imu later
[07:26] <Laurenceb> so measurement space is pseudoranges
[07:27] <hallam> ok
[07:27] <hallam> I think I can work out how to calculate the pseudorange
[07:27] <Laurenceb> 68ms is the standard to set for the closest sat
[07:27] <Laurenceb> rather than time in the filter, probably better to have clock rate offset
[07:28] <Laurenceb> i.e. crystal drift
[07:28] <hallam> don't understand
[07:28] <Laurenceb> which would probably mean newton raphson first
[07:28] <Laurenceb> then initialise the kalman filter
[07:28] <hallam> maybe I'll look at Borres
[07:28] <Laurenceb> yeah
[07:28] <Laurenceb> do you have the code?
[07:28] <Laurenceb> basically you set the closest sat to 68ms
[07:29] <Laurenceb> then find pseudoranges
[07:29] <Laurenceb> then newton raphson
[07:30] <hallam> yeah I have the code
[07:31] <hallam> jumping jesus on a pogo stick
[07:31] <hallam> it's a little bit fast
[07:31] <Laurenceb> according to borre, standard deviation for single frequency is 4.6m on pseudorange
[07:31] <Laurenceb> fast ?!
[07:32] <hallam> 80* realtime per channel
[07:32] <Laurenceb> wtf
[07:32] <Laurenceb> not here it aint
[07:32] <hallam> no, my C tracker
[07:32] <Laurenceb> oh
[07:32] <Laurenceb> awsomeness
[07:32] <hallam> now that I've got rid of floating point operations in the tight loop
[07:32] <hallam> yeah
[07:32] <hallam> you were right, transitions don't seem to be important
[07:33] <Laurenceb> so with that sat configuration you are looking at 4 meters error or so
[07:33] <Laurenceb> nice
[07:33] <Laurenceb> as 32 is the only one behind you, and its so noisy
[07:33] <hallam> it takes about 10 times as long to load the results back into matlab as it does to calculate them
[07:33] <Laurenceb> haha
[07:33] <hallam> wait, it's nto actually behind me, is it?
[07:33] <Laurenceb> well almost
[07:33] <Laurenceb> you are really relying on 32 to get a position
[07:34] <Laurenceb> the others are in front of you more or less
[07:34] <hallam> is that a problem?
[07:34] <Laurenceb> yeah, you weant them spread about the sky
[07:34] <hallam> as long as they're spread out a bit, shouldn't it be ok if they're all in the same hemisphere?
[07:34] <hallam> well, 1/4 sphere I guess
[07:34] <Laurenceb> yeah, but not as good
[07:35] <Laurenceb> errors are amplified
[07:35] <hallam> ok
[07:35] <Laurenceb> so considering 4.6m on pseudorange, 4m error is very good
[07:35] <hallam> right
[07:35] <Laurenceb> you've on the 3rd floor?
[07:35] <hallam> yes
[07:35] <hallam> hehe
[07:35] <Laurenceb> windowsill ~5moff the road?
[07:35] <hallam> it's pretty much overhanging the pavement
[07:36] <hallam> maybe 1-2m
[07:36] <hallam> off the road
[07:36] <Laurenceb> vertically
[07:36] <hallam> oh right
[07:36] <hallam> yeah
[07:36] <hallam> bit more, perhaps
[07:36] <hallam> but about that
[07:36] <hallam> I'll go take more data at some well-defined places visible on google maps today
[07:36] <Laurenceb> ok somewhere in the region of 4m 3D error
[07:40] <Laurenceb> google maps used to be out by 100m or more in places
[07:40] <Laurenceb> but they seem to have really improved it - <1m probably now
[07:41] <hallam> 100m is pretty poor
[07:43] <Laurenceb> yeah, that was when it first went online
[07:48] <hallam> so it looks like I'm getting about 29MHz per channel CPU usage on my machine
[07:48] <hallam> I think it might just work on the blackfin\
[07:48] <hallam> or hell, even an ARM
[07:49] <Laurenceb> neat
[07:49] <Laurenceb> yeah, its not even optimised
[07:49] <Laurenceb> and the replica functions will be inefficient
[07:50] <hallam> replica?
[07:50] <hallam> COUNTONES is pretty efficient
[07:50] <hallam> not single-cycle, but only 4 or so
[07:50] <hallam> #define COUNTONES(v) (v -= ((v >> 1) & 0x55555555), v = (v & 0x33333333) + ((v >> 2) & 0x33333333),(((v + (v >> 4)) & 0xF0F0F0F) * 0x1010101) >> 24)
[07:50] <hallam> magic
[07:54] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[07:54] <Laurenceb> whats with the , ?
[07:54] <rjharrison> moring all
[07:54] <Laurenceb> hi
[07:54] <rjharrison> you get the idea
[07:54] <rjharrison> Hi Laurenceb
[07:55] <rjharrison> morning hallam, I assume that it was you Laurenceb was talking too
[07:55] <hallam> hullo
[07:55] <rjharrison> You haven't been up all night again playing GPS have you
[07:56] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[07:56] <Laurenceb> you can sleep when your dead
[07:56] <rjharrison> lol
[07:56] <rjharrison> morning edmoore
[07:56] <edmoore> yo
[07:56] <edmoore> it be too early
[07:56] <edmoore> off to breakfast
[07:56] <rjharrison> edmoore Will you be using your eee with the radio for tracking in the future?
[07:56] <edmoore> talk later
[07:56] <hallam> edmoore: C GPS is working really well
[07:56] <hallam> like, massively fast
[07:56] <edmoore> hallam: ok awesome. will need the run-down son
[07:57] <hallam> definitely doable on the blackfin
[07:57] <edmoore> rjharrison: yes
[07:57] <rjharrison> Is that C as in the language?
[07:57] <hallam> yes
[07:57] <edmoore> the significant bit is that it's in software, rather than specifically C :)
[07:57] <Laurenceb> hallam: wtf is with that countones code?
[07:57] <rjharrison> edmoore, cool will chat b4 next launch for tracking
[07:57] <edmoore> right, back later
[07:57] <Laurenceb> I dont follow
[07:57] <Laurenceb> cya ed
[07:58] <rjharrison> bye
[07:58] <hallam> Laurenceb: don't ask me, it works
[07:58] <hallam> found it online
[07:58] <rjharrison> hehe
[07:58] <Laurenceb> lol
[07:58] <Laurenceb> tiz crazy
[07:58] <rjharrison> Good old cut and paste
[07:58] <hallam> rjharrison: #define COUNTONES(v) (v -= ((v >> 1) & 0x55555555), v = (v & 0x33333333) + ((v >> 2) & 0x33333333),(((v + (v >> 4)) & 0xF0F0F0F) * 0x1010101) >> 24)
[07:59] <hallam> counts the number of 1 bits in a 32-bit word
[07:59] <Laurenceb> dont get the commas
[07:59] <rjharrison> haha
[07:59] <rjharrison> def. WTF
[07:59] <hallam> oh, the C comma operator
[07:59] <Laurenceb> never used it
[07:59] <hallam> e.g. x=a,b,c;
[07:59] <Laurenceb> what does it do?
[07:59] <hallam> evaluates a, then b, then c, and returns c
[08:00] <Laurenceb> so a way to get functions on a single line
[08:00] <Laurenceb> with no ;
[08:00] <hallam> yeah
[08:00] <Laurenceb> neat
[08:00] <hallam> and in this case, get it into a macro
[08:00] <Laurenceb> yeah
[08:00] <Laurenceb> so you have a 4 component lookup table for the carriers ?
[08:00] <hallam> it's just so absurdly fast
[08:00] <hallam> I can't help but keep running it
[08:00] <hallam> yeah
[08:01] <Laurenceb> nice
[08:01] <hallam> in fact, you can use the same table for both carriers
[08:01] <rjharrison> And the ternary operator is'nt even there
[08:01] <Laurenceb> how ?
[08:01] <Laurenceb> you can shift, but I needs inverting
[08:01] <Laurenceb> oh you lookup a different position?
[08:01] <hallam> yeah
[08:01] <hallam> http://www.mibbit.com/pb/Rn7Ou7
[08:01] <Laurenceb> I kind of see it
[08:01] <hallam> rjharrison: don't worry, I use the ternary pointer plenty
[08:02] <Laurenceb> whats that?
[08:02] <hallam> x=(a)?b:c;
[08:02] <hallam> evaluates a, returns b if it's true, c if it's false
[08:03] <rjharrison> I must say I avoid all that if I can for readability.
[08:03] <rjharrison> But it may compile to faster code
[08:03] <hallam> oh I don't think ternary compiles any faster than if
[08:03] <Laurenceb> oh sure
[08:03] <hallam> I like it a lot
[08:04] <Laurenceb> while(chan->carrier_phase > 4) chan->carrier_phase -= 4;
[08:04] <Laurenceb> whats with that?
[08:04] <hallam> cheaper than fmod
[08:04] <Laurenceb> what are you trying to do?
[08:04] <hallam> carrier_phase is still a float
[08:04] <Laurenceb> oh
[08:04] <Laurenceb> you need u16
[08:04] <Laurenceb> then its just a shift
[08:04] <hallam> oh, I made 2pi = 4
[08:05] <Laurenceb> yeah
[08:05] <hallam> I don't think u16 is enough
[08:05] <rjharrison> right im off before you cook my brain
[08:05] <hallam> I'll see
[08:05] <Laurenceb> well... I worked it out the other dat
[08:05] <Laurenceb> and it was fine
[08:05] <rjharrison> 2pi = 4 humm
[08:05] <Laurenceb> just a question of frequency steps
[08:05] <hallam> rjharrison: easier to work out which quadrant of the circle you're in
[08:05] Nick change: rjharrison -> rjharrison_quiet
[08:06] <Laurenceb> which will be around 0.5 Hz
[08:06] <Laurenceb> fine
[08:06] <hallam> as large as that?
[08:06] <Laurenceb> yes
[08:06] <hallam> ok
[08:07] <Laurenceb> oh hang on
[08:07] <hallam> well a u16 would be enough but I'm going to have negative frequencies in my hardware
[08:07] <Laurenceb> yeah s16
[08:07] <hallam> I'll go with s32
[08:07] <Laurenceb> fairdos
[08:07] <Laurenceb> guess its about as fast on a 32 bit machine
[08:08] <Laurenceb> I'm off, be back in 1/2 an hour
[08:08] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) left irc: "The day microsoft make something that doesnt suck is the day they make a vacuum cleaner"
[08:15] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc: Read error: 113 (No route to host)
[08:25] G_SQ5FNQ_Marcin (n=G_SQ5FNQ@235-tar-1.acn.waw.pl) joined #highaltitude.
[08:48] Laurenceb (i=zeusbot@lister.antycip.co.uk) joined #highaltitude.
[08:48] <Laurenceb> hi
[08:49] <Laurenceb> hallam: how goes it?
[08:50] <Laurenceb> got u16 carrier phase working?
[08:58] <hallam> u32
[08:58] <hallam> but I'm going to lecture now
[08:58] <hallam> ttyl
[09:00] <Laurenceb> cya
[09:02] <Laurenceb> yeah
[09:02] <Laurenceb> its 15.6Hz steps with u16
[09:03] <Laurenceb> with u32 its 0.000238
[09:19] Tiger^ (i=tygrys@moo.pl) left irc: Read error: 54 (Connection reset by peer)
[09:46] <Laurenceb> hallam: I just tried using u16 in matlab
[09:47] <Laurenceb> it still works
[09:47] <Laurenceb> it jumps between the different frequencies
[09:48] <Laurenceb> the noise actually spreads it across three frequency bins
[10:06] <Laurenceb> standard deviation on phase is <1cm
[10:15] <Laurenceb> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=CW660-ND
[10:16] <Laurenceb> if you want hardcore performance
[10:22] <Laurenceb> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=535-9615-1-ND
[10:22] <Laurenceb> ^ would do
[10:25] G_SQ5FNQ_Marcin (n=G_SQ5FNQ@235-tar-1.acn.waw.pl) left irc: " HydraIRC -> http://www.hydrairc.com <- Organize your IRC"
[12:04] <Laurenceb> list
[12:06] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[12:06] Nick change: dh_ -> dh
[12:09] <hallam> hey all
[12:10] <hallam> fergusnoble: Put a better carrier generator in the C and it is FAST
[12:11] <hallam> 80x realtime on my PC
[12:11] <fergusnoble> oh cool
[12:11] <hallam> we should easily be able to run 12 channels on the blackfin
[12:12] <fergusnoble> remember also the blackfin has faster bit shifts etc
[12:12] <fergusnoble> writing some of it in asm we should b able to make even more improvement
[12:12] <hallam> I think PCs have the shift instructions too, but we'll hand-write the tight loop in asm with parallel instructions
[12:13] <fergusnoble> so is it all basically working now?
[12:13] <hallam> I wouldn't be surprised if it ended up faster than the PC
[12:13] <hallam> the tracking is
[12:13] <hallam> still need to do nav, and reacquisition
[12:13] <hallam> Laurenceb: Is the carrier phase information any use for autonomous operation?
[12:13] <fergusnoble> awesome
[12:13] <fergusnoble> doing nav would be really cool, just because it would make the thing feel more concretely like a gps :)
[12:14] <fergusnoble> has the book come yet?
[12:14] <hallam> I should go pick it up from college
[12:14] <hallam> am sort of avoiding college right now
[12:14] <fergusnoble> hehe
[12:14] <fergusnoble> did you ever get that control stuff in?
[12:14] <hallam> not technically
[12:15] <fergusnoble> henry!
[12:15] <fergusnoble> you should have said you wanted to do a gps for your 4th year project :)
[12:15] <hallam> I know
[12:16] <fergusnoble> hallam: i wonder how fast we can make aquisition
[12:16] <hallam> I was thinking about that in lecture
[12:16] <fergusnoble> if we pre-load the alminac
[12:17] <hallam> worst case about 15 minutes, but probably better than that
[12:17] <fergusnoble> if its 15mins we may as well not bother
[12:17] <hallam> why?
[12:17] <fergusnoble> it will be down by then
[12:17] <hallam> no no
[12:17] <hallam> that's acquisition
[12:17] <hallam> not reacquisition
[12:17] <fergusnoble> oh ok
[12:18] <hallam> for reacq it will know where to look
[12:18] SpeedEvil (n=jfkjdjkf@mauve.plus.com) joined #highaltitude.
[12:18] <hallam> did I mention that I'd tested how good it is at dealing with acceleration?
[12:18] <hallam> hi s
[12:18] <fergusnoble> hallam: no?
[12:19] <SpeedEvil> when did I ping out?
[12:19] <fergusnoble> how did you test it? :)
[12:19] <SpeedEvil> hi
[12:19] <hallam> without changing the loop filters it can take about 10 g depending on the signal strength
[12:19] <SpeedEvil> 1G?
[12:19] <SpeedEvil> :)
[12:19] <SpeedEvil> hallam: are you faking it by speeding up or slowing down the signal?
[12:19] <hallam> you add a fake term to the doppler, increasing over time
[12:19] <hallam> so the PLL has to shift to cancel it
[12:19] <fergusnoble> ok
[12:19] <fergusnoble> and you think it will take 50g with the filters changed?
[12:20] <hallam> but by increasing the PLL gain and noise bandwidth it keeps tracking up to around 100g
[12:20] <hallam> the weak sat can't take much more than 50
[12:20] <fergusnoble> ok, cool
[12:20] <SpeedEvil> If you add a trivial IMU, you should get it to tens of thousands of G easily.
[12:20] <hallam> of course the output gets noisier but the filters can be adaptive
[12:20] <hallam> yeah I know, even a simple accelerometer input would help enormously
[12:20] <SpeedEvil> Neglecting the whole 'falling apart' thing
[12:21] <hallam> SpeedEvil: predicted acceleration on the rocket is about 50
[12:21] <SpeedEvil> m/s or g
[12:21] <fergusnoble> hallam: well we do have an accelerometer on board
[12:21] <hallam> g
[12:21] <hallam> yeah, I definitely think we should have the LPC relay it to the blackfin
[12:21] <SpeedEvil> hallam: remind me - what's this for again?
[12:21] <hallam> 100km balloon-launched rocket
[12:22] <SpeedEvil> ah
[12:22] <fergusnoble> hallam: even if its not incorporated into the blackfin code, it can be used to help on the ground
[12:22] <SpeedEvil> Is it spun?
[12:22] <hallam> no
[12:22] <hallam> fergusnoble: on the ground, you don't need it, post-processing just slows down a little because it has to reacquire more often
[12:22] <fergusnoble> ok, cool
[12:23] <SpeedEvil> You can just widen the acquisition window.
[12:23] <SpeedEvil> Until the GPS signal falls off the IF filter at .05C or so :)
[12:23] <hallam> hehe
[12:24] <hallam> SpeedEvil: got the C code tracking at about 80x realtime, without even doing any hand assembler yet
[12:24] <SpeedEvil> hallam: yeah - fast processors are easy
[12:24] <SpeedEvil> hallam: small ones are more fun
[12:25] <hallam> the Blackfin's pretty small, but still fast
[12:26] <hallam> fergusnoble: I think we should hack a couple wires into the blue stick and feed them to a Blackfin
[12:28] <Laurenceb> hi hallam
[12:28] <hallam> hi
[12:29] <Laurenceb> sounds a good plan
[12:29] <Laurenceb> is there a 3.3v reg on the sige board?
[12:30] <fergusnoble> hallam: yeah, definately
[12:30] <Laurenceb> there must be from the usb
[12:30] <fergusnoble> hallam: will need to have a look and see if they are easy to break out
[12:30] <Laurenceb> ideally you'd power it off the blackfin board
[12:30] <hallam> yeah there is a reg
[12:30] <Laurenceb> fergus: you may have to solder to the ic
[12:30] <fergusnoble> they might be easier to get off from the cypress usb chip end as thats not qfn
[12:30] <Laurenceb> hard but possible
[12:30] <Laurenceb> I've soldered stuff like that before
[12:31] <Laurenceb> yeah
[12:31] <hallam> I should really get this under a microscope
[12:31] <Laurenceb> hehe
[12:31] <fergusnoble> hallam: luckily you have a nice stereo one :)
[12:31] <Laurenceb> being shortsighted, I just take off my glasses
[12:31] <Laurenceb> and avoid solder splashes in eyes
[12:31] Action: SpeedEvil turns his stereo microscope up to 11.
[12:31] <SpeedEvil> Though I've actually only got a mono one.
[12:32] <hallam> Laurenceb: I'm myopic too and it's definitely better than nothing, but I was amazed at how useful a stereo microscope was
[12:32] <Laurenceb> yeah
[12:32] <SpeedEvil> However, decent webcams and LCD are actually good.
[12:32] <Laurenceb> I used one for die level mods at oxford
[12:32] <hallam> that must need a steady hand
[12:32] <Laurenceb> on perkin elmer sensor arrays
[12:32] <hallam> I thought 0.4mm QFN was tricky
[12:32] <hallam> haven't tried wire bonding
[12:32] <Laurenceb> for the submillimeter fft spectrometer :P
[12:33] <Laurenceb> its pretty cool working ion dies
[12:33] <Laurenceb> perkin elmer claimed it was made at their plant in germany
[12:34] <Laurenceb> but there was a marking from a fab in china on the die
[12:35] <Laurenceb> if you want to power it off the blackfin board, you might be able to connect in and out on the v reg
[12:35] <Laurenceb> not sure if you'll fry the cypress
[12:35] <hallam> eh, it'll be fine
[12:35] <Laurenceb> is that piowered directly off the usb?
[12:35] <SpeedEvil> Many/most USB stuff seems to use 3.3V mainly
[12:35] <SpeedEvil> through a regulator
[12:35] <Laurenceb> or off the 3.3v
[12:36] <hallam> probably the 3.3V
[12:36] <Laurenceb> it'll be ok then
[12:36] <hallam> I'm not intending this to be a practical navigation device, just a test rig on my bench
[12:36] <Laurenceb> I have a cypress thingy with inbuilt reg
[12:36] <hallam> USB power is actually easier
[12:36] <Laurenceb> yeah
[12:36] <hallam> better to power the Blackfin off the stick
[12:36] <hallam> the Blackfin doesn't have a PSU anyway
[12:36] <Laurenceb> just have to be careful to rig it up correctly
[12:36] <hallam> thanks Laurenceb, I think I'll manage :)
[12:36] <Laurenceb> :P
[12:37] <fergusnoble> all usb stuff uses 3.3v at some point because thats the signal level on the usb data linces iirc
[12:37] <fergusnoble> *lines
[12:38] <Laurenceb> well I'm not responsible for any fired blackfin/sige board
[12:38] <Laurenceb> :D
[12:38] <Laurenceb> hallam: so the carrier is working with a u32 for phase?
[12:39] <hallam> yeah
[12:39] <hallam> nice and speedy
[12:39] <Laurenceb> I tried a u16 in matlab and it still works
[12:39] <SpeedEvil> U8!
[12:39] <hallam> fuck that, 1 bit
[12:39] <Laurenceb> it jumps around between bins - 15.6Hz spacing
[12:39] <Laurenceb> lol
[12:39] <fergusnoble> its slower to use a different size then the machine word size
[12:39] <Laurenceb> yeah
[12:39] <Laurenceb> u32 is fine
[12:39] <fergusnoble> may as well use a u32
[12:39] <hallam> I'm happy with u32
[12:40] <Laurenceb> interesting erperiment to use u16 tho
[12:40] <hallam> sure
[12:40] <hallam> you could see if s16 works
[12:40] <Laurenceb> basically the noise is larger than 15.6Hz so its really not significant
[12:40] <hallam> I'm using u32 for phase and s32 for frequency
[12:40] <Laurenceb> stupuid question: can you still use the 2msb if its signed?
[12:40] <hallam> so it supports negative frequencies
[12:41] <Laurenceb> yeah
[12:41] <hallam> you can use them, but it's 2's complement so it's a bit weird
[12:41] <Laurenceb> yeah
[12:41] <hallam> no point really having a signed type for phase, but definitely for frequency
[12:41] <Laurenceb> but u32 phase s32 freq is fine
[12:41] <Laurenceb> yeah
[12:41] <fergusnoble> Laurenceb: effectively you lose the fist msb, but its not actually that simple in hardware
[12:41] <fergusnoble> beacuse its stored as 2's comp
[12:41] <Laurenceb> it just loops around the phase in reverse for -ive freq
[12:42] <hallam> right, perfect
[12:42] <Laurenceb> fergus: yeah I get it
[12:42] <Laurenceb> hallam: how much faster is it now?
[12:42] <Laurenceb> before you said 29MHz/chan
[12:43] <hallam> oh, a bit, but not much
[12:43] <hallam> maybe 20 or 25MHz
[12:43] <Laurenceb> oh I found an explanation of that countones code
[12:43] <Laurenceb> nice
[12:43] <hallam> going from float to integer for the phase didn't make a ton of difference
[12:44] <Laurenceb> the maths is.... erm ....
[12:44] <Laurenceb> complex :P
[12:44] <Laurenceb> safe to say it works
[12:44] <hallam> it was really using the lookup method to make the interleaved carrier that did it
[12:44] <hallam> Laurenceb: my thoughts exactly
[12:44] <Laurenceb> hehe
[12:45] <Laurenceb> theres a whole page of countones functions
[12:45] <fergusnoble> hallam: having the hardware countones should strip a bit off
[12:45] <Laurenceb> but thats best for 32 bit machines
[12:45] <SpeedEvil> Laurenceb: where - countones
[12:47] <Laurenceb> http://graphics.stanford.edu/~seander/bithacks.html
[12:47] <SpeedEvil> thanks
[12:48] <Laurenceb> http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel
[12:48] <SpeedEvil> I think you can maybe beat that by bitslicing
[12:48] <Laurenceb> its obfusticated enough for me to leave it as it is
[12:49] <SpeedEvil> bitslicing obfuscates it _considerably_ more.
[12:50] <Laurenceb> you'll need to use the sync line to enable the hardware
[12:51] <hallam> Laurenceb: that's where I got the routine
[12:51] <Laurenceb> cool
[12:51] <hallam> hmm
[12:51] <Laurenceb> hallam: spi?
[12:51] <hallam> actually I'm not sure I can plug the stick into the blackfin
[12:51] <Laurenceb> sync to /ss
[12:51] <hallam> sure that's the plan for the rocket hardware
[12:52] <hallam> but in the stick it's in pulse mode, not byte mode
[12:52] <Laurenceb> whats the issue?
[12:52] <Laurenceb> oh bugger
[12:52] <hallam> I guess I can see if I can force that line low or high or something
[12:52] <hallam> or maybe break out the TTL
[12:52] <Laurenceb> this calls for hardcore hacking
[12:53] <Laurenceb> cut the traces, put in some switches
[12:53] <fergusnoble> hallam: maybe capture a bunch of test data first incase you break it :)
[12:53] <Laurenceb> hehe
[12:53] <hallam> Laurenceb: you can't see the damn traces, it's 6-layer or something
[12:53] <hallam> at least 4
[12:53] <Laurenceb> it would be really cool to stick a little raw data interface port in the side
[12:53] <Laurenceb> ew
[12:54] <hallam> ok ok I'll see what I can do
[12:54] <Laurenceb> have you already mached up the case?
[12:54] <Laurenceb> mashed
[12:54] <fergusnoble> hallam: the taces must go to vias to get into the inner layers, you can grab them there
[12:55] <SpeedEvil> unless they're blind vias
[12:55] <Laurenceb> Fs_SEL<1:0>=10
[12:55] <Laurenceb> is what yopu want
[12:55] <hallam> yeah the case took some mashing
[12:55] <Laurenceb> problem is, it00 astm
[12:55] <Laurenceb> they may just go to gnd
[12:55] <Laurenceb> i.e. ground flood
[12:55] <hallam> I'm sure I can get to the data lines, it's just the fs-sel things
[12:55] <hallam> right
[12:56] <Laurenceb> thats pretty unfixable
[12:56] <hallam> they might be via a resistor
[12:56] <hallam> I'll see
[12:56] <hallam> let me get the scope out
[12:56] <Laurenceb> do they go straight into the ground plane?
[12:56] <SpeedEvil> desolder the micro?
[12:56] <Laurenceb> arg
[12:56] <hallam> I'd love to keep it useful as a sampler
[12:56] <Laurenceb> dont want to desolder the front end
[12:56] <hallam> SpeedEvil: that won't help if the configure lines are grounded directly at the front end
[12:57] <fergusnoble> hallam: can always get it put in the 3d xray :)
[12:57] <SpeedEvil> true
[12:57] <hallam> can the x-ray cut internal traces too?
[12:57] <Laurenceb> the fsel line are at the corener
[12:57] <Laurenceb> 12 and 13
[12:57] <fergusnoble> hallam: are you positive you cant use it in pulse mode?
[12:58] <Laurenceb> need to switch to 4Msps
[12:58] <Laurenceb> ideally
[12:58] <Laurenceb> maybe rigup a counter?
[12:58] <Laurenceb> on the sync pulses?
[12:59] <Laurenceb> hmm I bet you cxould do it with some DIP logic ICs
[12:59] <hallam> fergusnoble: can't see a way with SPI
[12:59] <Laurenceb> this may be a better plan
[12:59] <hallam> I can do it easily enough with a PIC18 or 24, and I have plenty of those around
[12:59] <hallam> even leaving it at 8
[12:59] <Laurenceb> hallam: is there a ground layer flood to the corner?
[13:00] <hallam> wait til I get it under the scope! crikey
[13:00] <Laurenceb> hehe
[13:00] <Laurenceb> maybe just logic... I'm thinking about it
[13:00] <fergusnoble> hallam: are you sure it doesnt work? put the blackfin in slave mode and then just remember to turn the gps on first so you get the beginning of the clock
[13:00] <fergusnoble> forget the sync plse
[13:00] <fergusnoble> sorry, gps on last
[13:00] <Laurenceb> its still 8Msps
[13:01] <fergusnoble> the spi shold be able to take that
[13:01] <fergusnoble> even the arm spi can do like 30mhz
[13:01] <Laurenceb> yeah, but you have to convert it to be useful
[13:02] <hallam> hm
[13:02] <hallam> what would happen if the I and Q were to get reversed?
[13:02] <Laurenceb> nothing
[13:02] <Laurenceb> if they stay that way
[13:02] <hallam> right
[13:02] <hallam> ok, so SPI @ 8MHz is a fallback
[13:03] <SpeedEvil> Umm. Don't you get discontinuous results if I and Q are reversed?
[13:03] <Laurenceb> I diont follow
[13:03] <Laurenceb> how would you do it at 8Msps
[13:04] <Laurenceb> hallam, stick a divide by two on sync
[13:04] <Laurenceb> then put it into /ss on the spi
[13:04] <Laurenceb> problem solved
[13:04] <hallam> a divide by two is lots more hardware than just chucking half of them in software
[13:05] <hallam> it has the speed anyway
[13:05] <Laurenceb> but you have to do intelaced chucking
[13:05] <Laurenceb> I'd just picvk something up from stores
[13:05] <Laurenceb> and stripboard it
[13:06] <hallam> I don't see how div/2 would work
[13:06] <fergusnoble> Laurenceb: often you are supposed to leave a gap between asserting chip select and starting clocking
[13:06] <Laurenceb> ok
[13:06] <SpeedEvil> hallam: divide the clock by two - then you discard half of the samples if you clock on one edge of the divided clock
[13:07] <Laurenceb> use it to control the clock
[13:07] <Laurenceb> sync goes into a divide by two, then output goes into a nand with clock
[13:07] <Laurenceb> which goes to the spi clock
[13:07] <hallam> oh
[13:07] <hallam> meh
[13:07] <hallam> hardware
[13:07] <Laurenceb> hopefully two ICs
[13:08] <SpeedEvil> two ICs?
[13:08] <Laurenceb> but I dont know logic ICs by heart
[13:08] <SpeedEvil> why not just divide teh clock alone?
[13:08] <hallam> if stores even have TTL
[13:08] <Laurenceb> register thingy of some sort=divide by two
[13:08] <hallam> because then you'd get I, I, I, I
[13:08] <SpeedEvil> ah, right
[13:08] <Laurenceb> then a nand
[13:09] <Laurenceb> I'm searching for divide by two circuits
[13:09] <Laurenceb> need a flip flop
[13:09] <hallam> it's just a flipflop
[13:09] <hallam> 4 nands
[13:09] <hallam> er, 2 nands
[13:09] <SpeedEvil> 7474
[13:09] <Laurenceb> how many nands ion there?
[13:09] <SpeedEvil> I was meaning hte 7474 is a dual j/k flip-flop
[13:09] <SpeedEvil> IIRC
[13:10] <SpeedEvil> 7400 has 2 nands
[13:10] <SpeedEvil> 4
[13:10] <SpeedEvil> Oops - dual d flip flop
[13:10] <Laurenceb> how many nands to make a flip flop?
[13:10] <Laurenceb> wondering if you could do it with one IC
[13:11] <hallam> I thought you only needed 2, but now I think it's 4
[13:11] <Laurenceb> http://www.play-hookey.com/digital/rs_nand_latch.html
[13:12] <Laurenceb> http://wearcam.org/ece385/lectureflipflops/flipflops/
[13:14] <fergusnoble> hallam: the eietl has loads of descrete logic in that big tower of little drawers
[13:14] <fergusnoble> if you really want to do it that way
[13:15] <fergusnoble> i think its best to look and see if we can change the fsel
[13:15] <Laurenceb> it means its the same as a 4Msps as far as the firmware goes
[13:15] <Laurenceb> grr I still cant work it out
[13:15] <fergusnoble> Laurenceb: surely the data will change in the middle of the clock cycle, which can give wierd results
[13:16] <Laurenceb> I bet its possible with one NAND gate IC
[13:16] <Laurenceb> I dont think so
[13:17] <Laurenceb> you set the spi to sample on rising edge
[13:17] <gordonjcp> you can do a flipflip with two nand gates, but you really need four for pulse steering
[13:17] <Laurenceb> or falling even
[13:17] <gordonjcp> depending on if you want a D or S/R flipflop
[13:17] <Laurenceb> just want to divide a clock by 4
[13:17] <Laurenceb> erm 2
[13:18] <hallam> guys you can stop panicing
[13:19] <hallam> FS_SEL go through resistors
[13:19] <Laurenceb> oh yes
[13:19] <Laurenceb> both?
[13:19] <hallam> yeah
[13:20] <Laurenceb> actually you only need1
[13:20] <Laurenceb> switch to Vcc on 1 :P
[13:20] <hallam> wow this thing was assembled kind of shoddily
[13:20] <hallam> way too much solder paste on the front end
[13:20] <fergusnoble> hallam: sweet, easy to bodge a wire to the end of the resistor?
[13:20] <Laurenceb> pin13
[13:20] <hallam> yeah no problems
[13:21] <Laurenceb> awsomeness
[13:21] <Laurenceb> did you have to remove screening to gwet the the front end?
[13:22] <SpeedEvil> Laurenceb: I think you're going to need about 10 NANDs to make a suitable flip-flop
[13:22] <Laurenceb> hehe
[13:22] <Laurenceb> SpeedEvil: no need
[13:22] <SpeedEvil> At least the simple way that replaces the normal Xor gate with a nand array
[13:22] <SpeedEvil> I know
[13:22] <hallam> there's a can over the front end and a can over the cypress, but both of their lids just lift off
[13:22] <Laurenceb> I see
[13:22] <hallam> underneath there's a sort of plus shaped thing
[13:22] <Laurenceb> eh
[13:22] <hallam> but I snipped that off, don't anticipate it causing any problems
[13:23] <hallam> looks like it was there to facilitate machine placing of the can
[13:23] <Laurenceb> like... reinforcement?
[13:23] <Laurenceb> ah
[13:23] <SpeedEvil> a metal former to keep the bottom of the can stable alone
[13:23] <hallam> right
[13:23] <SpeedEvil> to make the clip-on more secure too
[13:23] <Laurenceb> hallam: is it usiong a TCXO ?
[13:24] <hallam> I think so
[13:24] <hallam> hang on, I'll try to read the part number
[13:24] <hallam> wish this damn ring light would stay on the scope
[13:24] <Laurenceb> hallam: I found some nice TCXOs on digikey
[13:24] <Laurenceb> correct freq as well
[13:24] <hallam> I noticed
[13:24] <hallam> does super high stability really matter that much?
[13:24] <Laurenceb> not really
[13:25] <Laurenceb> but 30ppm is a bit high
[13:25] <SpeedEvil> not once you've got multiple sats locked
[13:25] <Laurenceb> - most of the normal crystals
[13:25] <Laurenceb> if the temperasture is repidly changing
[13:25] <Laurenceb> it could mess things up
[13:25] <SpeedEvil> but a teeny bit of foam fixes that.
[13:25] <Laurenceb> with lower quality drystals
[13:25] <SpeedEvil> And a cc of water maybe.
[13:25] <Laurenceb> but any TCXO is way more than enough
[13:26] <Laurenceb> a few ppm
[13:26] <SpeedEvil> It matters if you're trying to keep lock in the asbsence of signals.
[13:26] <SpeedEvil> Then it really matters.
[13:26] <Laurenceb> yeah
[13:26] <SpeedEvil> But not likely a problem in the rocket unless it goes through tunnels :)
[13:26] <Laurenceb> the borre tracker seems to just use delta_time
[13:27] <Laurenceb> which may exoplain the odd behavior
[13:27] <Laurenceb> at 1Khz
[13:27] <Laurenceb> ideally you want a clock offset term
[13:28] <Laurenceb> and solve for dalta time then start tracking the clock offset
[13:28] <Laurenceb> i.e. error in crystal freqency
[13:29] <Laurenceb> I'm going to have a look at modding borres code
[13:29] <hallam> there's a black chip with 4 leads, looks like a crystal or TXCO, labelled JEy4V
[13:29] <hallam> JEY4V
[13:29] <hallam> can't find any references on google
[13:30] <hallam> might just be a crystal
[13:30] <Laurenceb> interesting
[13:30] <Laurenceb> are there 2 caps?
[13:30] <Laurenceb> and two pins grounded?
[13:32] <SpeedEvil> hallam: got a DMM?
[13:32] <SpeedEvil> hallam: are any pins grounded?
[13:32] <SpeedEvil> oops
[13:32] <hallam> I think it's a TXCO
[13:32] <hallam> or some kind of oscillator
[13:33] <hallam> only one lead goes into the SE4120
[13:33] <hallam> unless there's some crazy shit going on under the IC that I can't see
[13:33] <Laurenceb> and caps on it?
[13:33] <hallam> there's what looks like a series cap on that lead
[13:33] <hallam> I'll try to take a picture
[13:33] <Laurenceb> ah its an osc
[13:33] <Laurenceb> its in the datasheet
[13:34] <Laurenceb> 10n cap to pin125
[13:34] <Laurenceb> pin15
[13:34] <Laurenceb> http://www.sige.com/uploads/datasheets/SE4120L%20GNSS%20Receiver%20IC%20Datasheet.pdf
[13:34] <hallam> yeah
[13:34] <Laurenceb> page 18
[13:34] <Laurenceb> interesting
[13:35] <Laurenceb> hmm well osmething is causing these errors at 1KHz
[13:35] <hallam> they didn't follow the datasheet well enough to choose the right damn crystal
[13:35] <Laurenceb> first maybe I'll try a solution at 50Hz
[13:35] <Laurenceb> hehe
[13:35] <Laurenceb> noobs
[13:37] <Laurenceb> be interesting ot see if the errors dissappear at 20Hz
[13:39] <Laurenceb> fastax have a driver for the SE4120 btw
[13:39] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[13:39] <Laurenceb> aimed at phones and stuff
[13:39] <Laurenceb> hi edmoore
[13:40] <Laurenceb> hallam: do you have Borre's book yet?
[13:40] <hallam> haven't picked it up
[13:41] Action: SpeedEvil isn't bothering with books.
[13:41] <hallam> is it more useful than the software?
[13:41] <SpeedEvil> Just going straight for the C/asm, based on the colorado and other sites.
[13:41] <Laurenceb> hallam: its useful for explaining
[13:41] <hallam> Laurenceb: a driver?
[13:41] <hallam> as in, a software receiver?
[13:42] <SpeedEvil> At least for the acquisition - I may need help on the position solution.
[13:42] <edmoore> hi Laurenceb
[13:42] <Laurenceb> yes
[13:42] <hallam> nice
[13:42] Action: SpeedEvil wishes for source.
[13:42] <Laurenceb> hehe
[13:42] <SpeedEvil> The hammerhead chip is so nice and would be ideal - it's got correlators, peak detectors, ... all built in and a nice slow serial out.
[13:42] <hallam> SpeedEvil, do you have a front end?
[13:42] <SpeedEvil> No hard-real-time, ...
[13:42] <hallam> link?
[13:43] <Laurenceb> http://www.fastraxgps.com/products/softwaregps/softwaregps/
[13:43] <fergusnoble> SpeedEvil: the hammerhead on my phone sucks
[13:43] <SpeedEvil> hallam: one of the maxim GPS parts. I haven't exactly decided which ones
[13:43] <Laurenceb> 10MIPS/PRN
[13:43] <Laurenceb> we're getting close
[13:43] <hallam> SpeedEvil: which hammerhead chip is that?
[13:43] <fergusnoble> well, its ok, but it takes ages to lock without data network support
[13:44] <Laurenceb> -144 start/-160 track
[13:44] <SpeedEvil> http://wiki.openmoko.org/wiki/Hammerhead/Integrators
[13:44] <Laurenceb> sounds like what you get with about 1ms delay doppler map
[13:45] <Laurenceb> interesting how they got it down to 10MIPS
[13:45] <SpeedEvil> The above is based on watching the code output.
[13:45] <Laurenceb> mus be hardware optimised
[13:45] <Laurenceb> ported to x86 and ARM processors
[13:45] <Laurenceb> must have optimised it to some extent
[13:46] <SpeedEvil> I noted earlier that if you're willing to take more CPU in the weak signal case, you can ignore 19/20ms of the signal
[13:46] <Laurenceb> blackfin should be less than that
[13:46] <Laurenceb> I dont follow you
[13:46] <SpeedEvil> And even more if you don't need to decode the nav bits.
[13:46] <SpeedEvil> You say you're getting adequate S/N to track seperate ms.
[13:47] <Laurenceb> right
[13:47] <SpeedEvil> If you only decode 20 1ms samples per second, in the centre of nav-bits, rather than all of them, you get 20 of these to integrate into a position solution, not 1000
[13:47] <Laurenceb> yeah
[13:48] <SpeedEvil> But if you don't need 1000 to get the accuracy.
[13:48] <SpeedEvil> ...
[13:48] <SpeedEvil> What was the raw error at 1KHz - I forgot?
[13:49] <fergusnoble> SpeedEvil: sounds good, i guess you would have to be careful with the dynamics that you dont loose track
[13:49] <SpeedEvil> Of course.
[13:49] <Laurenceb> SpeedEvil: about 6m standard dev on pseudorange
[13:49] <Laurenceb> with carrier aiding
[13:49] <SpeedEvil> It also means that on a limited CPU, instead of picking 4 sats - forex - you can do all in view
[13:53] <Laurenceb> ok... almost finished the last channel
[13:54] <Laurenceb> I'm funning the nav loop at 50Hz
[13:54] Tygrys^ (n=tygrys@moo.pl) joined #highaltitude.
[13:54] <Laurenceb> rather than 1Khz
[13:54] Nick change: Tygrys^ -> Tiger^
[13:54] <SpeedEvil> sounds sane.
[13:55] <hallam> I didn't have much luck getting a picture of the board I'm afraid, my camera doesn't work well with the microscope
[13:55] <SpeedEvil> I think 1KHz is only needed if you're gun-launching :)
[13:55] <edmoore> when you say careful of the dynamics, do you just mean limit them?
[13:55] <SpeedEvil> hallam: 'macro' on the camera - can give surprisingly good results in some cases if you've got the light
[13:56] <fergusnoble> edmoore: no i mean the doppler or phase might drift beyond what the loop will track in 20ms
[13:56] <edmoore> no i know what you mean
[13:56] <Laurenceb> hmm fastrax sell amodule
[13:56] <Laurenceb> based on the Se4120 with an ARM
[13:56] <Laurenceb> reflash :P
[13:56] <SpeedEvil> fergusnoble: +-50m or so is a _long_ way to drift in 1/20th of a second :)
[13:56] <edmoore> so i mean - do you just limit the dynamics you subject the receiver to, or can you recover a lock quickly enough?
[13:57] <fergusnoble> but you can take account of that with the coeffs and such, but i think you intoduce a bit of extra noise
[13:57] <hallam> SpeedEvil: I tried the macro mode (with and without the scope) but it wasn't any good, I think my camera just sucks
[13:57] <SpeedEvil> :/
[13:57] <fergusnoble> no, reaquiring takes some time, henry thinks we might be able to make it quick enough but for now if we loose lock we are a bit stuffed
[13:58] <Laurenceb> you can reaquire
[13:58] <edmoore> sure but i'm thinking if you could add some other sensor, like a 3-axis acceleromneter, you'd hve some acceleration vector which would gicve the loop a fighting chance of keeping track in the absense of the feedback afforded to you by oversampling
[13:58] <Laurenceb> have acquistion running as a background task
[13:58] <edmoore> ok
[13:58] <Laurenceb> edmoore yes
[13:58] <hallam> Laurenceb: that's the plan
[13:58] <Laurenceb> you use accel to aid the pll
[13:58] <hallam> I just haven't tried reacquisition yet
[13:58] <hallam> it shouldn't take long
[13:58] <Laurenceb> you can feed in data to help the ac
[13:59] <Laurenceb> edmoore: nicely the max g goes with noise bandwidth ^2
[13:59] <Laurenceb> we tested it to 50g
[13:59] <edmoore> my question is if it's therefore good enough to try speedevils lower sample rate plan
[13:59] <SpeedEvil> Even lacking a 'proper' IMU - you can use the absolute accel to change the loops.
[13:59] <Laurenceb> simulated
[13:59] <Laurenceb> before it lost lock
[13:59] <fergusnoble> SpeedEvil: true, but we will be going maybe mach 4, which is a change of nearly 30m
[13:59] <edmoore> Laurenceb: I was about to correct you on that one too :p
[13:59] <Laurenceb> :P
[13:59] <SpeedEvil> fergusnoble: I wasn't meaning 30m
[13:59] <SpeedEvil> fergusnoble: I was meaning 30m delta from your expected position based on newton
[14:00] <SpeedEvil> fergusnoble: 30m delta in 1/20th of a second means you've flown into something.
[14:00] <hallam> now where did I put that Metcal?
[14:00] <edmoore> your room?
[14:00] <hallam> yeah, it's in here somewhere
[14:00] <fergusnoble> edmoore: yeah, i think it will be possible
[14:00] <Laurenceb> Metcal?
[14:00] <hallam> edmoore: where can I get a cheap XY stage?
[14:01] <hallam> Laurenceb: very nice, very expensive soldering iron
[14:01] <SpeedEvil> Laurenceb: a nice soldering iron brand
[14:01] <Laurenceb> cool
[14:01] <edmoore> hallam: for soldering?
[14:01] <SpeedEvil> Laurenceb: using wierd magnetic and skin effects to regulate temp
[14:01] <Laurenceb> cool
[14:01] <fergusnoble> edmoore: but the current code can run 80 simulatenous correlators on the pc and thats without any asm
[14:01] <Laurenceb> skin effect heating?
[14:01] <edmoore> fergusnoble: i think so too. it's a quantitative arguement rather than a qualitative one.
[14:01] <edmoore> fergusnoble: it cane do more on my laptop :D
[14:02] <hallam> edmoore: yes
[14:02] <Laurenceb> hmm there are similar effects at 50Hz
[14:02] <Laurenceb> I think its the delat time
[14:02] <hallam> if nothing else, for moving the board about under the scope, because the scope only has one degree of freedom in that plane
[14:02] <edmoore> hallam: machinemart?
[14:02] <Laurenceb> the nav fil;ter need to know crystal drift
[14:02] <hallam> would "X Y stage" be the right thing to look for?
[14:03] <fergusnoble> hallam: the ones you get for drill presses would be the cheapest, but not so accurate
[14:03] <Laurenceb> yeah
[14:03] <fergusnoble> you can get them from machine mart
[14:03] <hallam> doesn't have to be accurate
[14:03] <hallam> ok
[14:03] <Laurenceb> you can pick them up on ebay
[14:03] <Laurenceb> what for?
[14:03] <edmoore> they're fine for soldering, they're quite tall though
[14:05] <edmoore> check them for cast iron dust though first
[14:05] <edmoore> they're cheaply produced
[14:06] <edmoore> hallam: if you can find a local one, i will drive u
[14:07] <edmoore> bbiab
[14:07] <hallam> cool
[14:07] <hallam> Peterborough?
[14:08] <hallam> Laurenceb: interestingly enough FSSEL0 has a via in it going somewhere
[14:09] <Laurenceb> we dont need to change it
[14:09] <Laurenceb> luckly
[14:11] edmoore_ (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[14:12] <fergusnoble> hallam: maybe it goes to the cypress chip, so you could change it in software
[14:13] <hallam> yeah
[14:14] <hallam> I think I'll do it in hardware though
[14:14] <Laurenceb> those blackfin board are quite cheap
[14:14] <hallam> just bring out 3.3V, gnd, data, clk, sync and fssel0
[14:14] <hallam> the surveyor ones?
[14:14] <Laurenceb> fancy one myself :P
[14:14] <Laurenceb> yes
[14:14] <hallam> yeah they're pretty nice
[14:14] <hallam> don't get the robot base though, it's crap
[14:14] <Laurenceb> fssel1
[14:14] <Laurenceb> yeah
[14:14] <hallam> sorry yeah 1
[14:15] <hallam> I mean, the base isn't terrible, it's just not worth the extra $$$
[14:15] <Laurenceb> yeah
[14:15] <Laurenceb> why would I want it anyway
[14:15] <Laurenceb> I'm only interested in flying stuff
[14:15] <edmoore_> hallam: what's the name of that blackfin-stamp tpy unit?
[14:15] <edmoore_> type*
[14:15] <edmoore_> the stamp + memories on a solderable package
[14:16] <Laurenceb> erm
[14:16] <hallam> no
[14:16] <hallam> not that
[14:16] <edmoore_> Laurenceb: what are you doing?
[14:16] <Laurenceb> dont know
[14:16] <hallam> edmoore_, I'll find it, gimme a sec
[14:16] <Laurenceb> :P
[14:16] <edmoore_> ta
[14:17] <hallam> http://www.bluetechnix.at/rainbow2006/site/blackfin_family/__core_modules/__tcm-bf537/315/tcm-bf537.aspx this is the one I like
[14:17] <hallam> they have other, slightly bigger ones
[14:18] <edmoore_> cool, thanks
[14:18] <edmoore_> just the ticket
[14:18] <hallam> for?
[14:18] <edmoore_> interest!
[14:18] <hallam> :)
[14:18] <Laurenceb> nice
[14:18] <Laurenceb> lovely beasty
[14:18] <hallam> might be worth asking them for sponsorship
[14:18] <hallam> actually I think I might have already, and not heard back
[14:19] <edmoore_> how much current does a typical part pull on full clock with most things running?
[14:19] <hallam> the whole surveyor board draws somewhere in the region of 100-150mA
[14:20] <hallam> but part of that is the camera
[14:20] <edmoore_> that's very reasonable for the MIPS
[14:20] <hallam> yeah it's not bad
[14:20] <edmoore_> oh well. I'll get on with badger2
[14:20] <fergusnoble> i guess it is designed to go in battery powered things like cameras
[14:20] <edmoore_> want to get that sent off
[14:20] <fergusnoble> edmoore_: i can do som badger2 this evening
[14:20] <fergusnoble> well, any time after 5.30
[14:20] <edmoore_> that would be cool if you want
[14:20] <edmoore_> we could get pizza
[14:21] <edmoore_> i have management lectures 4-6
[14:21] <hallam> do you think there'll be a problem with RFI if I take the clock and data lines out through the can?
[14:21] <fergusnoble> sounds good
[14:21] <Laurenceb> that thingys bbl "team meeting" joy
[14:21] <Laurenceb> erm
[14:21] <fergusnoble> edmoore_: actually it might be more like 6 for me too, my supervision always overruns
[14:21] <edmoore_> fergusnoble: if we could bored we could try a rocket board design :p
[14:21] <fergusnoble> we could head up together iuw
[14:21] <edmoore_> i suspect thtough we won't even get close
[14:22] <fergusnoble> the trouble with that is i would like to get some advice about the rf design
[14:22] <edmoore_> rf design?
[14:22] <fergusnoble> but yes, it would be good to get a little prototype with the sige and th lpc2300 on it
[14:23] <fergusnoble> everything the other side of the antenna input on the sige
[14:23] <edmoore_> fergusnoble: my thinking too. concept would at least be proved
[14:23] <edmoore_> fergusnoble: sure, yeah
[14:23] <fergusnoble> i think its got to be done well if we want to try a passive chip antenna
[14:23] <hallam> Laurenceb: FILT_BW is pulled low (2MHz BW) but again there's a via so it might be under sw control
[14:24] <edmoore_> that's obviously true, though there is lots on rf pcb design for gps
[14:24] <fergusnoble> ok
[14:24] <fergusnoble> maybe we can have a look if we get bored
[14:24] <edmoore_> can nick the ublox hardware integration manual which goes into it in perverse detail
[14:24] <edmoore_> i guess we'll have more than enough to keep us amused though with just badger
[14:24] <edmoore_> you know the 2368 in cheaper than the 2148?
[14:24] <edmoore_> is*
[14:25] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[14:26] <edmoore_> fergusnoble: can do 6.30-10.30 tonight. have got gym with chris after that, and I need to go
[14:27] <fergusnoble> edmoore_: really, wow :)
[14:27] <fergusnoble> edmoore_: ok, so want to walk up to churchill together?
[14:27] <edmoore_> sure
[14:27] <edmoore_> i'll call you as I leave the dept
[14:28] <edmoore_> basically need to make the fuel guage package then have a route-a-thon
[14:28] <edmoore_> + whatever else we think of
[14:28] <fergusnoble> ok, if i dont answer then the supervision has run over so come to queens
[14:28] <fergusnoble> and ill be out pretty soon
[14:28] <fergusnoble> unusual they go on past 6
[14:28] <edmoore_> fergusnoble: it strikes me that the rocket board may conceptually lend itself well to drop test flight computer. i.e. space constraints + high speed logging
[14:29] <fergusnoble> yeah, possibly true
[14:29] <edmoore_> which i guess adds weight to just making badger2 very very good at ballooning
[14:30] <hallam> how about putting a few badger2 breakout boards on the goldphoenix order?
[14:31] <edmoore_> that was the plan i think - but 2 layer
[14:31] <edmoore_> multi-design for 4 layer costs almost as much as an entire 2-layer panel
[14:32] <edmoore_> that would be the next thing to make after badger2, anyway
[14:32] <fergusnoble> yeah, would be good to play with the radio rx
[14:33] <edmoore_> very much agreed
[14:33] <edmoore_> like whether or not we want to just have a 169downlink and a 434 uplink or not
[14:33] <fergusnoble> shall we use a 16bit dac for the radio tx then?
[14:33] <edmoore_> yeah i think that's a good idea
[14:33] <fergusnoble> edmoore_: we can have both :)
[14:33] <edmoore_> more future-proof anyway
[14:34] <fergusnoble> we can put an extra tx footprint and dac on the expansion board
[14:34] <edmoore_> so we can entirely offload radio duty to daughter board?
[14:34] Nick change: hallam -> hallam|food
[14:34] <fergusnoble> oh maybe, but i was thinking so we could possibly have two tx's
[14:35] <edmoore_> :)
[14:35] <edmoore_> i like
[14:35] <edmoore_> so one 434 array - for 50 baud rtty that amatuers can listen to aswell, and a 169 for funner stuff?
[14:36] <fergusnoble> yeah, could be good
[14:36] <fergusnoble> need to think about how to fit the antennas onto the payload
[14:36] <edmoore_> def
[14:36] <edmoore_> well i have some ideas about that
[14:36] <edmoore_> i reckon we should just go to the dept and make something
[14:36] <fergusnoble> yeah
[14:37] <edmoore_> i'd like to try a 434 big wheel
[14:37] <fergusnoble> yeah deffo
[14:37] <edmoore_> your idea anyway, so i guess you want to try it more :)
[14:38] <edmoore_> but yeah, will draw you what i was funkin later
[14:38] <edmoore_> you emailed a link to some polystyrene boxes a bit ago
[14:38] <fergusnoble> does your idea extend to two antennas?
[14:38] <edmoore_> I say get some
[14:38] <edmoore_> fergusnoble: yes
[14:42] <hallam|food> edmoore_: Peterborough machine mart at your convenience?
[14:43] <edmoore_> hrm
[14:43] <edmoore_> that's non trivial
[14:43] <edmoore_> let me have a look
[14:43] <hallam|food> it's a bit of a trek I suppose
[14:43] Nick change: hallam|food -> hallam
[14:43] <edmoore_> it's 50 mins each way
[14:43] <hallam> no hurry, and I can give you some petrol money
[14:43] <edmoore_> longer than i had in mind, I'll be honest
[14:43] <hallam> ok no worries
[14:44] <fergusnoble> bbl, supervision
[14:44] <edmoore_> well it's be 2 hrs of petrol = about 15
[14:44] <edmoore_> £15*
[14:44] <edmoore_> so see how much shipping is
[14:44] <edmoore_> i'm off too, back a bit later
[14:44] Nick change: Guest43341 -> Ebola
[14:47] Nick change: edmoore_ -> edmoore|away
[15:05] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[15:31] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[15:44] edmoore|away (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[16:00] <Laurenceb> hello
[16:00] <Laurenceb> I'm back
[16:00] <Laurenceb> honey I'm home
[16:01] <Laurenceb> ect
[16:08] <Laurenceb> I think the [position solution oscillation is due in poart to crystal offset
[16:16] Nick change: Bluenarf -> EI5GTB
[16:27] <SpeedEvil> umm
[16:27] <SpeedEvil> won't that just affect doppler?
[16:27] <SpeedEvil> jitter being needed to make position solutions oscillate
[16:30] <Laurenceb> the nav filter assumes the clock is perfect
[16:31] <Laurenceb> so dt at the receiver is corrected
[16:31] <SpeedEvil> Ah - right
[16:31] <Laurenceb> not dt/dt
[16:31] <Laurenceb> not dt_receiver/dt
[16:31] <Laurenceb> I'm going to find the difference between consecutive dt estimates
[16:32] <Laurenceb> then use that to correct
[16:32] <Laurenceb> its crying out for an extended kalman filter
[16:32] <Laurenceb> fastrax use one
[16:33] <SpeedEvil> Dozens of inputs and outputs to be ideal I suppose.
[16:33] <Laurenceb> some people complain about modules with extended jkalman filters as its very sub optimal to layer them
[16:33] <Laurenceb> ie. one in module one in your imu or whatever
[16:33] <Laurenceb> but we dont have that problem :P
[16:33] <Laurenceb> as we have the source code
[16:34] <SpeedEvil> I mean you ideally want a filter with outputs of X,Y,Z,time, loop filter for PRN31,
[16:34] <SpeedEvil> ...
[16:34] <SpeedEvil> But that's probably overkill, and won't actually buy you much - at least in the good signal case
[16:36] <Laurenceb> hopefully just xyz dtime/dt
[16:36] <Laurenceb> initialise it with a newton raphson
[16:37] <SpeedEvil> I could see it helping lots in the case where you've got multipath, trees, ...
[16:38] <SpeedEvil> :)
[16:38] <SpeedEvil> http://www.washingtonpost.com/wp-dyn/content/article/2009/01/26/AR2009012602086.html?nav=rss_email%2Fcomponents
[16:38] <SpeedEvil> With a google ad - 1 Inch Female Brass Bush
[16:38] <SpeedEvil> Electric products discounted below trade price at TLC Electrical.
[16:47] <Laurenceb> lol
[16:52] <Laurenceb> clock_offset=dt-olddt
[16:52] <Laurenceb> olddt=dt
[16:52] <Laurenceb> dt=dt+clock_offset
[16:52] <Laurenceb> like that
[16:54] <Laurenceb> I initialise olddt=0
[16:54] <Laurenceb> so not sure how stable it will be
[16:55] <Laurenceb> if you could use doppler errors
[16:55] <Laurenceb> that would be perfect
[16:55] <Laurenceb> but you need position first
[16:55] <Laurenceb> catch22
[16:59] <SpeedEvil> Well - at normal speeds, you don't need to worry about problems with doppler at 20ms - the PRN code doesn't slip by more than a quarter of a cycle during that time.
[17:00] <SpeedEvil> So you just track that for a few periods, and lock to that.
[17:00] <SpeedEvil> (the apparant rate I mean)
[17:01] <SpeedEvil> Looks like fun - http://www.fire.gov/PPV/index.htm
[17:01] <SpeedEvil> Though I'm probably missing what you're saying - feeling like going to sleep.
[17:02] <Laurenceb> yeah its certainly possible to come up with good solutions for this
[17:03] <SpeedEvil> It only really gets tricky if you need rapid lock in constrained conditions.
[17:04] <SpeedEvil> (low CPU, low signal, high initial speed (>2000m/s), ...)
[17:11] <Laurenceb> hmm this is odd
[17:11] <Laurenceb> my solutions form a fern shape in 3D space
[17:15] <SpeedEvil> how many sats?
[17:16] <hallam> 3.5
[17:16] rjharrison_quiet (n=rharriso@gateway.hgf.com) left #highaltitude.
[17:18] <Laurenceb> hehe
[17:18] <Laurenceb> 4
[17:18] <Laurenceb> but one is dodgy
[17:18] <Laurenceb> the solutions oscillate between leaves of the fern
[17:18] <hallam> Laurenceb, would you like my C tracker and it's matlab bodge-erface?
[17:18] <Laurenceb> yeah thanks
[17:19] <Laurenceb> have my email?
[17:19] <hallam> it solves all four sats in about 2 seconds
[17:19] <Laurenceb> haha
[17:19] <hallam> no, what is it?
[17:19] <Laurenceb> madness
[17:19] <Laurenceb> l<dot>blaxter<at>surrey<dot>ac<dot>uk
[17:20] <Laurenceb> Borres position code is confusing and oversimplified
[17:20] <Laurenceb> its very nice to look at
[17:20] <hallam> heh]
[17:20] <Laurenceb> but it doesnt track the receiver clock error
[17:20] <Laurenceb> and the xyz to lat long alt code is nicked out of some ancient book
[17:21] <Laurenceb> and uses the 1924geoid from what I can gather
[17:21] <Laurenceb> my first attempt to track clock error didnt work :-/
[17:21] <Laurenceb> I'm re running it to see what the numbers look like
[17:22] <Laurenceb> hallam: I was looking at arm7
[17:22] <Laurenceb> on psarkfun - cant really find anything fast enough
[17:22] <SpeedEvil> badgerboard?
[17:23] <Laurenceb> wonder if you could reflash a premier camera
[17:23] <Laurenceb> 60MHz
[17:23] <Laurenceb> not fast enough
[17:23] <Laurenceb> premier cameras have arm9
[17:24] <SpeedEvil> Hmm.
[17:25] <SpeedEvil> I wonder...
[17:25] <Laurenceb> probably not worth it
[17:25] <SpeedEvil> How fast do typical cameras read out GPS
[17:25] <SpeedEvil> How fast do typical cameras read out a frame
[17:25] <SpeedEvil> I was wondering about jamming GPS signals onto the bus
[17:25] <Laurenceb> dont know
[17:25] <Laurenceb> but on premier ones its quite slow
[17:26] <Laurenceb> if the camera shakes you can see it
[17:26] <hallam> I think you'd be hard pushed to do real time on an arm7
[17:26] <hallam> maybe track 4 channels if you really optimise
[17:26] <hallam> but acquisition will take ages
[17:27] <hallam> FFT is pretty slow without floating point
[17:28] <Laurenceb> yeah
[17:28] <SpeedEvil> You don't need FFT
[17:28] <Laurenceb> fastrax is on arm9
[17:28] <Laurenceb> hmm this is odd
[17:28] <Laurenceb> my clock offset is slowly drifting - crystal offset
[17:28] <Laurenceb> then theres huge jumps
[17:28] <SpeedEvil> If you're willing to take 20s/channel or so.
[17:28] <Laurenceb> its really weird
[17:29] <hallam> SpeedEvil: that's a pure sequential search?
[17:29] <SpeedEvil> yeah
[17:29] <SpeedEvil> assuming 20ms*1023
[17:29] <hallam> what about frequency space?
[17:29] <SpeedEvil> 1ms*1023 is of course faster if you're happy to live with the higher signal level
[17:29] <SpeedEvil> you don't care
[17:30] <hallam> ?
[17:30] <SpeedEvil> you get one lock signal in 1ms, or 20ms
[17:30] <SpeedEvil> you then look again at it 20ms later, and look at the phase change
[17:30] <SpeedEvil> There's your frequency drift
[17:30] <hallam> I don't think you'll get any correlation at all without getting the carrier freq within a few hundred Hz
[17:31] <Laurenceb> the huge jumps in clock correspond the jumps between leaves of the fern
[17:31] <Laurenceb> its like a fractal
[17:31] <Laurenceb> seriously odd
[17:31] <Laurenceb> fractal positioning oscillation :P
[17:32] <SpeedEvil> hallam: my reasoning.
[17:33] <SpeedEvil> hallam: The recieved signal has to drift by over 0.25 or so chips in 20ms in order for there to start to be major problems locking to it if you have the frequency wrong.
[17:33] <SpeedEvil> err
[17:34] <SpeedEvil> hang on
[17:34] <SpeedEvil> brb
[17:35] <hallam> I figure for a pure sequential search over frequency and code phase with the same CPU usage as continuous tracking, it takes about (240 freq bins) * (2046 code phases) * (4ms integration) = 30 minutes
[17:35] <Laurenceb> hehe
[17:35] <Laurenceb> I looked at acquisition on the blackfin, using s16 multiplication (1 cycle)
[17:36] <Laurenceb> got6 seconds total
[17:36] <Laurenceb> for fine acquisition as well
[17:36] <hallam> per PRN?
[17:36] <Laurenceb> no
[17:36] <Laurenceb> total
[17:36] <Laurenceb> 32 sats
[17:37] <Laurenceb> about 5 going into fine search
[17:37] <Laurenceb> with ephemeris you could get a position in 10 seconds
[17:38] <hallam> how do you reason that?
[17:38] <Laurenceb> hallam: you wrotwe the tracking in asm ?
[17:38] <hallam> not yet
[17:38] <hallam> I will
[17:39] <Laurenceb> tracking.s
[17:39] <Laurenceb> ok
[17:39] <hallam> oh, that was me looking at the compiler output
[17:39] <Laurenceb> hallam: just adding up the cycles
[17:40] <hallam> for a parallel or sequential search?
[17:40] <Laurenceb> parrallel
[17:40] <Laurenceb> with fft
[17:41] <hallam> interesting
[17:41] <Laurenceb> how do I add a network drive in windoze?
[17:41] <hallam> I'll have to look into fixed-point FFTs
[17:41] <hallam> right click my computer
[17:41] <Laurenceb> yeah
[17:41] <Laurenceb> and
[17:43] <Laurenceb> hmf bloody windows
[17:43] <hallam> map network drive
[17:44] <Laurenceb> it doesnt appear
[17:44] <hallam> where are you right clicking?
[17:44] <hallam> you have to right click the icon itself, not in the window
[17:44] <Laurenceb> in the window
[17:44] <Laurenceb> oh
[17:44] <hallam> it's dumb, I know
[17:44] <Laurenceb> thats retarded
[17:50] <Laurenceb> cool ok
[17:50] <Laurenceb> how do I run it?
[17:50] <hallam> have you made the packed.bin file yet?
[17:51] <Laurenceb> no
[17:51] <Laurenceb> not sure how to compile it
[17:51] <hallam> got gcc installed?
[17:51] <Laurenceb> I've stuck it on a server
[17:52] <Laurenceb> I'll ssh into a debian machine
[17:52] <Laurenceb> and gcc it
[17:52] <hallam> if you want to compile it on windows, I highly recommend code::blocks, it's a nice lightweight easy to use IDE and I've included a project file that works with it
[17:52] <hallam> it also automatically installs gcc for windows when you set it up
[17:52] <Laurenceb> ok
[17:52] <Laurenceb> I've used bloodshed c++
[17:52] <Laurenceb> or whatever its called
[17:53] <hallam> but if you want to use plain gcc on linux or whatever, gcc -std=c99 -O3 -lm *.c
[17:54] <Laurenceb> uncomment the first line?
[17:55] <hallam> yeah, and fill in appropriate paths
[17:55] <hallam> turns the 640MB file into a 40MB one :)
[17:56] <Laurenceb> k
[17:57] <Laurenceb> billion errors
[17:57] <Laurenceb> tracking2.c: In function 'track_channel_ms':
[17:57] <Laurenceb> tracking2.c:93: error: 'ChannelState' has no member named 'prn_prompt'
[17:57] <Laurenceb> for example
[17:57] <Laurenceb> add nausium
[17:58] <Laurenceb> actually its mostly related to ChannelState
[17:59] <hallam> delete tracking2.c
[17:59] <Laurenceb> any ideas?
[17:59] <hallam> and tracking3.c
[17:59] <hallam> they're old, I shouldn't have included them
[18:00] <Laurenceb> yeah compiled
[18:00] <hallam> ./a.out
[18:00] <Laurenceb> right... what next
[18:01] <Laurenceb> its tasking forever
[18:02] <Laurenceb> segmentation fault
[18:02] <Laurenceb> Operating on SV 32 @ 37051.0 Hz, code phase 419.75 for 40000 ms
[18:02] <hallam> did you give it the right file names?
[18:03] <Laurenceb> pack_file("../henry.bin","./packed.bin");
[18:03] <hallam> and later on for when it reads packed.bin
[18:03] <Laurenceb> oh course
[18:03] <hallam> it's probably saved it now, so you don't need to pack it again
[18:03] <hallam> that was what took it a while
[18:05] <Laurenceb> got it
[18:05] <Laurenceb> ok, vut now
[18:05] <hallam> did it work?
[18:05] <Laurenceb> looks like it
[18:05] <Laurenceb> it gave me one sat doppler
[18:06] <Laurenceb> Operating on SV 32 @ 37051.0 Hz, code phase 419.75 for 40000 ms
[18:06] <hallam> well actually those are just the default values
[18:06] <Laurenceb> thats all
[18:06] <Laurenceb> right
[18:06] <hallam> then it returned after a second?
[18:06] <Laurenceb> hmm yeah suppose so
[18:07] <Laurenceb> so what the next stage?
[18:08] <hallam> use the matlab stuff
[18:08] <hallam> there's a function LoadCResults
[18:15] <Laurenceb> k
[18:15] <Laurenceb> it runs
[18:15] <Laurenceb> hallam: ping
[18:15] <hallam> hi
[18:16] <hallam> now you can use PlotTrack
[18:16] <Laurenceb> ??? Input argument "cp" is undefined.
[18:18] <fergusnoble> hallam: erm... do i take it from that last statement that you have got position solutions working?!
[18:18] <hallam> PlotTrack(32,cp,cf,codeph)
[18:18] <Laurenceb> where do I get those coefficients
[18:18] <hallam> fergusnoble: no, osrry
[18:18] <hallam> I'll work on that now though
[18:18] <fergusnoble> hehe, ok
[18:18] <hallam> been making things faster instead
[18:18] <fergusnoble> i am free this eve if you want moral support
[18:18] <hallam> cool
[18:19] <Laurenceb> hallam: borres code does a 7 step iteration for each chunk of pseudoranges
[18:19] <hallam> I'm kind of tired but I'll be up another couple hours
[18:19] <Laurenceb> :P
[18:19] <hallam> Laurenceb: LoadCResults loads them into the workspace
[18:19] <hallam> fergusnoble: we can break out the textbook
[18:19] <Laurenceb> so there is no tie in between subsequenct blocks
[18:19] <hallam> oh
[18:19] <hallam> is that whence the jitter?
[18:19] <Laurenceb> hallam: what should I use for the coefficients?
[18:19] <hallam> coefficients?
[18:19] <Laurenceb> hallam: yeah may well be
[18:20] <hallam> cp = prompt correlations, cf = carrier frequency, codeph = code phase
[18:20] <hallam> you should have them in the workspace
[18:20] <Laurenceb> hallam: there are far, far better ways to do it
[18:20] <hallam> Laurenceb: look at / try running go.m
[18:20] <hallam> it shells out to the C program (again you'll have to fix the path)
[18:21] <Laurenceb> yeah, I get an error
[18:23] <Laurenceb> cool
[18:23] <Laurenceb> appears to work
[18:23] <Laurenceb> but erm... where are the databits?
[18:24] <Laurenceb> oh you take abs
[18:25] <Laurenceb> I'll take a look later, going to ze pub in a sec
[18:25] <Laurenceb> hallam: borres code take some sample of code - say 20ms
[18:26] <hallam> zoom in on the top left graph for data bits
[18:26] <hallam> or run Nav to get them cleaned up
[18:26] <Laurenceb> then does a 7 interation postition solutions
[18:26] <Laurenceb> from the pseudoranges
[18:27] <Laurenceb> whats HenryGNSS.exe?
[18:28] <Laurenceb> oh yeah I see them
[18:28] <hallam> what you called a.out
[18:28] <Laurenceb> what dio I use for dos?
[18:30] <hallam> unix() maybe?
[18:30] <Laurenceb> dos works
[18:31] <Laurenceb> this is nice
[18:32] <Laurenceb> ideally you want a kalman filter for position with x,y,z,dtime/dt
[18:32] <Laurenceb> initialised by one borre style newtion raphson iteration
[18:33] <Laurenceb> to get the starting position and delta time
[18:33] <Laurenceb> anyway I'm off
[18:33] <Laurenceb> cya
[18:34] Laurenceb (i=zeusbot@lister.antycip.co.uk) left irc: "leaving"
[18:40] <fergusnoble> hallam: shall i come over?
[18:44] <hallam> sure
[19:20] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-70ea96a6838fdd35) left irc: "http://www.mibbit.com ajax IRC Client"
[20:23] Xenion (n=robert@p579FC53D.dip.t-dialin.net) joined #highaltitude.
[20:40] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[20:40] <edmoore> hi all
[20:41] <edmoore> sorry about that fergusnoble, forgot I'd agreed to do it
[20:41] <edmoore> we had an almost incomprehensibly thickly accented chinese mathmo, running for ents master, promise to 'make pav songs free from grammatical error'
[20:45] <fergusnoble> oh dear
[20:45] <fergusnoble> did you run for anything?
[20:49] <edmoore> no, just had to sum up some of the issues we wanted addressed for different things by the next person for a few or the roles
[21:02] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc:
[21:30] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[22:21] Xenion (n=robert@p579FC53D.dip.t-dialin.net) left irc: "Verlassend"
[22:51] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[23:04] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[23:08] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[23:18] RocketBoy (n=Steve@217.47.75.27) left irc: "Leaving"
[23:21] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[23:24] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Read error: 104 (Connection reset by peer)
[23:24] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) joined #highaltitude.
[23:24] <Laurenceb> what happened?
[23:24] <Laurenceb> no topic
[23:26] <Laurenceb> http://news.bbc.co.uk/1/hi/world/middle_east/7853803.stm
[23:26] <Laurenceb> ^ and what happened there
[23:26] <Laurenceb> since when were they sponsored by hp and google
[23:27] <Laurenceb> like wtf
[23:37] dh (i=dh@bsd.ee) got netsplit.
[23:41] dh (i=dh@bsd.ee) returned to #highaltitude.
[23:42] fergusnoble (n=fergusno@natreg.pem.cam.ac.uk) joined #highaltitude.
[23:43] <Laurenceb> hi fergus
[23:43] <Laurenceb> theres no topic
[23:44] <Laurenceb> wut happened
[23:44] dh (i=dh@bsd.ee) got netsplit.
[23:44] dh (i=dh@bsd.ee) returned to #highaltitude.
[23:44] <fergusnoble> Laurenceb: hi
[23:45] <fergusnoble> netsplit?
[23:45] <fergusnoble> freenod has been bad recently?
[23:45] <Laurenceb> yeah
[23:51] Action: epictetus hmms
[00:00] --- Wed Jan 28 2009