highaltitude.log.20090124

[00:00] <hallam> sure
[00:00] <SpeedEvil> Laurenceb: download something else and pay attention to the box
[00:00] <Laurenceb> is there a way to view the downloaded items folder?
[00:00] <SpeedEvil> Laurenceb: yes, but it doesn't list where it put them
[00:00] <SpeedEvil> Just file - save-as - and see where it puts you
[00:01] <Laurenceb> desktop
[00:01] <Laurenceb> this makes no sense
[00:02] <SpeedEvil> Might you have run out of temp space?
[00:02] <Laurenceb> hmm
[00:02] <Laurenceb> I've just tried again
[00:04] <fergusnoble> hallam: want me to bring anything? laptop?
[00:08] <hallam> sure, if you like
[00:08] <hallam> if we get the tracking code done in C it would be interesting to see how well it works on something slower than my laptop
[00:10] <fergusnoble> hehe, my laptop isnt all that bad :p
[00:10] <fergusnoble> ok, heading over, will ring you when im outside
[00:11] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc:
[00:13] <Laurenceb> ok
[00:13] <Laurenceb> I've extracted fldigi
[00:13] <Laurenceb> but when I run fldigi, I get 2.08 still
[00:14] <hallam> do you run it by typing fldigi, or ./fldigi ?
[00:15] <Laurenceb> ./fldigi
[00:15] <Laurenceb> to run the local one
[00:15] <Laurenceb> oops
[00:15] <Laurenceb> I shouldnt have extracted it in /home/
[00:15] <Laurenceb> where should it be?
[00:15] <Laurenceb> /bin/ ?
[00:16] <hallam> it shouldn't matter
[00:16] <hallam> you can have stuff in home
[00:16] <Laurenceb> hmm
[00:16] <Laurenceb> no libportaudio
[00:18] <SpeedEvil> rjharrison still audio probs?
[00:18] <Laurenceb> theres a version on the site with no pulseaudio dependancy
[00:18] <Laurenceb> but this is portaudio
[00:19] <Laurenceb> hmm I seem to remember this was one reason why I had to build from source
[00:19] <Laurenceb> jcoxon had the same problem on his mac
[00:21] <Laurenceb> libportaudio2 is already the newest version.
[00:21] <Laurenceb> apparently
[00:22] <Laurenceb> ./fldigi: error while loading shared libraries: libportaudio.so.2: cannot open shared object file: No such file or directory
[00:22] <Laurenceb> am I running it from the wrong place?
[00:23] <Laurenceb> /usr/bin ?
[00:34] <Laurenceb> ok... there an fldigi in there, but deleting it makes no difference
[00:35] <Laurenceb> how can I find out where a binary is on the filesystem?
[00:36] <SpeedEvil> which foo
[00:36] <Laurenceb> /usr/local/bin
[00:36] <Laurenceb> arg so many different folders
[00:36] <Laurenceb> thanx
[00:45] <Laurenceb> broke it :(
[00:46] <Laurenceb> I'll ack on ubuntu
[00:49] <natrium42> i installed windows 7 :P
[00:50] <natrium42> but not on my main pc
[00:50] <Laurenceb> bindoze
[00:51] <natrium42> the windows still don't snap to other windows when you resize, grrr
[00:52] rjharrison (n=rharriso@80.176.172.227) left #highaltitude.
[00:52] <natrium42> but at least you can easily tile windows side by side
[00:58] <Laurenceb> hmm
[00:58] <Laurenceb> I dont think this is going to be easy
[00:58] <Laurenceb> think I need portaudio
[00:58] <SpeedEvil> 'hitlers eyes flash' :)
[01:10] <Laurenceb> "secret rabbit code not found"
[01:10] <Laurenceb> wrf
[01:10] <Laurenceb> WTF
[01:11] <Laurenceb> thats got to be a very bad joke
[01:17] <Laurenceb> oh... its an audio up/down sampler
[01:24] <Laurenceb> http://www.mega-nerd.com/SRC
[01:40] <Laurenceb> its compiling *holds breath*
[01:47] <SpeedEvil> Oh no!
[01:47] Action: SpeedEvil calls the ambulance to apply CPR to Laurenceb
[01:48] <Laurenceb> lol
[01:48] <Laurenceb> it compile
[01:48] <Laurenceb> d
[01:48] <Laurenceb> but it doesnt work
[01:48] <Laurenceb> segmentation fault
[01:48] <SpeedEvil> yoy mean just to forex go from 44k1 to 22khz?
[01:48] Action: SpeedEvil uses sox
[01:51] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Read error: 104 (Connection reset by peer)
[01:55] <Laurenceb> awsome
[01:55] <Laurenceb> it works - I had to shutdown flash player as it had hung
[01:55] <Laurenceb> and was blocking the sound card
[02:03] <Laurenceb> ok everything appears to work
[02:03] <Laurenceb> but I cant get anything out of my icom apart from clicks
[02:03] <Laurenceb> I think I need to turn up the gain
[02:58] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[02:59] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[03:01] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[03:47] <Laurenceb> hallam: still aabout?
[04:42] <SpeedEvil> Laurenceb: is this the input samples of the adc?
[04:42] <Laurenceb> SpeedEvil: yeah, I was thinking about how to speed up tracking
[04:42] <Laurenceb> so the PRN is +-1
[04:42] <Laurenceb> so you need to flip the sign
[04:43] <Laurenceb> I was thinking of creating a datatype of two s04
[04:43] <SpeedEvil> multiply incoming bit by 1 or 0
[04:43] <Laurenceb> i.e. two 4 bit signed variables
[04:43] <SpeedEvil> then accumulate
[04:43] <Laurenceb> hmm yeah
[04:43] <SpeedEvil> you end up with 512 or whatever in the null case
[04:43] <Laurenceb> if you do that first
[04:43] <Laurenceb> then the local osc
[04:44] <SpeedEvil> or a large table
[04:44] <Laurenceb> as at the local osc it really helps to manipulate complex types
[04:44] <Laurenceb> yeah, that was my plan for the local osc
[04:44] <SpeedEvil> do it for I and Q channels seperately
[04:44] <Laurenceb> no
[04:44] <Laurenceb> to many operations
[04:45] <Laurenceb> you well be waisting loads of cpu cycles shifting data about
[04:45] <SpeedEvil> look at your CPU instruction set
[04:45] <Laurenceb> yeah
[04:45] <SpeedEvil> and work out what's the most handy instructions
[04:45] <Laurenceb> I need to check out these XMOS thingys
[04:45] <SpeedEvil> and then swear at your C compiler for not emitting them
[04:46] <Laurenceb> if I have 2 bit adcs in
[04:46] <Laurenceb> how do I apply the prn?
[04:46] <SpeedEvil> hmm
[04:46] <Laurenceb> so I need to map 0 to 3
[04:46] <Laurenceb> 1 to 2
[04:47] <Laurenceb> and visa versa
[04:47] <SpeedEvil> pack the bits into a 32 bit word
[04:47] <Laurenceb> yeah
[04:47] <SpeedEvil> use 8 bit table lookup to normalise them
[04:47] <SpeedEvil> or even 16 bit
[04:47] <SpeedEvil> or something like that
[04:47] <Laurenceb> normalise?
[04:47] Action: SpeedEvil should be asleep
[04:48] <SpeedEvil> make it so you don't need to do subtraction
[04:48] <Laurenceb> hmm
[04:48] <Laurenceb> so everything is +ive
[04:48] <Laurenceb> interesting
[04:49] <SpeedEvil> other things to remember
[04:49] <SpeedEvil> 0x1111+0x1232 = 0x2343
[04:49] <SpeedEvil> which can be handy
[04:50] <SpeedEvil> though you rapidly run into overflows if not careful
[04:50] <SpeedEvil> Bitslicing also
[04:51] <SpeedEvil> though that way may lie madness
[04:51] <Laurenceb> whats that?
[04:51] <SpeedEvil> google bitslicing DES
[04:51] <SpeedEvil> basically
[04:51] <SpeedEvil> you make your algorithm into xor, or,and, ... gates
[04:52] <SpeedEvil> and then run it in parallel using the processor as a *32 SIMD machine
[04:53] <Laurenceb> yeah
[04:53] <Laurenceb> this is what I was thinking - for the local osc
[04:53] <Laurenceb> using a data construct of two s04
[04:53] <Laurenceb> one for real, one complex
[04:53] <Laurenceb> and a 16KB lookup table
[04:54] <Laurenceb> stored in 4K 32 bit locations
[04:54] <Laurenceb> but I couldnt work out how to do the prn
[04:54] <Laurenceb> multiplication
[04:54] <Laurenceb> seperately, and efficiently
[04:55] <Laurenceb> without doubling the size of the lookup table
[04:55] <SpeedEvil> have you looked at the noise effect of disregarding the other bit?
[04:55] <Laurenceb> yeah
[04:55] <Laurenceb> at the moment we disregard it
[04:55] <Laurenceb> in the matlab code
[04:56] <SpeedEvil> this is why I was going on about countones
[04:56] <Laurenceb> hehe
[04:56] <Laurenceb> but thats not possible for complex numbers
[04:56] <SpeedEvil> take samples, pack them into the word, xor with a properly oriented PRN, countones
[04:56] <Laurenceb> unless you have a complex instruction
[04:56] <Laurenceb> :P
[04:56] <SpeedEvil> or you deal with I and Q seperately
[04:56] <Laurenceb> no
[04:57] <Laurenceb> as they have to mix together
[04:57] <Laurenceb> if you see what I mean
[04:57] <SpeedEvil> No
[04:57] <Laurenceb> one complex mult is 4 real mults and two additions
[04:57] <SpeedEvil> sorry - not following.
[04:57] <SpeedEvil> What I meant
[04:57] <Laurenceb> try it on paper
[04:58] <SpeedEvil> You have two copies of the PRN, seperated by +-0.25 chips
[04:58] <SpeedEvil> you multiply each of the input bits by both of these copies, and call one I and one Q
[04:59] <SpeedEvil> ah
[04:59] <Laurenceb> its direct downconversion
[04:59] <Laurenceb> you were talking about ~1MHz or more IF
[04:59] <SpeedEvil> tIt works teh same way
[04:59] <Laurenceb> no, as you have a complex local osc
[05:00] <SpeedEvil> it's just that the PRN signal you multiply it to 'rotates'
[05:00] <hallam> hey
[05:00] <Laurenceb> hi hallam
[05:00] <SpeedEvil> It does so even for your chip - it's just it's at 38KHz, not 1MHz
[05:00] Action: hallam was working out how to efficiently do tracking on the Blackfin (which has countones)
[05:00] <Laurenceb> I'm not sure that works
[05:00] <Laurenceb> nice
[05:00] <hallam> for each 1ms sample
[05:00] <Laurenceb> I like the look of the XMOS
[05:01] <SpeedEvil> Laurenceb: I'm pretty syure it does - but I'm not explaing it well - it's too early
[05:01] <hallam> I'm thinking about 1 bit I and 1 bit Q
[05:01] <Laurenceb> gcc for the blackfin?
[05:01] <hallam> exists but sucks
[05:01] <Laurenceb> what are you using?
[05:01] <hallam> gcc for now, maybe the proprietary compiler later
[05:01] <SpeedEvil> Laurenceb: to recap
[05:01] <hallam> and lots of assembler
[05:01] <Laurenceb> is that free?
[05:02] <hallam> the prop. compiler isn't
[05:02] <Laurenceb> :(
[05:02] <hallam> I haven't actually started coding yet
[05:02] <Laurenceb> yeah its tricky
[05:02] <hallam> gcc doesn't suck *too* badly, it just doesn't make good use of the DSP features
[05:02] <Laurenceb> my idea was a datatype of two s04
[05:02] <hallam> for the carrier?
[05:02] <Laurenceb> yes
[05:02] <Laurenceb> real and imag
[05:02] <hallam> right
[05:02] <Laurenceb> then a lookup table
[05:03] <Laurenceb> 4K locations
[05:03] <hallam> then everything else is bit flipping and adding
[05:03] <Laurenceb> yeah
[05:03] <Laurenceb> well
[05:03] <Laurenceb> I cant work out how to do the prn multiplication
[05:03] <hallam> it's just bit flipping
[05:03] <Laurenceb> thats flummoxed me
[05:03] <hallam> if your samples are 1-bit I and 1-bit Q
[05:03] <Laurenceb> well... I was thinking 2 bit samples
[05:03] <hallam> then it's just inverting
[05:04] <Laurenceb> as with the s04 type you can do that
[05:04] <Laurenceb> yeah, but how to do it fast
[05:04] <SpeedEvil> Laurenceb: If you take any I and Q sample, it goes into the resultant total by multiplying and accumulating it with the PRN value times the appropriate values - 0 if it's 90 degrees out of phase, 1 if it's in phase, -1 if it's out of phase
[05:04] <hallam> why would I want to use 2-bit samples? 1-bit works fine
[05:04] <Laurenceb> cuz you can
[05:04] <SpeedEvil> hallam: jam immunity, a bit better SNR
[05:04] <Laurenceb> its more noise tolerant
[05:04] <hallam> not with the blue stick
[05:04] <Laurenceb> its not next to a gsm module
[05:04] <hallam> blue stick only gives 1 bit of I and 1 bit of Q
[05:04] <SpeedEvil> In theory anyway
[05:05] <Laurenceb> if you look at the raw data spectrum, its close to saturating if the ant is on my keyboard
[05:05] <Laurenceb> -laptop
[05:05] <hallam> interesting
[05:05] <hallam> how do you tell when it's saturating?
[05:06] <Laurenceb> the size of the peak(s)
[05:06] <Laurenceb> in the fft
[05:06] <hallam> what's saturation?
[05:06] <Laurenceb> where the noise is driving the adc
[05:06] <Laurenceb> and the gps signal has no room to come in
[05:06] <hallam> yeah but how big are the peaks at that point?
[05:07] <Laurenceb> thick a 8 bit adc always at +-127
[05:07] <Laurenceb> *think
[05:07] <hallam> ok
[05:07] <hallam> some matlab pseudocode?
[05:07] <Laurenceb> hmm say 8*1023 samples
[05:07] <hallam> f=fft(complex_samples);
[05:07] <hallam> plot(f)
[05:07] <Laurenceb> yeah, then abs
[05:07] <hallam> plot(abs(f))
[05:08] <hallam> at what point should I worry?
[05:08] <Laurenceb> a peak of size(samples)*2
[05:08] <hallam> ok
[05:08] <Laurenceb> or anything close to that
[05:08] <Laurenceb> i.e. within an order of magnitude is starting to get worrying
[05:08] <Laurenceb> just a sec I'll look at my data
[05:09] <hallam> a peak or lots of peaks?
[05:10] <Laurenceb> hmm it gets tricky
[05:10] <Laurenceb> as the peaks have bandwidths
[05:10] <SpeedEvil> the GPS signal-noise drops in the case that it's mostly saturated.
[05:10] <Laurenceb> and you have several peaks
[05:10] <Laurenceb> maybe the total area under the noise peaks
[05:11] <SpeedEvil> but the signal still gets in by pushing up or down on marginal bits
[05:11] <Laurenceb> yeah
[05:11] <SpeedEvil> he more bits you have the more jam resistant you are
[05:11] <hallam> ok let's consider the nice mesh plots from the acq routine
[05:11] <hallam> correlation vs code phase and freq
[05:12] <hallam> as the noise increases, the size of the peak from a satellite stays the same, but the rest of the peaks increase?
[05:12] <hallam> and when they're similar magnitude, you start to worry
[05:12] <hallam> do I have that right?
[05:12] <SpeedEvil> hallam: unless you saturate it
[05:12] <SpeedEvil> hallam: if it's saturated, the main peak falls too
[05:13] <hallam> so saturation would occur before the noise reached as high as the satellite peak?
[05:13] <SpeedEvil> as there are times it's not recieving the GPS signal, it's pinned to one side or the other
[05:13] <SpeedEvil> umm
[05:13] <SpeedEvil> yes
[05:13] <hallam> ok
[05:13] <SpeedEvil> well - it'll be saturated at some fraction of the time by random noise anyway
[05:13] <hallam> ok
[05:14] <SpeedEvil> As you increase that fraction, the amount of time you can recieve a GPS signal drops
[05:14] <hallam> so more ADC bits does two things
[05:14] <hallam> 1. decrease quantisation noise, moving the noise floor lower
[05:14] <SpeedEvil> yes
[05:14] <hallam> 2. increase the limit at which the noise starts to bring the SV peak down due to saturation
[05:14] <SpeedEvil> especially in the face of the AGC stopping down the gain
[05:14] EarlJr (n=earljr@66-230-111-65-rb1.nwc.dsl.dynamic.acsalaska.net) joined #highaltitude.
[05:15] <Laurenceb> yeah i
[05:15] <SpeedEvil> I diddn't think about the AGC at first - that will probably have an effect meaning that only very bursty waveforms saturate
[05:15] <SpeedEvil> and then only some of the time
[05:15] <SpeedEvil> but it still drops the effective signal level lots
[05:16] <SpeedEvil> SAW filter at the frontend helps with near-band noise
[05:17] <hallam> would you expect better results with 8MSamples/s and 2 bit samples, or 4MS/s and 4-bit samples?
[05:17] <Laurenceb> yeah AGC is important
[05:17] <SpeedEvil> I would expect them to be almost equivalent on first thoughts
[05:18] <SpeedEvil> err
[05:18] <SpeedEvil> no, 4 bits better
[05:18] <SpeedEvil> I think
[05:18] <Laurenceb> so... you need to get your data (stored using DMA from the SPI?) into a usable form first, which will involve some bit shifting ect
[05:18] <hallam> because the signal is only 2MHz bandwidth?
[05:18] <Laurenceb> that will use a bit of cpu :-/ bu tmaybe the PRN multiplication could come in there
[05:18] <hallam> Laurenceb: if I keep it in 1-bit I and Q, no bit shifting needed
[05:18] <SpeedEvil> Laurenceb: can always use a little TTL
[05:18] <Laurenceb> argmy machine is dying
[05:19] <SpeedEvil> hallam: I was thinking that the total bit depth you have overwhelms the small gain you get from faster sampling
[05:20] <SpeedEvil> hallam: My initial thought was based on the assumption that you could add the 2 bit samples to get 4 bit samples - which was only because it's so early - you can of course only get 3 bit that way
[05:22] <hallam> well when I say 2 bit samples, I mean 1 bit of I and 1 bit of Q
[05:22] <hallam> does that make any difference?
[05:22] <SpeedEvil> yes, I think so
[05:22] <SpeedEvil> they are not independant
[05:22] <SpeedEvil> consider that they were equally spaced
[05:23] <SpeedEvil> at 1us or something
[05:23] <SpeedEvil> you can't make 2 bit samples at 500KHz from 1 bit samples at 1MHz
[05:23] <hallam> even with dithering?
[05:23] <hallam> I thought the noise gave natural dithering
[05:23] <SpeedEvil> if you add them, you only get 0-2 not 0-3
[05:23] <hallam> oh okay
[05:24] <hallam> so you get 1.5-bit samples
[05:24] <SpeedEvil> more or less
[05:24] <SpeedEvil> 1.414 bit?
[05:24] Action: SpeedEvil forgets
[05:24] <hallam> ok
[05:24] <hallam> so 4MS/s and 4-bit is better
[05:24] <hallam> but it makes the computation much harder
[05:25] <hallam> and I think I'm CPU-bound
[05:25] <SpeedEvil> You mean 2 bit samples?
[05:25] <SpeedEvil> Well...
[05:25] <hallam> yeah 2-bit I, 2-bit Q
[05:25] <SpeedEvil> There is better, and better
[05:25] <hallam> I've been doing all my MATLAB work with 1-bit I and 1-bit Q, and it seems to work okay
[05:25] <SpeedEvil> do you actually care about low noise performance, and absolutely best possible aqccuracy
[05:25] <hallam> the flight environment may or may not be noiser
[05:26] <hallam> there are high dynamics, and I'm not very good at RF PCB design, and there's a 500MHz CPU vaguely nearby
[05:26] <hallam> that is, near the front-end, not near the antenna
[05:26] <SpeedEvil> This is why god gave us metal boxes.
[05:26] <hallam> well still vaguely near the antenna, but cm rather than mm
[05:27] <hallam> btw I got the can off the blue stick
[05:27] <SpeedEvil> Put the front-end in a metal box, with appropriate ferrite beads
[05:27] <hallam> on everything but the RF in?
[05:27] <SpeedEvil> yeah
[05:28] <SpeedEvil> and use an amplified antenna
[05:28] <hallam> that's the plan
[05:28] <hallam> nice as it would be to use a chip antenna on the PCB
[05:28] <hallam> I fear it's not up to the task
[05:28] Laurenceb_winxp (i=83e3dd23@gateway/web/ajax/mibbit.com/x-456c267e1b0f7919) joined #highaltitude.
[05:28] <Laurenceb_winxp> hi
[05:28] <Laurenceb_winxp> what did I miss
[05:29] <SpeedEvil> we solved the halting problem.
[05:29] <Laurenceb_winxp> lol
[05:29] <SpeedEvil> Nothing much
[05:29] <Laurenceb_winxp> hallam: do you have spi on the blackfin?
[05:29] <hallam> yeah
[05:29] <Laurenceb_winxp> how many bons? 8?
[05:29] <Laurenceb_winxp> *bits
[05:30] <hallam> er
[05:30] <hallam> maybe 16, I don't know
[05:30] <hallam> and I don't care because it's DMAed straight into RAM
[05:30] <Laurenceb_winxp> ok yeah
[05:30] <Laurenceb_winxp> how much ram is there?
[05:30] <hallam> I also have two general purpose sync serial ports
[05:30] <SpeedEvil> check if the DMA steals cycles
[05:30] <hallam> it doesn't
[05:30] <Laurenceb_winxp> its dma
[05:31] <hallam> it slows down your program's access to external ram, of course
[05:31] <SpeedEvil> DMA can steal cycles from the processor due to bus contention
[05:31] <Laurenceb_winxp> ok yeah
[05:31] <hallam> but it has a separate bus to the L1 ram
[05:31] <Laurenceb_winxp> nice
[05:31] <Laurenceb_winxp> how much L1 ram is there?
[05:31] <hallam> about 128kB
[05:32] <Laurenceb_winxp> hmf
[05:32] <hallam> plenty for tracking
[05:32] <Laurenceb_winxp> I did have a design using 128 lookup
[05:32] <Laurenceb_winxp> nvm
[05:32] <Laurenceb_winxp> ooh hang on
[05:32] <hallam> even external ram access is fairly fast though
[05:33] <Laurenceb_winxp> no 8KB
[05:33] <Laurenceb_winxp> ok, heres how it works
[05:33] <SpeedEvil> All you need for a _really_ fast solution is a 4000 bit lookup table :)
[05:33] <Laurenceb_winxp> 1 bit is the prn, 4 signed real local osc, 4 signed limag local osc, 2 bit I sample
[05:34] <Laurenceb_winxp> then you use the 2 bit Q sample to read out the correct byte of the 32 bit reult
[05:34] <Laurenceb_winxp> so thats 8*4KB
[05:34] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) left irc: Read error: 145 (Connection timed out)
[05:34] <Laurenceb_winxp> 32KB
[05:34] Nick change: Laurenceb_winxp -> Laurenceb
[05:35] <hallam> hmmm
[05:35] <SpeedEvil> isn't that 32K per sat?
[05:35] <Laurenceb> local osc values themselves come from a 8 byte lookup
[05:35] <SpeedEvil> err - no
[05:35] <Laurenceb> no, this is general perpose
[05:35] <Laurenceb> everything can use this
[05:35] <Laurenceb> erm 256 byte lookup even - for local osc
[05:36] <Laurenceb> so you need 4M acesses per second per channel
[05:36] <SpeedEvil> I think I'm going to sleep - will read backscroll. Night.
[05:36] <Laurenceb> me too actually
[05:37] <hallam> Laurenceb: you still need to do that lookup once per sample, right?
[05:37] <Laurenceb> yeah
[05:37] <Laurenceb> but isnt it like a couple of clocks?
[05:38] <hallam> prolly
[05:38] <Laurenceb> or 4 or 5 even
[05:38] <hallam> with 1-bit samples though, you can process 32 samples at a time
[05:38] <Laurenceb> you have around a hundered to play with
[05:38] <Laurenceb> how come?
[05:39] <hallam> I think you have of order 10 clocks per sample
[05:39] <Laurenceb> :/
[05:39] <Laurenceb> 40MHz?
[05:40] <Laurenceb> sample=I and Q 2 bits
[05:40] <hallam> (500MHz / 5 * 1 millisecond) / (8184 samples)
[05:41] <hallam> = 12 clocks per 2-bit sample
[05:41] <hallam> the 5 is for 5 channels
[05:41] <Laurenceb> ah ok
[05:41] <hallam> so with my metho
[05:41] <hallam> d
[05:41] <Laurenceb> which is?
[05:42] <hallam> let's pretend we have deinterleaved I and Q data, maybe it can work with it interleaved but let's pretend for now
[05:42] <hallam> packed into 32-bit words
[05:42] <Laurenceb> ah ok
[05:42] <Laurenceb> yeah I was thinking of this
[05:42] <Laurenceb> it makes it a lot simpler
[05:42] <Laurenceb> just need a quick way to upconvert
[05:42] <Laurenceb> to 1.5MHz or so
[05:43] <hallam> what for?
[05:43] <Laurenceb> I know
[05:43] <Laurenceb> the method I described :P
[05:43] <Laurenceb> only simpler and only one channel to run
[05:43] <hallam> I don't understand
[05:43] <Laurenceb> hallam: you have a complex sample, IF~0
[05:43] <Laurenceb> we want a real, IF~1.5MHz
[05:44] <Laurenceb> then we can search through many samples at a time
[05:44] <Laurenceb> and no complex maths
[05:44] <Laurenceb> so you upconvert the samples
[05:44] <Laurenceb> using a simple lookup table
[05:44] <hallam> they sell receiver ICs with IF ~1.5MHz
[05:45] <hallam> but I don't understand how that helps
[05:45] <Laurenceb> yeah, but we have SE4120 frontends
[05:45] <Laurenceb> and they dont need SAW filters
[05:45] <hallam> if we're building embedded solutions, we can choose whichever front end we like
[05:45] <hallam> though the 4120 is nice
[05:45] <Laurenceb> yeah
[05:45] <Laurenceb> and the 1.5MHz ones prob have saw built on
[05:45] <Laurenceb> havent really looked
[05:46] <Laurenceb> ok, so you can premultiply the PRN by the local osc, which is now real
[05:46] <Laurenceb> and maybe just have 1 bit resolution
[05:46] <Laurenceb> then XOR
[05:46] <Laurenceb> 32 bit words together
[05:46] <Laurenceb> and add
[05:47] <hallam> yeah
[05:47] <hallam> why doesn't that work with IQ at 0 IF?
[05:47] <Laurenceb> as you have to do complex arithmetic
[05:47] <hallam> do it once for the I channel of samples and LO, once for the Q channel
[05:47] <Laurenceb> hmm I'll look
[05:47] <Laurenceb> maybe it does work
[05:47] <Laurenceb> I'm confused
[05:49] <Laurenceb> hmm you want to be able to run a costas loop as well
[05:49] <Laurenceb> oh crap
[05:49] <hallam> ?
[05:49] <Laurenceb> the borre code for the SE4110
[05:49] <hallam> the costas loop isn't exactly CPU intensive, is it?
[05:50] <Laurenceb> which is 1.5MHz
[05:50] <Laurenceb> downconverts to zero if
[05:50] <hallam> yeah?
[05:50] <hallam> oh
[05:50] <hallam> heh
[05:50] <Laurenceb> digitally
[05:50] <Laurenceb> then runs in the same way as the SE4120 code
[05:50] <Laurenceb> hmm I'm not sure how to do the PLL
[05:50] <Laurenceb> costas loop works nicely
[05:51] <Laurenceb> the GP2021 is similar again
[05:51] <hallam> oh right, if you only have real samples
[05:51] <Laurenceb> (hardware gps correlator asic)
[05:51] <hallam> I'm stickign with my 0Hz IF 1-bit I, 1-bit Q
[05:52] <Laurenceb> in which case I think you need complex arithmetic
[05:52] <Laurenceb> yeah, speedevils approach is good for the dll
[05:52] <Laurenceb> but for the pll I dont get it...
[05:53] <Laurenceb> unless you multiply by two local carriers
[05:53] <Laurenceb> sin and cos
[05:53] <Laurenceb> and find the phase over the interval, but thats a lot more work
[05:53] <Laurenceb> or maybe not...
[05:54] <hallam> yeah that's the plan
[05:54] <hallam> I'm wondering how much noise performance you'd lose by using a carrier that's 1 bit I, 1 bit Q
[05:54] <Laurenceb> quite a bit
[05:56] <Laurenceb> hmm I'm wondering if you can have 4 accumulator bins
[05:56] <Laurenceb> signal comes in, has the prn taken off
[05:57] <Laurenceb> giving I_s and Q_s, then these are multiplied by I_l and Q_l
[05:58] <Laurenceb> then you have two real bins and two imaginary
[05:58] <Laurenceb> you sum them at the end
[05:59] <Laurenceb> I_l and Q_l are 1 bit
[06:00] <hallam> how do you do the LO mixing?
[06:00] <Laurenceb> a 1 bit sample xor with a 1 bit is the same as +-1 with a +-1, so we lose nothing in the PRN multiplication
[06:00] <Laurenceb> that is the LO mixing
[06:00] <hallam> I'm with you up to taking off the PRN, how does the next part work?
[06:00] <Laurenceb> so our LO is two square waves, I and Q, 90 degree out of phase
[06:01] <hallam> ok, so it's a 1-bit LO
[06:01] <Laurenceb> no 2 bit
[06:01] <Laurenceb> as you have real and imaginary
[06:01] <hallam> 1 bit I, 1 bit Q
[06:01] <hallam> ok
[06:01] <Laurenceb> yeah
[06:01] <hallam> that's what I was asking, how much do you lose with that versus say a 3-bit LO
[06:01] <Laurenceb> then you XOR and dump into 4 bins
[06:01] <hallam> I figure much more than that doesn't get you anything
[06:02] <hallam> why not dump into 2 bins?
[06:02] <Laurenceb> I'd say you're not going to lose a huge amount more than you alread have
[06:02] <Laurenceb> lose, through going to 1 bit
[06:02] <Laurenceb> hallam: yeah
[06:02] <Laurenceb> ignore the 4, just real and imaginary bins
[06:02] <hallam> I_bin=sum(I_lo * I_samp * PRN)
[06:02] <hallam> er, +=
[06:03] <hallam> then you can use countones
[06:03] <hallam> well I'll just test that out with matlab
[06:03] <Laurenceb> dont forget there are 4 operations
[06:04] <Laurenceb> so there is an instruction to xor two words and return the number of nonzero bits?
[06:05] <Laurenceb> damnit, I've got to try this in matlab now
[06:05] <Laurenceb> just round th elocal osc to +-1
[06:06] Action: Laurenceb listens to 5 live on his icom
[06:09] <hallam> kept lock on 3 of the 4 sats
[06:09] <hallam> lost the other one
[06:09] <hallam> maybe i'll bring it back with some tuning of the loop filters
[06:09] <Laurenceb> I'll see what the position looks like in about 10 minutes
[06:09] <hallam> bedtime now though
[06:09] <Laurenceb> hehe
[06:09] <Laurenceb> cya
[06:09] <hallam> well not quite yet
[06:09] <hallam> to answer your question
[06:09] <hallam> you can at least do that in 2 instructions, maybe in 1
[06:10] <Laurenceb> ok nice
[06:10] <Laurenceb> that should make it pretty possible
[06:11] <hallam> any idea how best to tell if the signal was lost due to carrier or PRN?
[06:12] <Laurenceb> plot the prn phase
[06:12] <Laurenceb> and pll freq, v time
[06:12] <Laurenceb> carrsig = exp(i .* trigarg(1:blksize));
[06:12] <Laurenceb> how can I make it round the real and imag parts to +-1?
[06:13] <hallam> carrier_i=sign(real(carrier)); carrier_q=sign(imag(carrier)); carrier=i*carrier_q + carrier_i;
[06:13] <hallam> could be in one instruction if you prefer
[06:13] <Laurenceb> ah sign
[06:13] <Laurenceb> need to learn more matlab
[06:15] <Laurenceb> does that have to be a vector + ?
[06:15] <hallam> no such thing
[06:16] <Laurenceb> right
[06:16] <Laurenceb> I was thinking like a.*b
[06:16] <hallam> oh
[06:16] <hallam> even easier
[06:16] <hallam> you can just do carrier=sign(carrier);
[06:16] <hallam> sign will operate on both the real and imag parts
[06:16] <Laurenceb> oh cool
[06:17] <Laurenceb> running
[06:17] <Laurenceb> this will take ~8 minutes
[06:18] <hallam> whose code, how many satellites for how long?
[06:18] <Laurenceb> borres code, with lots of modifications
[06:18] <Laurenceb> your set of sats, tracking for 40 seconds
[06:18] <Laurenceb> and looking for all 32 to start off with
[06:19] <Laurenceb> not sure what its running on, some debian machine
[06:19] <Laurenceb> I'm using X forwarding
[06:19] <hallam> oh ok
[06:19] <hallam> you're doing acq on 32 sats, that'll take a bit
[06:20] <Laurenceb> its searched about 20 so far
[06:20] <hallam> just the tracking on mine takes about 5 minutes for 4 sats over 40 sec
[06:20] <hallam> first two sats tracked okay
[06:21] <Laurenceb> hope I didnt screw it up
[06:21] <hallam> :)
[06:21] <hallam> it's a race!
[06:21] <Laurenceb> should have test run for ~1 second first
[06:21] <hallam> well, if it's a race to a position output you'll win
[06:21] <hallam> I should get around to hacking borres' code to work with that
[06:22] <Laurenceb> be interesting to see how the position changes
[06:22] <Laurenceb> I need to find some geoid code and stick it in to get a MSL height
[06:22] <hallam> so
[06:22] <hallam> you xor 32 bits of I samples with 32 bits of PRN with 32 bits of carrier
[06:23] <hallam> countones
[06:23] <hallam> repeat for Q
[06:23] <Laurenceb> yeah
[06:23] <hallam> repeat 256 times
[06:23] <hallam> bob's your uncle
[06:23] <Laurenceb> but when you do it with carrier, remember the carrier is complex
[06:23] <hallam> 3rd sat tracked ok
[06:23] <Laurenceb> you have real and imag carrier
[06:23] <hallam> come on SV32, you're the weak one
[06:23] <hallam> yeah
[06:24] <Laurenceb> as they are just square waves 90 degrees out of phase
[06:24] <hallam> but you only xor sample I with carrier I, and sample Q with carrier Q
[06:24] <Laurenceb> theres got to be simplifications you can make
[06:24] <Laurenceb> no
[06:24] <hallam> to generate the carrier?
[06:24] <Laurenceb> square wave to gen the carrier
[06:24] <hallam> yeah
[06:24] <Laurenceb> but you got the multiplication bit wrong
[06:24] <hallam> that's not so tricky
[06:24] <hallam> I did?
[06:24] <Laurenceb> imagine multiplying two complex numbers
[06:25] <hallam> oh right
[06:25] <Laurenceb> there 4 mults, 2 additions
[06:25] <hallam> expansion
[06:25] <hallam> bugger
[06:25] <hallam> ok so write a lookup table and look for simplifications
[06:25] <Laurenceb> still works the same
[06:25] <Laurenceb> countones
[06:25] <Laurenceb> but you need to do more work
[06:25] <Laurenceb> twice as much
[06:26] <Laurenceb> i*r, i*i, r*i, r*r
[06:26] <hallam> yeah
[06:26] <Laurenceb> dumping into the real and imag bins as you go
[06:26] <hallam> it works with all 4 sats!!
[06:27] <Laurenceb> nice
[06:27] <Laurenceb> what did you change?
[06:27] <hallam> carrier=sign(carrier) instead of the previous one
[06:27] <Laurenceb> oh i*i need to be -ive
[06:27] <hallam> because the previous one changed the magnitude
[06:27] <Laurenceb> so maybe a seperate bin
[06:27] <Laurenceb> and subtract at the end
[06:27] <hallam> abs(1+i) > 1
[06:27] <hallam> which affected the loop gains
[06:27] <Laurenceb> oh course
[06:28] <hallam> now the tricky thing
[06:28] <hallam> is that we also have to do this with the earlyminuslate prn
[06:28] <hallam> which is a bit of a bugger
[06:28] <Laurenceb> drat
[06:28] <Laurenceb> have to have early, late and prompt
[06:28] <hallam> but
[06:28] <hallam> you only need to keep track of the real part of it
[06:29] <Laurenceb> but, you can run the best filters like that
[06:29] <hallam> why can't you have early-late?
[06:29] <Laurenceb> need signed types
[06:29] <hallam> hm
[06:29] <hallam> but we have signed anyway for the prompt correlation
[06:29] <hallam> oh wait, I see what you mean
[06:29] <hallam> nm
[06:29] <Laurenceb> ealry-late=0,+-1
[06:30] <hallam> unless you also downsample the early minus late
[06:30] <Laurenceb> no, thats gong to far
[06:30] <Laurenceb> what do you stick in for 0 ?
[06:30] <hallam> sounds like a challenge to me
[06:30] <hallam> you alternate sticking in 1 and -1
[06:30] <Laurenceb> a square wave?
[06:30] <Laurenceb> noo
[06:30] <Laurenceb> its going to correlte with random crap
[06:30] <hallam> only very rare random crap
[06:31] <Laurenceb> seperate complex early,late and prompt allows better filters
[06:31] <hallam> I'd better try it
[06:31] <Laurenceb> decoherent filtering
[06:31] <Laurenceb> you dont need a pll lock
[06:32] <Laurenceb> guess you could stick in 010101
[06:32] <Laurenceb> omg
[06:32] <Laurenceb> this will work
[06:32] <Laurenceb> as 0101010 is 4MHz
[06:32] <Laurenceb> which is filtered out in the frontend
[06:32] <Laurenceb> by the lowpass filter
[06:32] <Laurenceb> wow
[06:32] <Laurenceb> 01010101 is effectively 0
[06:33] <Laurenceb> hehe awsome
[06:35] <Laurenceb> hmm tracking 2nd sat
[06:36] <hallam> will it still work at a 4MHz sampling frequency instead of 8MHz?
[06:37] <Laurenceb> yeah 2MHz is a null point in th espectrum
[06:37] <hallam> cool
[06:37] <hallam> just trying to figure out how to do this in matlab
[06:38] <Laurenceb> you could do it with seperate early and late, and no prompt
[06:38] <Laurenceb> but this is way cooler
[06:38] <hallam> working so far
[06:39] <hallam> have to wait until it gets to a weak sat
[06:39] <Laurenceb> so in, flip with prn or prn early-late, then xor and countones into three bins
[06:39] <hallam> this is awesome
[06:39] <Laurenceb> real, imag and i*i
[06:39] <Laurenceb> at the end, subtract i*i from real
[06:39] <Laurenceb> oh 6 bins
[06:40] <Laurenceb> 3 for each of prompt or early-late
[06:41] <Laurenceb> onto 3rd sat here
[06:41] <hallam> is yours with the 1-bit earlyminuslate?
[06:42] <Laurenceb> fraid not
[06:42] <hallam> mine is, and just finished the first 2 sats
[06:42] <Laurenceb> it uses seperate early late and prompt
[06:42] <Laurenceb> nice
[06:42] <Laurenceb> its tracking them?
[06:42] <hallam> yeah
[06:42] <Laurenceb> have you got graphs?
[06:42] <hallam> no graphs until they're all done
[06:43] <hallam> but it would have said if it had lost lock
[06:43] <Laurenceb> ok
[06:43] <Laurenceb> yeah, no graphs here till its finished
[06:43] <hallam> my lock detector is pretty crude but usually works
[06:43] <Laurenceb> 2.5 tracked so far
[06:43] <hallam> same
[06:43] <hallam> I should really get it to draw graphs as it goes
[06:44] <Laurenceb> mine has a "tracking" bar
[06:45] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[06:45] <Laurenceb> 1 M xor countones per channel I find
[06:46] <hallam> that sounds high
[06:46] <hallam> ok with my DLL
[06:46] <Laurenceb> 32/(4*2*4)
[06:46] <hallam> oh, 1M per second?
[06:46] <Laurenceb> yes
[06:47] <Laurenceb> is what you need
[06:47] <hallam> not bad
[06:47] <hallam> done all 4, kept lock
[06:47] <hallam> this is sexy
[06:47] <hallam> hm I'll just try it at 4MS/s
[06:47] <Laurenceb> hmf
[06:47] <Laurenceb> mines still on the third
[06:47] <Laurenceb> how many seconds are you processing?
[06:47] <hallam> 40
[06:48] <Laurenceb> grrr
[06:48] <Laurenceb> slow code
[06:48] <hallam> or slow CPU
[06:49] <Laurenceb> oh just remembered, at 1KHz the nav solution takes a while
[06:49] <hallam> I bet, but we don't need nav otuputs at 1kHz
[06:49] <hallam> not in real time
[06:49] <hallam> couldn't telemeter them down that fast
[06:50] <hallam> and I'm logging the raw IQ data anyway (Fergus figured out a way to do that without any burden on the blackfin)
[06:50] <Laurenceb> using dma?
[06:50] <hallam> nah
[06:50] <hallam> there's an ARM coprocessor anyway for the IMU, radio and SD card
[06:51] <hallam> you pipe the IQ data direct to that as well as to the Blackfin
[06:51] <Laurenceb> ok, so spi-dma
[06:52] <hallam> now
[06:52] <hallam> is there a way to do it without deinterleaving the IQIQIQ samples?
[06:52] <hallam> first instinct is that you have to deinterleave them at some point, but..
[06:52] <Laurenceb> well not for the prn
[06:53] <Laurenceb> hmm
[06:53] <hallam> you could store a stretched PRN
[06:53] <Laurenceb> the problem is the lo
[06:53] <hallam> I think there's a single instruction to deinterleave them
[06:54] <hallam> I'd just rather not have to use it
[06:54] <Laurenceb> why not?
[06:54] <Laurenceb> and whats the instruction?
[06:54] <Laurenceb> ok... you can do it without deinterleaving if you can accept twice as many operations
[06:55] <Laurenceb> thats not a good solution
[06:55] <hallam> hm, maybe this instruction doesn't exist, but you can do it with two EXTRACTs
[06:56] <Laurenceb> interesting
[06:56] <Laurenceb> how long have you spent reading the datasheet
[06:56] <Laurenceb> :P
[06:56] <hallam> it's 1034 pages just for the core datasheet, give me a chance :P
[06:56] <Laurenceb> you only have to do it once rember
[06:56] <Laurenceb> not too bad
[06:56] <Laurenceb> avr is about that
[06:56] <Laurenceb> I have the entire mega168 datasheet in paper
[06:57] <hallam> hmm
[06:57] <Laurenceb> you can do it with two xors
[06:57] <hallam> two extracts works, but it gives it to you in 16-bit chunks instead of 32
[06:57] <Laurenceb> but thats a huge waste
[06:57] <hallam> so you still end up doing twice the operations
[06:58] <Laurenceb> yeah but you join the 16 bit chunks
[06:58] <hallam> how does it work with two xors and why is that a waste?
[06:58] <Laurenceb> you xor with interleaved real and imag
[06:58] <Laurenceb> i.e. one at a time
[06:58] <Laurenceb> oh crap
[06:58] <Laurenceb> no
[06:58] <Laurenceb> yeah its possible
[06:59] <Laurenceb> you xor and countones into the real and imag bins
[07:00] <hallam> btw with 4MS/s (or rather, decimated 8MS/s), 1-bit eml and 1-bit carrier, I can track the first 3 sats and the 4th for a couple of seconds, which suggests maybe fiddling with loop filters will bring it back
[07:00] <Laurenceb> and arrange it so you are effectively operating on real and imag data at the same time and adding
[07:00] <Laurenceb> ok
[07:00] <hallam> hm, can you describe more?
[07:00] <Laurenceb> I only just grasp it in my own head
[07:00] <Laurenceb> just a sec
[07:00] <hallam> hehehe
[07:00] <hallam> paper
[07:00] <hallam> paper is nice
[07:00] <Laurenceb> yeah
[07:00] <Laurenceb> draw out the flow diagram for complex multiplication
[07:01] <Laurenceb> you see our new real is the sum of two multiplications
[07:01] <Laurenceb> same for our complex result
[07:01] <Laurenceb> erm imaginary result
[07:01] <Laurenceb> now if we interleave the data
[07:02] <Laurenceb> we can do both of those at once
[07:02] <Laurenceb> by interleaving the lo appropriately
[07:02] <Laurenceb> we can make i*i -ive by inverting the phase... i think
[07:02] <Laurenceb> hmm not 100% sure
[07:03] <hallam> (a+bi)*(c+di) = (ac-bd) + (ad+bc)i
[07:03] <hallam> that's 4 multimplications isn't it?
[07:03] <Laurenceb> yeah
[07:03] <Laurenceb> so we do this twice
[07:03] <hallam> oh ok, 2 for I and 2 for Q
[07:03] <Laurenceb> once dumping into real bin
[07:03] <Laurenceb> once into imag bin
[07:04] <Laurenceb> I'm just not sure about i*I
[07:04] <Laurenceb> erm i*i
[07:05] <Laurenceb> hmm but i*-i=1
[07:05] <Laurenceb> and we kind of say 0=-1 1=1
[07:05] <Laurenceb> so inverting the phase has the same result
[07:05] <Laurenceb> need to try the algebraically
[07:06] <Laurenceb> if i*i was suddently to equal 1, and we multiply complex sinusoids.... does it still work if we invert phase of the sin in the i*i
[07:06] <Laurenceb> yes it does
[07:06] <Laurenceb> sin(-x)=-sin(x)
[07:07] <Laurenceb> ok, so you can do it in two
[07:07] <hallam> I'm not really following, but keep talking :)
[07:07] <hallam> let's start from a word of samples
[07:07] <Laurenceb> so... this doesnt speed up the M xors /sec /channel
[07:07] <hallam> IQIQIQIQIQIQIQIQIQIQIQIQIQIQIQIQ
[07:07] <hallam> that's 16 each of I and Q
[07:07] <Laurenceb> but avoid deinterleaving
[07:08] <Laurenceb> yeah
[07:08] <Laurenceb> try it with 32, easier to explain
[07:08] <Laurenceb> oh sorry
[07:08] <hallam> 32 bits
[07:08] <Laurenceb> ignore me
[07:08] <Laurenceb> ye
[07:08] <hallam> you have a stretched copy of the PRNprompt and PRNeml
[07:08] <Laurenceb> yes
[07:08] <hallam> like PPppPPppPPppPPppPPppPPppPPppPPpp
[07:08] <Laurenceb> with the bit flipping=0 business
[07:09] <hallam> yeah
[07:09] <hallam> so lets call those words Samples, PRNprompt and PRNeml
[07:09] <hallam> they're all 32 bits and interleaved
[07:09] <Laurenceb> yeah
[07:09] <hallam> what next?
[07:09] <hallam> well first you xor Samples with PRNprompt and PRNeml
[07:09] <Laurenceb> yes
[07:10] <hallam> giving SamplesPrompt and SamplesEML
[07:10] <Laurenceb> yep
[07:10] <hallam> now explain how the LO works as if I'm stupid
[07:10] <Laurenceb> then you xor and countones SamplesPrompt into real and imag bins
[07:11] <Laurenceb> same for SamplesEML
[07:11] <hallam> huh?
[07:11] <hallam> before mixing with the LO?
[07:11] <Laurenceb> what you xor with is an interleaved and phase shifted copy of the lo square wave
[07:11] <hallam> oh ok
[07:11] <hallam> how is it phase shifted?
[07:12] <Laurenceb> erm the I of the lo for I is shifted by pi
[07:12] <Laurenceb> they are both interleaved
[07:12] <hallam> okayyyy
[07:12] <Laurenceb> 6xors
[07:12] <Laurenceb> 4 countones
[07:13] <hallam> are you doing the square wave = 0 trick with the LO too?
[07:13] <Laurenceb> maybe
[07:13] <hallam> I don't totally get it yet
[07:13] <Laurenceb> yeah guess you could, to get 1,0,-1
[07:14] <hallam> so for the correlator outputs you need 6 bins as you say
[07:15] <Laurenceb> no
[07:15] <Laurenceb> 4
[07:15] <Laurenceb> EML and prompt I and Q
[07:15] <hallam> wait
[07:16] <hallam> PromptI = sum(PRNprompt * (Isample * Icarrier - Qsample * Qcarrier))
[07:16] <hallam> PromptQ = sum(PRNprompt * (Isample * Qcarrier + Qsample * Icarrier))
[07:16] <Laurenceb> yeah
[07:16] <hallam> EML_I = sum(PRNprompt * (Isample * Icarrier + Qsample * Qcarrier))
[07:17] <hallam> er sorry
[07:17] <hallam> EML_I = sum(PRNeml * (Isample * Icarrier + Qsample * Qcarrier))
[07:17] <hallam> so the bins are PRNprompt*Isample*Icarrier, PRNprompt*Qsample*Qcarrier, PRNprompt*Isample*Qcarrier, PRNprompt*Qsample*Icarrier,
[07:17] <hallam> that's 4
[07:17] <hallam> and then 2 for the EML
[07:17] <Laurenceb> yes
[07:17] <hallam> PRNeml*Isample*Icarrier + PRNeml*Qsample*Qcarrier
[07:18] <Laurenceb> we already did EML
[07:18] <hallam> when?
[07:18] <Laurenceb> ^10 lines
[07:19] <Laurenceb> 4 bines
[07:19] <hallam> I don't see
[07:19] <Laurenceb> I and Q
[07:19] <Laurenceb> for EML and Prompt
[07:19] <Laurenceb> 2*2=4
[07:20] <hallam> don't get it :(
[07:20] <hallam> I'm sorry
[07:20] <Laurenceb> use abs(EML_bin)*sing(real(EML_bin) as dll disc
[07:20] <Laurenceb> angle(Prompt_bin) as PLL
[07:21] <Laurenceb> real(Prompt_bin) as data bits
[07:21] <hallam> hmmmmm
[07:22] <hallam> okay so you do the discrimination before storing it in bins
[07:22] <hallam> makes sense
[07:22] <hallam> so it's not just 6 xors, it's 6 sets of xors
[07:22] <Laurenceb> s/before/after
[07:23] <hallam> er
[07:23] <Laurenceb> 6 xors, 4 countones per 16 IQ samples
[07:23] <hallam> :/ can we go over it again from the top?
[07:24] <Laurenceb> k
[07:24] <hallam> SamplesPrompt, SamplesEML, each 32 bits interleaved
[07:24] <Laurenceb> yes
[07:24] <hallam> you've already used 2 xors to get there
[07:24] <Laurenceb> yes
[07:25] <hallam> next you xor SamplesPrompt with CarrierIQ?
[07:25] <Laurenceb> yes
[07:26] <hallam> same with EML
[07:26] <Laurenceb> yes
[07:26] <hallam> call that bbPrompt and bbEML
[07:26] <hallam> that's 2 more xors
[07:26] <hallam> what next?
[07:26] <Laurenceb> you need another carrier
[07:26] <Laurenceb> dunno
[07:26] <Laurenceb> call if Carrier QI
[07:26] <Laurenceb> *it
[07:27] <Laurenceb> releat with that
[07:27] <hallam> and carrier QI is made of?
[07:27] <Laurenceb> erm stuff
[07:27] <Laurenceb> I is pi phase reversed
[07:27] <Laurenceb> cant think
[07:28] <Laurenceb> work it out on paper :P
[07:28] <Laurenceb> the point is one is for the real bins
[07:28] <Laurenceb> one is for the imaginary bins
[07:28] <hallam> ok
[07:28] <Laurenceb> this is how you get to your 4 bins
[07:29] <hallam> so you xor SamplesPrompt with CarrierQI
[07:29] <hallam> and same for SamplesEML
[07:29] <Laurenceb> but its not that hard, as the lo is a square wave
[07:30] <Laurenceb> or maybe with 010101 in the middle
[07:30] <Laurenceb> yes
[07:30] <hallam> then what do you countones on?
[07:30] <Laurenceb> the results
[07:30] <Laurenceb> and add into the I and Q bins for prompt and EML
[07:31] <hallam> so Iprompt += countones(bbprompt)?
[07:32] <Laurenceb> yeah
[07:32] <Laurenceb> ok got a nav solution
[07:32] <hallam> nice
[07:32] <Laurenceb> looks very good
[07:33] <Laurenceb> 32 isnt tracked quite as well
[07:33] <hallam> and Qprompt+= countones(samplesPrompt xor CarrierQI)
[07:33] <Laurenceb> erm yeah
[07:33] <hallam> for my DLL you only need Ieml not Qeml
[07:33] <hallam> so that saves you one xor and one countones?
[07:33] <Laurenceb> yeah
[07:34] <hallam> sweet
[07:34] <Laurenceb> ok I'll see where this is
[07:34] <hallam> so um
[07:35] <hallam> how does this end up giving signed values for the correlations?
[07:35] <Laurenceb> it doesnt
[07:35] <Laurenceb> I think you need to subtract something off them
[07:35] <hallam> ok
[07:35] <hallam> makes sense
[07:35] <Laurenceb> as effectively we said 0.5=0
[07:35] <Laurenceb> 0=-1
[07:35] <hallam> yeah
[07:36] <Laurenceb> 1=1
[07:36] <hallam> thanks so much for being patient with me :)
[07:37] <Laurenceb> http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=%4052.20209575,0.1181225&sll=53.800651,-4.064941&sspn=12.270158,39.199219&ie=UTF8&ll=52.202069,0.118162&spn=0.000194,0.000598&t=h&z=21
[07:38] <Laurenceb> I can hardly tell the differnece
[07:38] <Laurenceb> but I think it worked as 32 dropped off a bit more
[07:38] <Laurenceb> think its about 0.5m SW
[07:38] <Laurenceb> ironicall closer to true position
[07:38] <hallam> heh
[07:39] <hallam> close enough I think!
[07:39] <Laurenceb> I guess you dont suffer much as you have already converted to 1 bit samples
[07:40] <Laurenceb> hmm I'll check the logs
[07:40] <Laurenceb> it'll be in there
[07:40] <hallam> so I make it 11 operations per word of samples
[07:40] <Laurenceb> just a sec
[07:40] <hallam> including the accumulating
[07:40] <Laurenceb> so xor, countones, accumulate are seperate?
[07:41] <hallam> AFAIK
[07:41] <hallam> I don't know the instruction set very well
[07:41] <hallam> I've just used gcc until now
[07:41] <hallam> but worst case, they are
[07:41] <hallam> that adds up to 2.8MHz per channel
[07:42] <hallam> oh, also you can do a lot of instructions in parallel with another
[07:42] <hallam> that's suited well to this
[07:42] <Laurenceb> it has a pipeline?
[07:42] <hallam> not as such
[07:43] <hallam> you specify two instructions to execute together
[07:43] <hallam> you're not allowed all combinations, but a lot
[07:43] <hallam> it's got slightly less than 2 ALUs
[07:45] <Laurenceb> hmm its the same position
[07:45] <Laurenceb> guess its only to so many dp
[07:45] <Laurenceb> hmm hope it worked
[07:46] <hallam> how does their code implement the DLL?
[07:46] <hallam> i.e. the bit where we chucked 0, 1 or 2 samples
[07:46] <Laurenceb> stretching the PRN
[07:46] <Laurenceb> one reason why its slow
[07:46] <hallam> so they don't always read 8184 samples?
[07:47] <Laurenceb> and why data bit tracking is overly complex
[07:47] <Laurenceb> they always read the same number yes
[07:47] <Laurenceb> so that means they have to strtch the code
[07:47] <Laurenceb> and rotate it
[07:47] <hallam> what happens then when a nav bit transition falls in the middle of a millisecond?
[07:47] <Laurenceb> with some indexing operations
[07:47] <Laurenceb> it misses it in acquisition :P
[07:48] <Laurenceb> dll will be slightly screwed up as well
[07:49] <hallam> wouldn't that mean all the correlations are 0? how do any of the loop filters keep lock?
[07:49] <Laurenceb> hmm
[07:49] <hallam> I can understand missing it in acquisition, that's hard to avoid
[07:50] <Laurenceb> yeah I'm confused
[07:51] <Laurenceb> ok yeah sorry
[07:51] <Laurenceb> they read in a variable amount of data
[07:52] <Laurenceb> then generate a stretched prn code
[07:53] <Laurenceb> based on the prn clock frequency
[07:53] <hallam> ok
[07:53] <hallam> but they never chuck
[07:53] <hallam> makes sense
[07:53] <hallam> I bet they could just not stretch the PRN and it would still correlate well enough
[07:53] <Laurenceb> yeah
[07:53] <Laurenceb> ooh
[07:54] <Laurenceb> how are you dont course aquisition
[07:54] <Laurenceb> erm
[07:54] <Laurenceb> fine acquisition
[07:54] <hallam> same as coarse with finer freq bin spacing
[07:54] <Laurenceb> over 10ms wont the prn need strectching?
[07:54] <hallam> I totally don't use the fact that I know the code phase
[07:54] <Laurenceb> ah ok
[07:54] <Laurenceb> they use code phase to generate a 10ms prn
[07:55] <Laurenceb> then fft to get the carrier
[07:55] <hallam> makes sense
[07:55] <Laurenceb> yeah over 10ms you dont have to worry about the prn chips gong out of alignment
[07:56] <hallam> we also have to worry about loading [samples, 2 PRNs, Carrier IQ, Carrier QI]
[07:56] <hallam> and generating the carrier
[07:56] <hallam> maybe better to generate the carrier than load it
[07:56] <Laurenceb> yeah
[07:56] <Laurenceb> as its simple
[07:56] <Laurenceb> on the xmos you could use another core
[07:56] <Laurenceb> :P
[07:56] <hallam> yeahj
[07:57] <hallam> so how do you generate the carrier?
[07:58] <Laurenceb> hmm
[07:58] <hallam> have a carrierphase variable, maybe a 16-bit or 32-bit unsigned
[07:58] <Laurenceb> do we have an rtos?
[07:58] <hallam> I was hoping not to have a full rots
[07:58] <hallam> rots
[07:58] <Laurenceb> I mean if all the data is DMAd
[07:58] <hallam> rtos
[07:58] <Laurenceb> we can stop excution
[07:58] <Laurenceb> and do something else
[07:59] <hallam> yeah, like compress JPEGs from the camera
[07:59] <Laurenceb> lol
[07:59] <Laurenceb> fft time
[07:59] <hallam> true
[07:59] <Laurenceb> I know
[07:59] <Laurenceb> you start from some intial 32 bit variable
[08:00] <Laurenceb> then iterate it through a lookup table
[08:00] <Laurenceb> xor occasionally
[08:00] <Laurenceb> when you want to flip something
[08:00] <Laurenceb> or all the time for 010101
[08:01] <hallam> what do you mean, iterate it through a lookup table?
[08:01] <Laurenceb> a=a XOR b
[08:01] <Laurenceb> lookup(n)=a
[08:02] <hallam> confused
[08:02] <hallam> bed might be in order
[08:02] <Laurenceb> over 1ms you have like 1023 samples or so
[08:02] <hallam> the 32 bit var is your carrier wave?
[08:02] <Laurenceb> erm *4
[08:02] <Laurenceb> not exactly
[08:02] <hallam> or is its phase
[08:02] <Laurenceb> it goes into the xor and countones
[08:04] <Laurenceb> or better
[08:04] <Laurenceb> you just correct you lookup table from one iteraction to the next
[08:05] <Laurenceb> it doesnt have to be rewritten
[08:05] <Laurenceb> better plan
[08:06] <Laurenceb> yuo have a fixed lookup table
[08:06] <Laurenceb> and a lookup table pointer
[08:06] <hallam> what's in the lookup table?
[08:06] <Laurenceb> 32 bit variables to use in the xor and counones
[08:06] <hallam> carrierIQ and carrierQI?
[08:06] <Laurenceb> yes
[08:07] <hallam> ok
[08:07] <Laurenceb> so, each 32 bins of sample iteration
[08:07] <Laurenceb> you increment lets say a u16
[08:07] <Laurenceb> by same variable pllfreq
[08:07] <hallam> ok
[08:07] <Laurenceb> then use the (say) 8msb
[08:07] <Laurenceb> to point to the lookup table
[08:08] <hallam> because 16 samples worth of carrier wave is going to be some shifted version of 0000000011111111
[08:08] <Laurenceb> you'd have to work it all out to get sensible freqencies and res
[08:08] <hallam> (in the real axis)
[08:08] <Laurenceb> yeah something like that
[08:08] <Laurenceb> prn obviously is simple, fixed lookup and chuck samples
[08:09] <hallam> yeah
[08:09] <Laurenceb> so the pointer business only adds a few clock cycles :P
[08:09] <hallam> let's think about the carrier some more though
[08:09] <hallam> forget the interleaving and look only at the I part of it
[08:10] <hallam> there's a maximum of one transition in 16 samples, right?
[08:10] <hallam> which would be 250kHz (at 4MHz sampling frequency)
[08:10] <Laurenceb> hmm let me work it out
[08:11] <Laurenceb> yeah
[08:11] <Laurenceb> 2 transitions per cycle remember
[08:12] <hallam> ok
[08:12] <hallam> so if the IF+doppler stuff is less than 125kHz, max 1 transition
[08:12] <Laurenceb> yep
[08:13] <Laurenceb> you could round it off
[08:13] <hallam> so your lookup table contains 0000000000000000, 000000000000001, 0000000000000011, ..., 1111111111111111, 1111111111111110, 111111111111111100
[08:14] <Laurenceb> yeah
[08:14] <Laurenceb> I was just thinking, may as well round it off to integer units of 16 samples
[08:14] <hallam> round what off?
[08:14] <Laurenceb> 0000000000000000,111111111111111111111
[08:15] <Laurenceb> only have transitions like that
[08:15] <hallam> that'll lose something, won't it?
[08:15] <Laurenceb> not too much
[08:15] <Laurenceb> bu tI dont think it saves you much
[08:15] <Laurenceb> guess you could ditch the lookup
[08:16] <Laurenceb> and have phase counters
[08:16] <hallam> phaseCarrierI, phaseCarrierQ
[08:16] <Laurenceb> then flip the bit according to the phase counter
[08:16] <Laurenceb> no lookup table required
[08:16] <hallam> so you replace four of the xors with (if, invert)
[08:17] <hallam> no wait
[08:17] <Laurenceb> yes
[08:17] <hallam> that doesn't work because of the interleaving
[08:17] <Laurenceb> you xor the lo u32 with something
[08:17] <Laurenceb> to flip the relevant bits
[08:18] <Laurenceb> like all the I bits or something
[08:18] <hallam> ok, so you keep your existing 5 xors and add a couple more
[08:19] <Laurenceb> yeah, with if clauses
[08:19] <hallam> ok
[08:19] <Laurenceb> based on phase counters, that are incremented by pll_freq
[08:19] <hallam> so with all this crap it'll add up to what, maybe 50 instructions per cycle?
[08:20] <Laurenceb> hmm yeah
[08:20] <Laurenceb> if clauses are heavy
[08:20] <Laurenceb> maybe the lookup with pointers is better
[08:20] <hallam> I think the Blackfin has fast ifs
[08:20] <hallam> I was just being pessimistic
[08:20] <Laurenceb> still have to add on preq
[08:20] <hallam> it's non-pipelined iirc
[08:20] <hallam> preq?
[08:20] <Laurenceb> *freq
[08:20] <Laurenceb> to ta phase counter
[08:21] <hallam> oh
[08:21] <Laurenceb> that is then made into a lookup pointer
[08:21] <hallam> you still need ifs with that
[08:21] <hallam> unless you want a lookup table that's mostly empty
[08:21] <hallam> or mostly repeated
[08:21] <Laurenceb> exactly
[08:21] <hallam> ifs aren't too expensive
[08:21] <Laurenceb> thats what I realised when I went for flipping
[08:21] <hallam> let's reexamine the cost of rounding the transitions
[08:22] <hallam> I think it's something like (number of transitions per 1ms) / (number of 16-sample chunks per ms)
[08:22] <hallam> so about 40/256
[08:23] <hallam> which might be ok
[08:23] <hallam> that's assuming zero IF and 20kHz max doppler
[08:24] <hallam> did I tell you that I worked out why the IF on the blue stick is not zero?
[08:24] <Laurenceb> more like 50
[08:24] <Laurenceb> oh go on
[08:24] <Laurenceb> so the sat freq is always +ive?
[08:24] <Laurenceb> 50/256 is still ok
[08:25] <hallam> well it is, but why
[08:25] <Laurenceb> makes code easier to write
[08:25] <hallam> they used a 16.3676Mhz crystal instead of the 16.368Mhz one that the datasheet specified
[08:26] <Laurenceb> durrr
[08:26] <Laurenceb> you've opened it up?
[08:26] <Laurenceb> can you take a photo?
[08:26] <hallam> I have, but I figured it out from context first
[08:26] <hallam> that also explains the 7km/s range rate offset that I got
[08:26] <hallam> sure
[08:27] <hallam> if you wait til tomorrow I'll get one under a microscope
[08:27] <Laurenceb> range rate from what?
[08:27] <hallam> satellite range rate
[08:27] <Laurenceb> hehe it is tomorrow
[08:27] <Laurenceb> hmm
[08:27] <hallam> from either doppler or code phase rate
[08:27] <hallam> doppler because it moves the IF
[08:27] <Laurenceb> why does that matter?
[08:27] <hallam> code phase rate because it means the sampling frequency is no longer an integer multiple of the PRN bitrate
[08:27] <hallam> it doesn't affect the final nav solution
[08:28] <hallam> it just confused me for a while
[08:28] <Laurenceb> right yeah
[08:28] <Laurenceb> so your dopplers were off
[08:28] <Laurenceb> as 38.4kHz isnt quite right?
[08:28] <hallam> well they're fine if you subtract the 38.4kHz
[08:28] <Laurenceb> ok
[08:28] <hallam> let me just check that's right
[08:29] <Laurenceb> why the hell did you get a range rat eoffset?
[08:30] <Laurenceb> oh as theres too many samples
[08:30] <Laurenceb> so you have to keep sropping them
[08:30] <Laurenceb> or too few even
[08:30] <hallam> yeah
[08:30] <hallam> hrmmmm
[08:31] <hallam> L1 center frequency is 1575.42MHz
[08:31] <hallam> SE4120 datasheet quotes the LO frequency as 1571.328MHz
[08:32] <hallam> which would make all the satellites positive frequencies, which is nice for coding I guess
[08:33] <hallam> but because of the different crystal, it's actually 1571.328*(16.3676 / 16.368) = 1 571.2896MHz
[08:34] <hallam> I don't get how you go from that to the zero IF
[08:34] <Laurenceb> yeah
[08:35] <hallam> 1571.328MHz*(1-(16.3676 / 16.368)) = 38.4kHz
[08:35] <hallam> altough I don't understand how that works
[08:36] <Laurenceb> lol
[08:36] <Laurenceb> yeah, thats the wrong L1 freq
[08:37] <hallam> is L1 1575.42?
[08:38] <hallam> ah
[08:38] <Laurenceb> yeah
[08:38] <hallam> I think
[08:38] <hallam> maybe
[08:39] <hallam> the LO on the chip is 1571
[08:39] <hallam> that gives a 4.092MHz IF on the chip
[08:39] <Laurenceb> oh
[08:39] <Laurenceb> course
[08:39] <Laurenceb> clever
[08:39] <hallam> but because it's sampled at that rate or twice that
[08:39] <Laurenceb> yeah
[08:39] <hallam> the aliasing gives you zero IF out
[08:39] <hallam> right?
[08:39] <hallam> yay
[08:39] <Laurenceb> yep
[08:39] <Laurenceb> :P
[08:39] Action: hallam is starting to get a clue about this mixing and aliasing stuff
[08:39] Action: Laurenceb is reading xmos datasheet
[08:39] <hallam> only starting, mind
[08:40] <hallam> remember xmos has 4 cores but they're only 100MHz each
[08:40] <Laurenceb> so much task switching dased stuff
[08:40] <Laurenceb> no 400
[08:40] <hallam> really?
[08:40] <hallam> nice
[08:40] <Laurenceb> yep 1600 total
[08:41] <hallam> not bad
[08:41] <hallam> I'm kind of hopeful though about doing this on the blackfin
[08:42] <hallam> let's be pessimistic and say that the PRN and sample loading (from L1) and generating the carrier takes three times as long as all the xoring/counting stuff
[08:42] <hallam> i.e. 50 cycles, some of which can be doing two things at once
[08:43] <Laurenceb> whats the cpu speed?
[08:43] <hallam> 500MHz
[08:43] <hallam> that's 12800 cycles for a whole millisecond
[08:43] <hallam> plus some for the loop filters, call it 15000
[08:44] <hallam> still only works out to 15MHz of cpu time
[08:44] <hallam> 8 channels, and you're at 25% cpu utilisation
[08:45] <hallam> plenty left for nav, reacq, jpeg compression
[08:45] <Laurenceb> nice
[08:45] <Laurenceb> 12 is just over 33%
[08:46] <Laurenceb> with the DMA you can build up a bit of data
[08:46] <Laurenceb> 1MB/s
[08:46] <hallam> yeah
[08:46] <Laurenceb> how much ram can you spare?
[08:46] <hallam> my plan was to buffer data for 16 seconds
[08:46] <hallam> well
[08:46] <Laurenceb> ?!
[08:46] <hallam> so
[08:46] <hallam> during acquisition, if you do a parallel search
[08:46] <hallam> you need (1) lots of ram for the search
[08:47] <Laurenceb> 10ms tasks?
[08:47] <Laurenceb> no
[08:47] <Laurenceb> you dump
[08:47] <Laurenceb> then restart
[08:47] <Laurenceb> and assume the clock doesnt jitter too much
[08:47] <hallam> (2) a substantial buffer for the data so you can track after acquisition
[08:47] <hallam> but you need lots of ram for the fft
[08:47] <Laurenceb> so external ram?
[08:47] <hallam> can't get around that
[08:47] <hallam> yeah I have 32MB external
[08:48] <Laurenceb> and it delays your code?
[08:48] <hallam> on my existing board, which I would like to use
[08:48] <Laurenceb> ah cool
[08:48] <Laurenceb> yeah I took a look at that
[08:48] <hallam> it's slow, but faster than realtime
[08:48] <Laurenceb> how does it work in the code?
[08:48] <hallam> 133MHz 16-bit
[08:48] <hallam> I think the CPU just halts
[08:48] <Laurenceb> you just declare stuff as in the external?
[08:48] <Laurenceb> and the cpu halts as appropriate?
[08:48] <hallam> oh, when you're programming?
[08:49] <Laurenceb> yes
[08:49] <hallam> yeah there's a unified address space
[08:49] <hallam> so you just have a pointer to an address somewhere in SDRAM
[08:49] <Laurenceb> so if you fill up the onboard it goes over?
[08:49] <Laurenceb> ah got it
[08:50] <Laurenceb> yeah, just like avr
[08:50] <hallam> there's no memory management unit
[08:50] <hallam> so
[08:50] <Laurenceb> Ive played about with similar setups on atmega128 before
[08:50] <hallam> for acq, you use all the sdram
[08:50] <hallam> for tracking, you switch the DMA so it goes straight into L1
[08:50] <hallam> L1 ram, that is
[08:50] <hallam> onboard
[08:51] <Laurenceb> you have to match up with acquisition timings
[08:51] <hallam> because for tracking you don't need much buffer, a few ms maybe
[08:51] <Laurenceb> i.e. acquisition stops, tracking starts
[08:51] <Laurenceb> you need to match up
[08:51] <hallam> right, so you have a substantial buffer in SDRAM
[08:51] <hallam> and you track through that
[08:51] <hallam> once it's empty, switch to L1
[08:51] <Laurenceb> yeah
[08:52] <Laurenceb> but you just said all SDRAM for acquisition
[08:52] <hallam> I was thinking 16MB of buffer, 16MB for the ffts and stuff
[08:52] <Laurenceb> cool got it
[08:52] <hallam> or whatever tradeoff is best
[08:52] <Laurenceb> you only need to store one fft at a time
[08:52] <Laurenceb> loop in frequency space
[08:53] <Laurenceb> erm local osc frequency
[08:53] <hallam> yeah
[08:53] <Laurenceb> not a huge amount of ram
[08:53] <hallam> do you mean a single-axis fft then?
[08:53] <hallam> I was going to keep the dual axis, but do it in chunks
[08:53] <Laurenceb> no
[08:53] <Laurenceb> processors dont appreciate pretty graphs
[08:54] <Laurenceb> could do it in <100KB
[08:54] <hallam> yeah but given the ram, a dual axis fft is faster than a lot of single axis ones, isn't it?
[08:54] <Laurenceb> theres no dual axis
[08:54] <hallam> oh really
[08:54] <hallam> ah fuck
[08:54] <Laurenceb> the other axis is descreet local oscs
[08:54] <hallam> so when you fall fft() in matlab
[08:54] <hallam> passing it, say, a 16x16 matrix
[08:55] <hallam> it just does 16 one-dimensional ffts
[08:55] <hallam> ?
[08:55] <Laurenceb> ioperates on rows
[08:55] <hallam> heh
[08:55] <Laurenceb> or columns, I forget
[08:55] <hallam> ah I guess that's what fft2 is for
[08:55] <Laurenceb> yep, 2D
[08:55] <Laurenceb> for you jpegs
[08:55] <hallam> it is possible to do it with a 2D fft, though, isn't it?
[08:55] <Laurenceb> yes
[08:55] <hallam> search in parallel in both freq and code phase
[08:55] <Laurenceb> you need 8*8 for jpeg IIRC
[08:56] <hallam> I must admit I don't get the fft method of acquisition
[08:56] <Laurenceb> no, its only parallel in code phase
[08:56] <Laurenceb> its serial in local osc
[08:56] <hallam> I know the one you gave me is
[08:56] <Laurenceb> thats the only way to do it it seems
[08:56] <hallam> but is it possible to do it in parallel with both?
[08:56] <hallam> oh, ok
[08:57] <Laurenceb> yeah, looking at fourier transform theorems I thought it might be
[08:57] <Laurenceb> but I havent investigated
[08:57] <Laurenceb> and thats what borre uses
[08:57] <hallam> man I totally feel like I could write a book on this
[08:57] <hallam> or teach a lecture series
[08:57] <Laurenceb> hehe
[08:57] <hallam> it's amazing how educational it is
[08:58] <Laurenceb> yeah we need to write some notes
[08:58] <Laurenceb> its getting a bit much to remember
[08:58] <Laurenceb> theres the logs
[08:58] <hallam> that's why I daren't stop
[08:58] <Laurenceb> hehe
[08:58] <Laurenceb> hmm
[08:59] <Laurenceb> we could afford multiple front ends then
[08:59] <hallam> oh god
[08:59] <Laurenceb> you dont need to multiply by the number of front ends
[08:59] <hallam> you're a crazy person
[08:59] <hallam> no?
[08:59] <hallam> would they run in sync?
[08:59] <Laurenceb> you only need a few channels in reserve
[08:59] <Laurenceb> ooh yeah
[08:59] <Laurenceb> prn in phase
[08:59] <Laurenceb> use the pll
[09:00] <Laurenceb> for attitude
[09:00] <hallam> but
[09:00] <hallam> oh ok
[09:00] <hallam> totally independent
[09:00] <Laurenceb> no
[09:00] <Laurenceb> prn the same
[09:01] <hallam> sure
[09:01] <hallam> I was thinking you were going to try to combine the data at the sample level
[09:01] <Laurenceb> whats the name of the countones instruction?
[09:01] <hallam> ONES
[09:04] <Laurenceb> hmm not in XMOS
[09:04] <Laurenceb> I read through AS WELL
[09:04] <Laurenceb> there bitwise or in one cycle
[09:05] <Laurenceb> xor, s16 multiply, divde
[09:05] <Laurenceb> sign swap ect
[09:05] <Laurenceb> unfortunately no ones
[09:05] <hallam> sucks
[09:05] <Laurenceb> lots of stack pointer and interrupt stuff
[09:05] <Laurenceb> and exception handling
[09:08] <Laurenceb> what about tigersharc?
[09:08] <hallam> no idea
[09:08] <Laurenceb> has fpu
[09:08] <hallam> funky
[09:09] <hallam> if it's a DSP then it probably has ONES
[09:10] <hallam> ok, goodnight
[09:11] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-2719d4232682d91a) left irc: "http://www.mibbit.com ajax IRC Client"
[09:20] <Laurenceb> yeah tigersharc is essencially blackfin with dsp
[09:20] <Laurenceb> ooh hes gone
[09:20] <Laurenceb> cya hllam
[09:20] <Laurenceb> has ones instruction
[09:25] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-456c267e1b0f7919) left irc: "http://www.mibbit.com ajax IRC Client"
[09:44] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[10:28] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[10:31] <rjharrison> Morning all
[10:31] <rjharrison> Preliminary tests show that two way coms are a go go
[10:32] <edmoore> cool - what have you done?
[10:32] <rjharrison> Well at least within the constraints of the comp.
[10:32] <rjharrison> Well I have two modules from rm working overland to tx rx rtty over 22 miles
[10:33] <gordonjcp> rjharrison: nice
[10:33] <rjharrison> Given that distance overland it seems reasonable that it's going to work fine in the air
[10:34] <gordonjcp> rjharrison: is that with your 169MHz modules?
[10:34] <rjharrison> the antenna are a bit bigger
[10:34] <rjharrison> yep
[10:34] <gordonjcp> that's excellent
[10:34] <gordonjcp> 22 - actually twenty-two - miles?
[10:34] <rjharrison> than the 70cm ones
[10:34] <rjharrison> yep
[10:34] <gordonjcp> what kind of antennas are you using?
[10:35] <rjharrison> ground plane
[10:35] <gordonjcp> I take it that would be with both ends fairly high up over an unobstructed path?
[10:35] <rjharrison> 1/4 wave
[10:35] <rjharrison> yep
[10:35] <gordonjcp> jeeez
[10:35] <rjharrison> line of sight really
[10:35] <gordonjcp> that's incredible
[10:35] <rjharrison> 100mw
[10:35] <gordonjcp> imagine what they would be like with a Yagi at one end!
[10:36] <gordonjcp> Mmm, I suppose I can work the local repeater about 15 miles away non-LOS with 100mW
[10:36] <gordonjcp> s/100/500/
[10:37] <rjharrison> We have had 10mw over 300km
[10:37] <rjharrison> All be it from a high alt.
[10:37] <gordonjcp> well yeah, that's different
[10:37] <rjharrison> 8km +
[10:37] <gordonjcp> ground paths are much more difficult
[10:37] <edmoore> sure
[10:37] <gordonjcp> hm
[10:37] <edmoore> and also our receiving ends are a lot more sensitive that a radiometrix rx
[10:37] <gordonjcp> I'd want to hook a Yagi to one end, and see how far it went
[10:38] <rjharrison> Well I have the adv. of living on the highest hill in yorkshire
[10:38] <gordonjcp> edmoore: what are you using?
[10:38] <edmoore> for what?
[10:38] <gordonjcp> receiving
[10:38] <edmoore> ic-7000
[10:38] <gordonjcp> doubt that's *much* more sensitive, to be honest
[10:39] <rjharrison> actually the antenna home for the tx is a watson tri band 2000
[10:39] <rjharrison> not that it makes much difference
[10:39] <gordonjcp> whatever receiver you use, its sensitivity will be much greater than the local noise floor
[10:39] <edmoore> the radiometrix rx equivalent module for the tx is -118dBm
[10:40] <gordonjcp> it's pretty safe to say that you'll have way more local QRM than that
[10:41] <gordonjcp> have you got any electrical equipment more powerful than a digital watch within about a mile of the receiver?
[10:41] <edmoore> that's like 0.35uV
[10:41] <edmoore> vs 0.11 - so maybe 5dB? sure, not loads
[10:41] <rjharrison> Any how quite please with preliminarys
[10:41] <gordonjcp> edmoore: in practical terms it's not really important
[10:42] <gordonjcp> edmoore: how old are you?
[10:42] <rjharrison> hehe
[10:42] <gordonjcp> this is relevant
[10:42] <edmoore> too young to remember whatever it is you're about to say :p
[10:42] <gordonjcp> or if you don't want to answer, I'll assume you're about 10 years younger than me
[10:42] <edmoore> 21
[10:42] <gordonjcp> okay, 14 years younger than me
[10:43] <gordonjcp> the difference between the two receivers is about the same as the difference between your hearing an my hearing at about 12kHz
[10:43] <gordonjcp> so in a quiet environment - lead-lined hearing testing room in a hospital, which is spookily quiet - you'd be able to measure the difference
[10:44] <edmoore> what about those anti-social behaviour machines which drive my crazy in public spaces but that you're not meant to hear :p
[10:44] <gordonjcp> if you are running both receivers with a laptop within about 100 metres, that would be like testing your hearing and my hearing at a Grateful Dead concert
[10:44] <gordonjcp> edmoore: oh I can hear those
[10:45] <edmoore> I feel your pain then
[10:45] <gordonjcp> the railway station near me used to have one
[10:45] <gordonjcp> they don't any more though
[10:46] <gordonjcp> something happened to it
[10:47] <edmoore> you shot it?
[10:47] <gordonjcp> nope
[10:47] <gordonjcp> thought about it
[10:47] <gordonjcp> a couple of the local wee neds got hold of a can of expandy foam and sprayed it into the horn
[10:47] <edmoore> wee neds?
[10:48] <edmoore> don't even want to know
[10:48] <gordonjcp> you probably call them chavs down there
[10:48] <gordonjcp> can't think where they got the idea for that
[10:48] <edmoore> I noticed a local speed camera has been lopped off its stand with a plasma cutter, the other week
[10:48] <gordonjcp> haha
[10:49] <gordonjcp> a few months ago someone went along a bit of road in the south of Scotland and lopped off all six cameras on a ten-mile stretch
[10:49] <gordonjcp> quite heavy they are too
[10:49] <edmoore> i think expanding foam is meant to work on them too
[10:50] <gordonjcp> apparently they got caught when they went to weigh them in
[10:50] <edmoore> if you srill a small hole in and fill it up, it expands and bursts the whole thinf open
[10:50] <gordonjcp> edmoore: sandpaper on the window
[10:50] <edmoore> less fun!
[10:50] <edmoore> right, brunch
[10:50] <edmoore> bbl
[11:10] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[11:11] Nick change: Bluenarf -> EI5GTB
[11:12] Nick change: EI5GTB -> Bluenarf
[11:36] <SpeedEvil> plasma cutter?
[11:36] <SpeedEvil> Not oxy-ac?
[11:38] <gordonjcp> SpeedEvil: it's easier to get a plasma cutter these days
[11:39] <SpeedEvil> yes, but plasma cutters do require a power-point
[11:39] <SpeedEvil> or a large genny.
[11:39] <gordonjcp> you need all sorts of paperwork for oxy-acetylene
[11:39] <gordonjcp> not a large genny
[11:40] <gordonjcp> 5kW maybe?
[11:40] <gordonjcp> for a small one
[11:41] <gordonjcp> probably less, actually - one of my friends had one that just plugged into a normal 13A socket
[11:41] <gordonjcp> so that would have been at most 3kW input
[11:45] Nick change: Bluenarf -> EI5GTB
[11:46] Nick change: EI5GTB -> Bluenarf
[11:49] Nick change: Bluenarf -> EI5GTB
[12:16] <edmoore> gordonjcp / SpeedEvil - there are loads of portable(ish) ones with deisel genny's built in
[12:19] rjharrison (n=rharriso@80.176.172.227) left #highaltitude.
[12:20] <SpeedEvil> sure not a angle grinder?
[12:20] <SpeedEvil> those'd be an order of magnitude or two more common
[12:20] <SpeedEvil> IMO
[12:20] <gordonjcp> stihl saw
[12:20] <SpeedEvil> yeah
[12:24] <edmoore> SpeedEvil: was definitely not an angle ground edge
[12:24] Action: SpeedEvil notes that edmoore seems to know lots about the results of plasma-cutting cameras.
[12:24] <SpeedEvil> :)
[12:25] <edmoore> it had the trademark plasma edge. - much less molton than oxy but still slightly molten (i.e not ground)
[12:25] Action: SpeedEvil wants a plasma cutter.
[12:25] <SpeedEvil> And a filliment winder.
[12:25] <SpeedEvil> And an autoclave.
[12:25] <SpeedEvil> And a puppy.
[12:25] <edmoore> I used to work in an agricultural machine shop for beer money, and did lots of metal slicing. Plasma was a lovely tool for knocking stuff up
[12:29] <SpeedEvil> plasma can be used for welding - not just cutting?
[12:30] <edmoore> not with the sort of equipment I was using
[14:24] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[14:31] <edmoore> hi fergusnoble
[14:31] <fergusnoble> edmoore: hi
[14:31] <edmoore> there were some techy sounding discussion on the repeater just a bit ago
[14:31] <edmoore> am going to stay tuned in and see if there's an opportune moment to introduce myself/ourselves (if you go on) and CUSF
[14:32] <edmoore> the guy who runs it is an electropnics hobbyist doing lots of neat little bits and bobs
[14:32] <edmoore> i think the balloons would be right up his street
[14:33] <fergusnoble> ok, ill tune in
[14:35] <fergusnoble> edmoore: trying to fiddle with the predictor to check monday morning
[14:35] <fergusnoble> looks good on wundergrond
[14:35] <edmoore> what time and pressure?
[14:36] <fergusnoble> from about 3am, getting better until 9am
[14:37] <edmoore> and pressure?
[14:37] <fergusnoble> 200mb
[14:37] <edmoore> 300mB is cyan at 3am going to sky blue at 9am
[14:37] <edmoore> i.e. bad
[14:38] <edmoore> 80kts to 50-60kts
[14:38] <edmoore> 200mb is nice though yeah
[14:38] <edmoore> what says the predictor?
[14:38] <fergusnoble> yup, maybe later in the afternoon would be a better compromise
[14:38] <fergusnoble> just manually downloading the right gribs
[14:39] <edmoore> 12-3 is in the pink/purple on 200mB - workable
[14:40] <edmoore> 3pm gets the tail end of the blue. it's a bit tight. I'd be interested to see how the forcasts predict. It depends on the movement of that north-south aligned low speed corridor moving west-east
[14:40] <edmoore> if that moves a bit then we'd have a launch
[14:41] <fergusnoble> yeah
[14:41] <fergusnoble> the 200mb is really gentle
[14:42] <edmoore> it'd be another classic flight profile. ok...ok...ok...FUUUCK JEEEET STREEEEEAAAAMMMMM... ok...ok...ok...ok...burst
[14:44] <fergusnoble> edmoore: doesnt seem to like me
[14:44] <edmoore> the repeater?
[14:45] <fergusnoble> no, tuned into the repeater
[14:45] <fergusnoble> the predictor
[14:45] <edmoore> oh right
[14:45] <fergusnoble> i really need to take time to get it working properly
[14:45] <edmoore> did you hear my call?
[14:46] <fergusnoble> wasnt really listening, go again
[14:47] <fergusnoble> hear my reply?
[14:47] <edmoore> nope
[14:53] Action: SpeedEvil idly wonders about subsampling.
[14:53] <SpeedEvil> don't process every sample, only 1/20th (1ms per nav bit)
[16:12] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[16:17] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[16:53] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-cef973153232afd3) joined #highaltitude.
[16:59] <fergusnoble> hallam: hello
[16:59] <fergusnoble> hallam: whats new?
[17:00] <hallam> hey
[17:00] <hallam> laurence and I worked out a really clever way to do the tracking
[17:00] <fergusnoble> orly?
[17:00] <hallam> involving all sorts of nasty bit-level stuff
[17:00] <fergusnoble> cool
[17:00] <fergusnoble> have you done much on the C implementation?
[17:01] <hallam> but I reckon it can use as little as 5MHz of Blackfin per channel
[17:01] <fergusnoble> wow
[17:01] <hallam> no, I'm going to do the C one now using the same method
[17:01] <fergusnoble> awesome
[17:01] <fergusnoble> want a hand at all?
[17:01] <hallam> sure
[17:01] <hallam> got chicken to eat too
[17:01] <fergusnoble> ok, cool
[17:01] <hallam> even if it's 20MHz, you can still have 12 channels and leave half the CPU for acquisition, navigation and JPEG
[17:01] <fergusnoble> yeah, sweet
[17:02] <fergusnoble> i might bring over some stuff i have to read
[17:02] <hallam> sounds good
[17:03] <hallam> it's wonderful, you can approximate a sine wave as a square wave
[17:03] <hallam> and zero as 0101010101
[17:03] <hallam> (where 0 = -1, and 1 = +1)
[17:03] <hallam> because the 01010101 are at an exact multiple of the sampling frequency, they disappear
[17:04] <hallam> quite ridiculous
[17:05] <fergusnoble> i dont quite get it, explain in person
[17:05] <fergusnoble> but it turns out to be ok to use a square instead of a sine wave?
[17:05] <fergusnoble> you tried it in matlab?
[17:06] <hallam> yeah
[17:06] <hallam> you lose a little bit of SNR
[17:06] <hallam> but it still works on all but the weakest of signals, and I think you could reacquire those
[17:06] <hallam> or tune the loop filters better
[17:07] <fergusnoble> cool
[17:07] <fergusnoble> we should have several strong sats on the rocket
[17:07] <hallam> yeah
[17:07] <hallam> I do think we should probably use an active ant
[17:08] <fergusnoble> the balloon with the crappy lassen usually gets 8 or 9 sats
[17:08] <hallam> saves some worrying about the PCB design
[17:08] <fergusnoble> ok
[17:08] <hallam> btw did you realise why the lassen IQ is called IQ? I only got that yesterday
[17:09] <hallam> ok cereal time for me
[17:09] <hallam> later
[17:20] <hallam> zeusbot seems not to be logging any more
[17:20] <SpeedEvil> Probably worries about ITAR goons.
[17:20] <hallam> heh
[17:20] <SpeedEvil> All this terroristic GPS stuff we're doing.
[17:20] <hallam> COCOM not ITAR
[17:20] <hallam> and it's cool if we don't sell it
[17:21] <SpeedEvil> you mwan COCOM is the UK equivalent?
[17:21] <hallam> no
[17:21] <hallam> the GPS dynamics restrictions fall under COCOM regs, not ITAR
[17:22] <SpeedEvil> Last I looked, they were in ITAR
[17:22] <hallam> oh, I could be wrong, or maybe it's a subset
[17:22] <SpeedEvil> the 1000 knots, 60000 feet, no GPS nulling antennas ones at least
[17:23] <SpeedEvil> right after kick motors on satellites that could precision reenter, and right before high speed nuclear detonation cams
[17:24] <hallam> what's a GPS nulling antenna?
[17:24] <SpeedEvil> It's a GPS antenna with one or more very sharp steerable nulls in it.
[17:24] <SpeedEvil> you point the nulls at jamming sources
[17:25] <hallam> cool
[17:26] <hallam> http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=283874&sk=&date=&pageID=7 this is interesting
[17:27] <SpeedEvil> Not read it
[17:27] <SpeedEvil> I did some numbers on sci.space.policy I think a few years back
[17:28] <SpeedEvil> The amount of power you need for a meaconing jammer is teeny
[17:28] <SpeedEvil> Do basically the inverse of what you're doing, and transmit it.
[17:29] <SpeedEvil> Or more simply, just a 1024 byte RAM with canned signals at high amplitude
[17:29] <hallam> what sort of range can that reasonably cover?
[17:30] <SpeedEvil> Consider that the satellites L1 power is 50W
[17:30] <SpeedEvil> For a hemisphere
[17:30] <SpeedEvil> Even broadcasting all 32 satellites, 1W goes a long way if you have line of sight
[17:30] <hallam> wow, I didn't realise it was that low
[17:31] <SpeedEvil> I was positing a $10 mass-produced 0.5W solar-jammer for scatterin in Iraq
[17:31] <SpeedEvil> produce a few tens of thousands of them.
[17:31] <hallam> do the baddies really use GPS much?
[17:32] <SpeedEvil> That was assuming it was for 'defensive' installation
[17:32] <hallam> I thought the US infantry were using commercial receivers because they worked better than the mil ones
[17:32] <hallam> oh
[17:32] <fergusnoble> hallam: shall i head over?
[17:32] <hallam> sure
[17:32] <SpeedEvil> As HARM missiles are lovely, if you can shoot them at a 'GPS jammer'
[17:33] <SpeedEvil> but if your HARM missile sees a hundred $10 sources, it's just going to smack into the desert confused.
[17:33] <hallam> SpeedEvil: I think it's not in my interest to speculate too much about that kind of thing :P
[17:33] <SpeedEvil> Inertial guidance makes this largely irrelevant
[17:34] <SpeedEvil> As the incoming bomber is traveling at several hundred knots, so will only be over your jammer for a few minutes.
[17:34] <hallam> I really like terrain-following (visual or radar) guidance
[17:34] <SpeedEvil> Yeah.
[17:34] <hallam> SpeedEvil: did you read through the logs from me and Laurence last night?
[17:34] <SpeedEvil> Google-maps, download route to target, click 'go'.
[17:35] <SpeedEvil> I ran out of backscroll
[17:35] <SpeedEvil> hangon
[17:35] <hallam> http://www.pegasushabproject.org.uk/zeusbot/highaltitude.log.20090124
[17:35] <hallam> we figured out how to do the tracking bitwise
[17:35] <hallam> on 16 samples (32 bits) at a time
[17:35] <SpeedEvil> nice
[17:35] <hallam> total maybe one operation per bit
[17:36] <hallam> -> single-digit MHz CPU usage per channel
[17:36] <SpeedEvil> yeah - I've been looking at similar things myself.
[17:36] Xenion (n=robert@p579FC2C3.dip.t-dialin.net) joined #highaltitude.
[17:36] <hallam> I tested the square wave carrier and 1-bit early-minus-late PRN in matlab, successfully
[17:36] <SpeedEvil> I also noted earlier that if you get adequate SNR at 1ms averaging, you could always only do one in 20.
[17:37] <hallam> that means your carrier phase has to be coherent for much longer, right?
[17:37] <SpeedEvil> Which of course vastly reduces the CPU.
[17:37] <SpeedEvil> As I understand it, it should be almost exactly the same as reducing the signal level by 13dB
[17:38] <Xenion> Guten Abend
[17:38] <SpeedEvil> Neat.
[17:38] <SpeedEvil> (wrt matlab)
[17:38] <hallam> why 13dB?
[17:38] <SpeedEvil> A quick glance indicates I've got some of the ideas you went through on paper scribbled down.
[17:38] <SpeedEvil> 1/20
[17:38] <hallam> oh right
[17:39] <hallam> isn't that kind of a lot?
[17:39] <SpeedEvil> Not really.
[17:39] <hallam> it would be cool to do something like that, but adaptive
[17:39] <SpeedEvil> The attenuation - tree cover, ... that most GPSs can cope with just fine - works.
[17:39] <SpeedEvil> yeah
[17:39] <hallam> so for weak signals it correlates every cycle
[17:40] <SpeedEvil> Or accels indicate 0G - powersave lots
[17:40] <hallam> heh
[17:40] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) joined #highaltitude.
[17:40] <SpeedEvil> None of this matters if you just brute-force it.
[17:40] <SpeedEvil> It gets vastly more important on teeny hardware.
[17:41] <hallam> yeah I'll have to see how it goes on the Blackfin
[17:41] <SpeedEvil> Oh
[17:41] <SpeedEvil> P/Y code repeats?
[17:41] Action: SpeedEvil diddn't know that.
[17:41] <hallam> P code repeats
[17:41] <hallam> P/Y = P*W
[17:41] <hallam> I don't think W repeats
[17:41] <SpeedEvil> Oh - so you can't simply record it
[17:41] <SpeedEvil> (with a huuuge dish)
[17:42] <hallam> you could meacon it, if you're fast
[17:42] <SpeedEvil> yeah
[17:46] <SpeedEvil> spot-beam M code is pretty hard to jam though - with other than rather silly powers.
[17:59] <SpeedEvil> http://www.hemispheregps.com/tabid/388/Default.aspx
[17:59] <SpeedEvil> fun
[17:59] <SpeedEvil> 1-2cm error
[18:17] <EI5GTB> is that possible?
[18:19] <EI5GTB> sdo, what module are you guys using to get raw adc data?
[18:21] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[18:53] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) left irc: Remote closed the connection
[19:34] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[19:37] akawaka (n=akawaka@66-215-97-198.dhcp.malb.ca.charter.com) joined #highaltitude.
[19:46] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[19:46] bfirsh (n=ben@host-137-205-75-156.res.warwick.ac.uk) joined #highaltitude.
[20:07] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[20:08] <rjharrison> Quick question guys I have an oscilloscope
[20:08] <rjharrison> Lucky me! However I don't really know how to use it
[20:09] <rjharrison> If I set the time to 1ms is that the time it takes for the scan line to cross the screen or is it the time to move though one of the squares on the screen. I'm assuming the whole screen
[20:25] <akawaka> i believe it is the square
[20:26] <akawaka> set it to a really slow scan
[20:26] <akawaka> like >sec and see for yourself
[20:26] <natrium42> any launches today? :P
[20:34] <natrium42> rjharrison: is today the day?
[20:51] <rjharrison> hi
[20:51] <rjharrison> nope
[20:51] <rjharrison> Fraid not
[20:51] <rjharrison> I'm hoping early Feb
[20:51] <rjharrison> posibly the w/e after next
[20:51] <rjharrison> natrium42 u?
[20:52] <natrium42> just being swamped with other work :S
[20:53] <rjharrison> akawaka good point. Still not obv.
[20:59] rjharrison (n=rharriso@80.176.172.227) left irc:
[21:01] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[21:23] Laurenceb (n=laurence@dyres221-140.surrey.ac.uk) joined #highaltitude.
[21:23] <Laurenceb> hello
[21:24] <Laurenceb> hallam: braindump - I think that the sdrgnss technique of taking fft of 10ms of data with prn removed is less effecient than just multiplying by a local carrier
[21:25] <Laurenceb> at least for 20 different carrier frequencies for fine acquisition or less
[21:25] <Laurenceb> the course acquisition should take about 6 seconds for all 32 sats
[21:25] <Laurenceb> I'd have a variable number of software trackers, and run acquisiton continuously in the background
[21:26] <Laurenceb> if you lose a sat at high elevation, but the course acquisition onto it
[21:26] <Laurenceb> *put
[21:26] <Laurenceb> and if you have almanac, use that to help setup the acquisition
[21:27] <Laurenceb> you want some sort of non volatile storeage for almanac
[21:27] <Laurenceb> finally, for the pll/local osc
[21:28] <Laurenceb> have a u16, and every 16 sample iteration, add some lo_freq onto it, then use the 2msb to select one of 4 u32 from a lookup
[21:28] <Laurenceb> or rather two lookups, one for the real bin and one for the imaginary
[21:29] <Laurenceb> thats simpler and fasher than what we described with the flipping and if clauses
[21:30] <Laurenceb> also, and 2D fft technique will inevitably use more cpu than the 1D fft and local oscillator technique
[21:30] <Laurenceb> due to the complexity of a 2D fft
[21:30] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[21:33] <Laurenceb> oh for the fft, It looks like the s16 would be quite fast - I had a quick read through the datasheet
[21:33] <Laurenceb> tigersharc is essencially blackfin with fpu by the look of it
[21:37] <Laurenceb> the two interleaved local oscillator words are local osc IQIQIQ ie interleaved, and local osc QIQIQI with I being pi out of phase - thats everytihng :P
[21:41] bfirsh (n=ben@host-137-205-75-156.res.warwick.ac.uk) left irc:
[21:48] <Xenion> Good Night / Gute Nacht
[21:48] Xenion (n=robert@p579FC2C3.dip.t-dialin.net) left irc: "Verlassend"
[21:48] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[22:24] <Laurenceb> jcoxon: have you used an icom?
[22:25] <Laurenceb> I'm trying to work out if I should get 3.5mm stereo or mon for connecting to my lapt
[23:01] <jcoxon> Laurenceb, sorry never used one
[23:06] <SpeedEvil> Ok.
[23:07] <SpeedEvil> A) read the manual - find out which the icom has
[23:07] <SpeedEvil> B) you can always make stereo work - sort-of - if you pull it out a little bit
[23:08] <SpeedEvil> C) many laptops have a stereo socket, but a mono mic in - the other pin is mic power
[23:15] <gordonjcp> Laurenceb: stereo plugs
[23:29] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[23:30] <Laurenceb> gordonjcp: thanks
[23:30] <Laurenceb> SpeedEvil: theres no manual avaliable that I can find
[23:31] <Laurenceb> at least that describes the interface properly
[23:31] <Laurenceb> i.e. other than specs
[23:32] <Laurenceb> gordonjcp: does it come out on both channels?
[23:34] <gordonjcp> what, line out?
[23:34] <gordonjcp> yes
[23:34] <Laurenceb> I see
[23:34] <Laurenceb> do you have a pcr-1000 ?
[23:37] natrium42 (i=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[23:43] <SpeedEvil> open it up, inspect the socket
[00:00] --- Sun Jan 25 2009