highaltitude.log.20090121

[00:08] Action: Laurenceb is still contemplating ducted fans
[00:10] <Laurenceb> I guess with a ducted fan you could have some degree of thrust vectoring with a servo and fin in the exhaust
[00:11] <Laurenceb> like jet vanes
[00:12] <Laurenceb> hmm are countrotating ducted fans possible?
[00:13] <SpeedEvil> sure.
[00:13] <SpeedEvil> also if you've vanes in the exhaust, they can provide the counter-torque
[00:13] <Laurenceb> yeah
[00:14] <Laurenceb> but its probably simpler and more efficient to have two units
[00:14] <Laurenceb> then a surfboard shaped foam body inbetween
[00:18] <Laurenceb> have a fore aft vane in one unit, and a port starboard vane in the other
[00:21] <SpeedEvil> the only real issue is that reverse fans tend to be less common - as most apps just use one
[00:21] <Laurenceb> yeah
[00:21] <Laurenceb> I was thinking about those units
[00:22] <Laurenceb> you cant reverse the fan
[00:22] <Laurenceb> - on dealextreme
[00:25] <SpeedEvil> Well - you can.
[00:25] <SpeedEvil> But it's inefficient - and due to being a screw, ...
[00:25] <Laurenceb> yeah
[00:26] <Laurenceb> the aerofoil will be the wrong way up
[00:26] <Laurenceb> hmm I'm confused... are there two types of prop?
[00:26] <SpeedEvil> yes
[00:26] <SpeedEvil> left-hand and right-hand
[00:26] <Laurenceb> yeah
[00:27] <Laurenceb> hmm never seen it as a spec
[00:39] <Laurenceb> http://www.b3tards.com/u/2103a3a3f4466eb7df81/dur.jpg
[00:50] Action: SpeedEvil heard earlier 'the president' and realised with a shock that it wasn't someone who appears incompetnat.
[00:57] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Read error: 104 (Connection reset by peer)
[01:20] <Laurenceb> where do you get the props?
[01:25] <Laurenceb> ah pusher props?
[01:37] jiffe88 (n=jiffe2@209.159.247.189) joined #highaltitude.
[01:49] bfirsh (n=ben@host-137-205-75-156.res.warwick.ac.uk) left irc:
[01:53] <SpeedEvil> A pusher prop and a reverse rotation tractor prop are different
[01:53] <SpeedEvil> err
[01:54] <SpeedEvil> That last sentance was composed by my cat jumping on the keyboard.
[02:02] <Laurenceb> lol
[02:03] <SpeedEvil> For some reason, I thought that the airspeeds would differ and hence the pitch, but of course not.
[02:04] <Laurenceb> http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct=5112
[02:04] <Laurenceb> those look good
[02:04] <Laurenceb> I've got a few of the next one down in that range
[02:06] <Laurenceb> looks like it pulls about 15A for 600grams static thrust
[02:06] <SpeedEvil> you're basically contemplating a helicopter, with low vertical speed max?
[02:06] <Laurenceb> kind of
[02:06] <SpeedEvil> So it'll effectively always be in the static thrust bit of the powercurve?
[02:07] <Laurenceb> two motors buried in a body
[02:07] <SpeedEvil> Ducted fans that can either point down, or through a duct buried in the wing.
[02:07] <SpeedEvil> VTOL FTW.
[02:09] <Laurenceb> http://www.hobbycity.com/hobbycity/store/uh_viewItem.asp?idProduct=6350&Product_Name=ZIPPY-H_5000mAh_3S1P_20-30C_Lipoly_Pack
[02:10] <Laurenceb> two of those for power
[02:10] <Laurenceb> should give over 20minutes flight time
[02:11] <SpeedEvil> What's your total mass budget?
[02:11] <SpeedEvil> guidance, control, structure, motor, battery, payload, ...
[02:12] <Laurenceb> yeah... its a bit tight
[02:12] <Laurenceb> if total mass=1.2Kg
[02:12] <SpeedEvil> also
[02:12] <SpeedEvil> google propcalc
[02:12] <Laurenceb> thats 800 batts, 140 motors, 100 props
[02:12] <SpeedEvil> you need to fiddle with the prop to pick the right one.
[02:12] <Laurenceb> yeah
[02:12] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-3465f751f8bb42a8) joined #highaltitude.
[02:13] <Laurenceb> is there an app for that?
[02:13] <SpeedEvil> propcalc
[02:13] <SpeedEvil> Does what it says on the tin.
[02:14] <SpeedEvil> http://www.drivecalc.de/PropCalc/index.html
[02:14] <SpeedEvil> that
[02:14] <SpeedEvil> (works with wine)
[02:14] <SpeedEvil> drivecalc is also of use
[02:14] <SpeedEvil> how are you controlling?
[02:14] jiffe88 (n=jiffe2@209.159.247.189) left irc:
[02:15] <Laurenceb> motors mounted on CF rods maybe
[02:15] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-3465f751f8bb42a8) left irc: Client Quit
[02:15] <SpeedEvil> you mean gimball?
[02:16] Action: SpeedEvil gyres and gimbals in the wabe.
[02:16] <Laurenceb> lol yes
[02:16] <Laurenceb> only one axis per motor
[02:16] <Laurenceb> with two motors thats all you need
[02:16] <SpeedEvil> Umm...
[02:17] <SpeedEvil> I suppose so, in theory.
[02:17] <Laurenceb> theres a bit of maths to get from attitude errors to motor/actuator inputs
[02:17] Action: SpeedEvil is always wary of theoretically plausible control schemes that nobodies implemented
[02:18] <Laurenceb> but its not too complex
[02:18] <Laurenceb> SpeedEvil: chinook
[02:18] <Laurenceb> SpeedEvil: osprey
[02:18] <SpeedEvil> chinoook hass conveentional rotors
[02:18] <SpeedEvil> with the normal helicopter controls.
[02:19] <SpeedEvil> It's just they are synced.
[02:19] <SpeedEvil> (usually)
[02:19] <SpeedEvil> And osprey has rather more than 2 control axis and differential thrust AIUI.
[02:20] <Laurenceb> http://www.yb2normal.com/tricopter.html
[02:20] <Laurenceb> its just an extension of that concept
[02:20] <SpeedEvil> I think you have a fair bit of unavoidable coupling.
[02:21] <SpeedEvil> And you're relying quite a lot on rapid speed changes in the fans.
[02:22] <SpeedEvil> If for example you want to rotate the airframe in the horizontal plane, you've got to tilt the only motor with control in that axes, wind up the power so that the vertical thrust remains unchanged, and crab round.
[02:23] <SpeedEvil> keeping roll, and pitch stable at the same time seems likely to be fun.
[02:23] <Laurenceb> yeah
[02:23] <Laurenceb> it'd be interesting to try
[02:23] <SpeedEvil> I'd want a large reserve power in the motor/fan/battery
[02:23] <SpeedEvil> At least 50% of nominal max.
[02:24] <Laurenceb> I'm worried that the control loops wont be tunable
[02:24] <SpeedEvil> Sure they'll be tunable :)
[02:24] <Laurenceb> as your control loop really needs to be tuned with the actuator taken into account
[02:24] <Laurenceb> and your mixing actuators
[02:24] <SpeedEvil> yeah.
[02:25] <Laurenceb> same with quadcopter, but all 4 are identical
[02:25] <SpeedEvil> speeding up or slowing down fans induces pitch, yaw, or roll, depending on the thrust vector.
[02:25] <SpeedEvil> Add winds and stuff...
[02:25] <SpeedEvil> Having said that, my design is arguably more silly.
[02:26] <Laurenceb> well theres a matrix mapping inputs to outputs...
[02:26] <SpeedEvil> http://www.mauve.plus.com/test.png single prop with thrust vanes in the exhaust.
[02:26] <Laurenceb> so it should be mathematically possible
[02:26] <SpeedEvil> I'm not saying it's not theoretically possible to make it stable, as it obviously is.
[02:26] <Laurenceb> to make some sort of control loop construct
[02:26] <Laurenceb> SpeedEvil: you'll need to get rid of a lot of torque
[02:26] <SpeedEvil> Just that it might be deeply annoying when your prop falls off due to gyroscopic forces as you're trying to wibble it back and forth at 20Hz.
[02:27] <SpeedEvil> Laurenceb: I know.
[02:27] <SpeedEvil> Laurenceb: preliminary tests indicate it works. (static proof-of-concept test)
[02:27] <Laurenceb> you might be able to get away with three rotors
[02:27] <Laurenceb> twohalf size ones to cancle the torque
[02:28] <Laurenceb> or contra rotating props
[02:28] <Laurenceb> one above the other
[02:28] <SpeedEvil> I'm hoping to keep it simple.
[02:28] <SpeedEvil> 4 independantly controlled aero vanes in the exhaust, and one prop.
[02:28] <Laurenceb> how do you cancle the torque?
[02:28] <SpeedEvil> Nominal vane setting is to cancel torque
[02:28] <Laurenceb> :-S
[02:29] <Laurenceb> surely thats rather inefficient
[02:29] <Laurenceb> if your vanes are flat
[02:29] <SpeedEvil> Not.
[02:29] <SpeedEvil> Aerofoils.
[02:29] <SpeedEvil> O>
[02:31] <SpeedEvil> Also - there will be small control tabs on the outside surface that when in the normal fast ascent mode will counteract the torque somewhat more efficiently than the vanes.
[02:32] <SpeedEvil> http://www.mauve.plus.com/test.png - from below
[02:32] <Laurenceb> I see
[02:32] <Laurenceb> so you want fast ascent
[02:34] <SpeedEvil> yes.
[02:34] <SpeedEvil> 3 minutes to 1-4Km or so.
[02:34] <SpeedEvil> gigapixel pan.
[02:34] <SpeedEvil> land.
[02:35] <SpeedEvil> (on takeoff spot)
[02:37] <SpeedEvil> Hovering for a long time isn't part of the plan.
[02:38] <Laurenceb> yeah
[02:38] <Laurenceb> propcalc gives some interesting results
[02:38] <SpeedEvil> A nifty idea I've also had is that just snap it into a housing with a couple of wings on, and it's a plane.
[02:39] <Laurenceb> huge variations in static thrust
[02:39] <SpeedEvil> yeah
[02:39] <SpeedEvil> Large prop diameter is good.
[02:39] <Laurenceb> so I know the max power is 180W
[02:39] <SpeedEvil> 180W - but only at that max speed
[02:39] <Laurenceb> and I set it up with a 8x4 prop to give 620 grams thrust
[02:40] <Laurenceb> then adjusted the prop
[02:40] <SpeedEvil> so you want a prop with maximal diameter that gives the adequate static thrust.
[02:40] <Laurenceb> and it scales the rpm
[02:40] <SpeedEvil> at max RPM
[02:40] <Laurenceb> how does it scale the rpm?
[02:40] <SpeedEvil> It is fun to see the interplay of stuff.
[02:40] <Laurenceb> I dont follow everything
[02:40] <SpeedEvil> sorry - it's been some while since I used it
[02:40] <Laurenceb> how does it scale rpm as I change the prop?
[02:41] <SpeedEvil> IIRC the docs weren't bad.
[02:41] <Laurenceb> as I increase the prop size the thrust and the power go up, but rpm goes down
[02:42] <Laurenceb> so with about 120W power - a 10" prop, I get about 1.1Kg static thrust
[02:42] <SpeedEvil> at what RPM?
[02:42] <Laurenceb> 6100
[02:43] <SpeedEvil> does that motor produce 120W at 6100RPM though?
[02:43] <Laurenceb> dunno
[02:43] <Laurenceb> its 1000k/v
[02:43] <SpeedEvil> the max power will typically be quoted at teh max voltage
[02:43] <Laurenceb> so 1.1V
[02:43] <SpeedEvil> better motor vendors have nice graphs
[02:43] <Laurenceb> *11.1
[02:44] <SpeedEvil> It'll be interesting to see the Ospreys safety record.
[02:44] <SpeedEvil> Once it's fully in service.
[02:44] <Laurenceb> hehe
[02:45] <Laurenceb> the Kv is the no load speed right?
[02:45] <SpeedEvil> yes.
[02:45] <SpeedEvil> and it probably drops a bit at high speed due to windage and stuff
[02:45] <Laurenceb> so whats the relationship between that and the max power speed?
[02:45] <SpeedEvil> increasing voltage always increases max power
[02:45] <Laurenceb> sure
[02:45] <SpeedEvil> till it melts or demagnetises.
[02:46] <Laurenceb> but at the max i.e. freewheel speed, theres no power
[02:46] <SpeedEvil> As a first cut.
[02:47] <SpeedEvil> raise the voltage so that the internal resistance causes a current adequate to flow.
[02:47] <SpeedEvil> the max current
[02:55] akawaka (n=akawaka@external.treyarch.com) left irc: Read error: 110 (Connection timed out)
[03:55] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-6e9db400b3fc2fc7) joined #highaltitude.
[03:56] <hallam> fergusnoble: still around?
[03:56] <fergusnoble> hallam: yeah, was going to go to bed, but if your up for observing i can probably be roused with coffee
[03:56] <fergusnoble> eeepc has new screen! :)
[03:57] <hallam> woo
[03:57] <hallam> not observing, GPSin
[03:57] <hallam> g
[03:57] <hallam> I got some data into matlab
[03:57] <hallam> haven't acquired a sat yet, but working on it
[03:57] <fergusnoble> ok, sweet
[03:57] <hallam> having a brief interlude trying to get the case of the blue stick open
[03:58] <fergusnoble> ok, why do you need to open it?
[03:58] <fergusnoble> and how will you know when you get a sat?
[03:58] <hallam> wanted to see what's inside, and also to attach wires to get the data out
[03:58] <fergusnoble> ok, wanted to get the data out to where?
[03:59] <fergusnoble> doesnt it come out through the usb?
[04:00] <hallam> I told Greg i'd give it to him on three wires
[04:00] <fergusnoble> ok
[04:00] <hallam> yeah, for MATLAB purposes it's over USB
[04:00] <SpeedEvil> gnd, d+,d- :)
[04:00] <hallam> when I find the sat it will look like a nice peak in a 3D plot
[04:00] <hallam> har har
[04:00] <hallam> serial out, clk, sync
[04:01] <fergusnoble> awesome, using Laurenceb's code? or did you just knock something up?
[04:01] <hallam> well, I don't have the plot yet
[04:01] <fergusnoble> i know Laurenceb was showing off his peaks in his 3d plots
[04:01] <hallam> all I've done is look at the power spectral density
[04:01] <hallam> which looks vaguely like the graph in the datasheet
[04:02] <fergusnoble> cool
[04:02] <fergusnoble> different from the noise power you would get for no signal?
[04:02] <fergusnoble> or is the signal to weak to register on that plot?
[04:03] <hallam> oh yeah, it's just noise
[04:03] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-6e9db400b3fc2fc7) left #highaltitude.
[04:03] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-6e9db400b3fc2fc7) joined #highaltitude.
[04:03] <hallam> whoops
[04:08] <hallam> got it open, that took a while
[04:08] <hallam> of course all the interesting signals are under a can
[04:09] <Laurenceb> hi
[04:09] <hallam> another night owl
[04:09] <Laurenceb> god why am I up at this time
[04:09] <Laurenceb> :P
[04:09] <Laurenceb> you've opened up the SiGe ?
[04:09] <Laurenceb> interesting
[04:09] <hallam> yeah
[04:10] <hallam> not much to see unless you remove the cans
[04:10] <hallam> Laurenceb, what should my first steps be to make some sense of the I/Q data? book isn't here yet
[04:10] <Laurenceb> ok, its I,Q,I,Q ect
[04:10] <Laurenceb> so read the file as signed chars
[04:10] <hallam> yeah, done that
[04:11] <Laurenceb> then loop through taking complex(n)=data(n*n)+i*data(2*n-1);
[04:11] <hallam> and that
[04:11] <Laurenceb> then plot(abs(fft(complex)));
[04:11] <Laurenceb> what do you see?
[04:12] <Laurenceb> should be noise with a gaussian envelope
[04:12] <hallam> hang on, I'll put it up
[04:12] <Laurenceb> cool, thanks
[04:13] <Laurenceb> I'd be interested to see the bandwidth
[04:13] <hallam> what's that image pasting site you use?
[04:13] <Laurenceb> imagebin
[04:13] <hallam> http://imagebin.org/36366
[04:14] <Laurenceb> hmm same as mine
[04:14] <Laurenceb> ~3MHz bandwidth
[04:15] <hallam> yeah I guess they're using it in GPS mode
[04:15] <Laurenceb> if you ever get the case off I'd be interested to see what the filter select mode pin is at
[04:15] <hallam> I'll let you know if I do
[04:15] <Laurenceb> they say its ok for BOC(1,1)
[04:15] <Laurenceb> which is 4MHz
[04:15] <Laurenceb> thanks
[04:15] <Laurenceb> ok, next step you need a local oscillator
[04:16] <Laurenceb> then create a series of bins with 500Hz local osc spacings
[04:16] <Laurenceb> centered about 38KHz
[04:16] <Laurenceb> 10KHz either direction
[04:16] <hallam> where does the 38kHz come from?
[04:16] <Laurenceb> thats the IF
[04:16] <hallam> I know the usb utility says that in the readme
[04:16] <hallam> but the datasheet quotes 0Hz
[04:17] <Laurenceb> odd
[04:17] <hallam> do you know what the deal is there?
[04:17] <Laurenceb> 38KHz works for me
[04:17] <Laurenceb> nope
[04:17] <hallam> ok
[04:17] <Laurenceb> maybe the datasheet is trying to say its direct downconversion
[04:17] <Laurenceb> shall I pastebin my code? its a bit hard to explain everything over IRC
[04:18] <hallam> sure, that would be great :)
[04:19] <Laurenceb> do you have an ant and a window?
[04:19] <hallam> yes
[04:19] Action: Laurenceb searches for the right usb stick
[04:19] <hallam> the driver only works in 32 bit windows though, so I'd have to reboot to take more data, but I already took a couple of sessions
[04:19] <hallam> when I knew sats ought to be visible
[04:20] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-f8e9d66fbb9438ef) left irc: "http://www.mibbit.com ajax IRC Client"
[04:21] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-9c589f59095feade) joined #highaltitude.
[04:21] <hallam> or do you want us to try to capture the same data? :P
[04:21] <Laurenceb> my machine is being a pain
[04:21] <Laurenceb> hehe
[04:21] <Laurenceb> my window has poor visability
[04:21] <hallam> I can send you some data, except it's huge
[04:22] <hallam> thoguh I guess I could just send a few ms worth
[04:23] <Laurenceb> http://www.mibbit.com/pb/7Yo0uk
[04:23] <Laurenceb> http://www.mibbit.com/pb/EnbDDe
[04:27] <hallam> thanks!
[04:27] <hallam> that gives pretty much the same graph for every sat
[04:27] <Laurenceb> erm
[04:27] <Laurenceb> how many does it find?
[04:27] <hallam> none, I think
[04:28] <Laurenceb> maybe you need to adjust limit
[04:28] <hallam> correlation is 10185 plus or minus a few, for all of them
[04:29] <Laurenceb> hmm thats not right
[04:29] <fergusnoble> ok, bedtime for me
[04:29] <fergusnoble> gdnight
[04:29] <hallam> night F
[04:29] <hallam> do I have pants data?
[04:29] <Laurenceb> dont know
[04:29] <Laurenceb> that code is a bit old
[04:30] <Laurenceb> I'm not sure if it works
[04:30] <Laurenceb> for some reason my usb stick wont show up
[04:30] <Laurenceb> on my machine
[04:31] <Laurenceb> its there in device manager
[04:31] <Laurenceb> but its not mounted
[04:31] <hallam> tried removing it in device manager?
[04:31] <Laurenceb> hmm ok
[04:36] <Laurenceb> what does the graph look like?
[04:36] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[04:37] <hallam> one min
[04:38] <hallam> http://uploads.mibbit.com/up/cwCispdI.png
[04:38] <hallam> essentially the same for all of them
[04:39] <Laurenceb> snt look good
[04:39] <Laurenceb> I'm going to shut some stuff down here and try and get my machne running a bit better
[04:39] <Laurenceb> usb devices are all screwy and the screen keeps freezing :-/
[04:39] <Laurenceb> brb
[04:40] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-9c589f59095feade) left irc: "http://www.mibbit.com ajax IRC Client"
[04:42] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-2a98e1ac61df8b72) joined #highaltitude.
[04:42] <Laurenceb> seems to be better
[04:42] <Laurenceb> firefox was using 95% cpu
[04:42] <hallam> wb
[04:42] <Laurenceb> still no usb stick
[04:43] <Laurenceb> damn you windows
[04:43] <hallam> question: sample_size=1023*8*milliseconds;
[04:43] <hallam> why the 8?
[04:43] <Laurenceb> its at 8MHz
[04:43] <Laurenceb> approx
[04:43] <Laurenceb> 8*1023
[04:43] <hallam> ok
[04:44] <Laurenceb> how do I get an address bar in explorer?
[04:44] <hallam> View/Toolbars?
[04:44] <hallam> don't use it much I'm afraid
[04:44] <Laurenceb> hmm no luck with that
[04:44] <Laurenceb> I think D exists
[04:44] <Laurenceb> I'll try the terminal
[04:45] <Laurenceb> arg you have to keep on C:
[04:45] <hallam> could look in Disk Manager as well (right click My Computer, Manage)
[04:46] <Laurenceb> its appearing there
[04:46] <Laurenceb> how can I get to view the contents?
[04:47] <hallam> double click it
[04:47] <Laurenceb> that doesnt work
[04:47] <Laurenceb> but I can fire up notepad from the command line
[04:47] <Laurenceb> just a sec
[04:49] <Laurenceb> http://www.mibbit.com/pb/o2scCm
[04:49] <Laurenceb> got it
[04:49] <hallam> awesome
[04:50] <Laurenceb> no thanks to windoze
[04:51] <hallam> by golly, it seems to have found sv 15
[04:51] <hallam> now to see if that was actually in the sky
[04:52] <hallam> holy cow, it was
[04:52] <Laurenceb> :P
[04:53] <Laurenceb> try altering ms
[04:53] <Laurenceb> milliseconds=5; or something
[04:53] <Laurenceb> then just look for 15
[04:54] <Laurenceb> you should get nicer peaks
[04:54] <hallam> I just tried it on my other dataset and it found the two that should have been visible then
[04:54] <hallam> shit, I think this is already enough to work out the velocity of the rocket
[04:55] <Laurenceb> depends how accurate you want it
[04:55] <hallam> yeah actually I guess I'd need more freq bins
[04:55] <Laurenceb> but yeah, you could just grab some intervals of raw data
[04:55] <hallam> that's the plan
[04:55] <hallam> so
[04:55] <Laurenceb> if you increase milliseconds to 10
[04:56] <hallam> is it actually possible to get a complete position and velocity fix from 2ms of data, if you know when it was recorded to within <1s, and where to within 300km?
[04:56] <Laurenceb> then freq_res to 80*milliseconds
[04:56] <Laurenceb> then just run it off PRN15
[04:56] <Laurenceb> yeah
[04:56] <Laurenceb> if you have valid ephemeris
[04:56] <hallam> right, which you can get online
[04:57] <Laurenceb> its slightly more complex than a normal position fix
[04:57] <Laurenceb> as you need to have sat position as a function of time
[04:57] <hallam> right
[04:57] <hallam> I'm just thinking in terms of a recorder
[04:57] <Laurenceb> instead of deriving it from the data bits
[04:57] <Laurenceb> but its easily solvable on a laptop
[04:57] <Laurenceb> you solve for time,x,y,z
[04:58] <Laurenceb> then look at the doppler
[04:58] <hallam> it's much easier to save chunks of a few ms at a time, can be done with a simple microcontroller
[04:58] <Laurenceb> yeah
[04:58] <hallam> rather than streaming the full 16Mbit/s
[04:58] <hallam> cor, this eats the ram
[04:58] <Laurenceb> its doable with an AVR :D
[04:59] <Laurenceb> need to grab data from the spi at 2MHz
[04:59] <Laurenceb> then plonk in the RAM
[04:59] <hallam> only 2MHz?
[04:59] <Laurenceb> 8 bits
[04:59] <hallam> oh right
[04:59] <Laurenceb> 16/8=2
[04:59] <hallam> doesn't it have DMA?
[04:59] <Laurenceb> ooh xmega does
[04:59] <Laurenceb> yeah
[05:00] <hallam> do you think you could solve it in an AVR too? (given a few hours)
[05:00] <Laurenceb> but even with a mega168, SPIDR -> ram
[05:00] <Laurenceb> incr ram pointer
[05:00] <Laurenceb> ect
[05:00] <Laurenceb> hmm yeah maybe
[05:01] <Laurenceb> if you grabbed data then post processed
[05:01] <Laurenceb> but really you need to grab enough to get data bits
[05:01] <Laurenceb> or its harder as you have to put the sat position fnctions into the position solver
[05:03] <Laurenceb> I'd hope it would only take a few seconds
[05:03] <hallam> I think it's definitely within the capability of my 500MHz Blackfin though
[05:03] <hallam> not real-time
[05:03] <Laurenceb> yeah
[05:04] <hallam> I'd get the ephemeris data from a u-blox gps
[05:04] <Laurenceb> you really need some trackers
[05:04] <Laurenceb> hehe
[05:04] <Laurenceb> do you have a ublox binary protocol driver?
[05:04] <hallam> not yet
[05:04] <Laurenceb> I was planning to write one
[05:04] <hallam> but I have the datasheet
[05:04] <hallam> it would be cool to be able to telemeter back the apogee height while the rocket was descending
[05:04] <Laurenceb> to complement the TSIP one on the wiki
[05:04] <hallam> just in case bad things happen
[05:05] <Laurenceb> I'd just use a laptop on the ground to calculate it
[05:06] <hallam> actually I guess you could telemeter an couple of ms of IF data and do it on the ground
[05:06] <hallam> would only be a few kB
[05:06] <Laurenceb> yeah
[05:06] <Laurenceb> how can you detect apogee?
[05:06] <hallam> crudely from accelerometer data, but you don't have to
[05:07] <Laurenceb> yeah, newtonian dynamics
[05:07] <hallam> a frame at any point after motor burnout and before reentry defines the trajectory
[05:07] <Laurenceb> you'll have velocity and position
[05:07] <Laurenceb> hopefully very accurately as theres no multipath
[05:08] <Laurenceb> doppler off cars ect
[05:08] <Laurenceb> do the acquisition in very high resolution then fit a pseudorange/doppler solution to the peak
[05:09] <hallam> well you can do it in low res first, then refine it
[05:10] <Laurenceb> yeah
[05:10] <hallam> no point searching the whole freq space in 10Hz bins
[05:10] <Laurenceb> oh I wrote a c version of that code at the weekend
[05:10] <hallam> how much faster is it?
[05:10] <Laurenceb> about an order of magnitude
[05:10] <hallam> cool
[05:10] <Laurenceb> at least on my machine versus octave
[05:11] <Laurenceb> as I compiled it under ubuntu
[05:11] <Laurenceb> I used fftw3
[05:12] <hallam> stupid question: using high res frequency bins will actually give a peak accurate to that resolution, right? even though the code phase doesn't slip by a single chip below like 1kHz shift?
[05:12] <Laurenceb> well it depends
[05:13] <Laurenceb> on the integration lenght
[05:13] <Laurenceb> e.g. for 1ms, you have a peak in freq space approx 500Hz wide
[05:13] <Laurenceb> for 2ms, 250Hz ect
[05:13] <hallam> oh
[05:13] <hallam> right
[05:13] <Laurenceb> but if theres little multipath
[05:13] <hallam> understand
[05:13] <Laurenceb> you can fit to that curve
[05:13] <Laurenceb> the only limiting thing is noise
[05:14] <Laurenceb> obviously 2ms increases signal to noise
[05:14] <Laurenceb> so its a matter of how accurate you want v
[05:14] <hallam> how do you deal with the shift from the nav message? does it even matter?
[05:14] <Laurenceb> I'd guesstimate you get about 10m/s v error from 1ms
[05:15] <Laurenceb> it doepends how lucky you are
[05:15] <hallam> The Blackfin has 32MB ram, so I can grab a few seconds anyway
[05:15] <Laurenceb> if the nav bit transits in the middle of your intagration -> nothing
[05:15] <hallam> I'd like to grab the whole of the motor burn
[05:15] <Laurenceb> hallam: you can derive a fill solution form that much data
[05:15] <Laurenceb> *full
[05:16] <hallam> how come? I'd probably only get half a frame of nav message
[05:16] <hallam> don't you still need the ephemeris from elsewhere?
[05:16] <Laurenceb> hmm
[05:16] <Laurenceb> yeah
[05:16] <Laurenceb> I think thats enoug data to work out the sat time...
[05:16] <Laurenceb> cant remember now
[05:17] <hallam> depends if you get lucky and get the first word in the frame
[05:17] <hallam> I think
[05:17] <Laurenceb> how long is a frame?
[05:17] <hallam> 6s?
[05:17] <Laurenceb> ok
[05:17] <Laurenceb> 12MB
[05:18] <hallam> could be 6 if I run it in 8Mbit mode
[05:18] <Laurenceb> ah yes
[05:19] <Laurenceb> forgot about that mode
[05:19] <hallam> but I think you might need to get the first frame (there's a sequence of 5)
[05:19] <Laurenceb> http://www.colorado.edu/geography/gcraft/notes/gps/gps.html
[05:19] <SpeedEvil> However.
[05:19] <Laurenceb> http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif
[05:19] <SpeedEvil> If you're also recording on the ground, you wimply pattern match
[05:19] <SpeedEvil> so you only need to match the databits for a few bits
[05:19] <Laurenceb> look for TLM,HOW
[05:20] <hallam> http://gpsinformation.net/gpssignal.htm
[05:20] <SpeedEvil> commercial solutions use a 200ms grab
[05:20] <SpeedEvil> For geotaggoing
[05:20] <Laurenceb> SpeedEvil: and you get that info up into your rocket how?
[05:20] <SpeedEvil> Laurenceb: post analysis I mean
[05:20] <Laurenceb> you need an RTC on the rocket, and to recover the rocket
[05:21] <Laurenceb> actually, if your RTC has drifted by less than 10ms, you're ok
[05:21] <Laurenceb> as you only need a data bit transition
[05:21] <SpeedEvil> you can predict a lot of the data for a reasonable period.
[05:22] <SpeedEvil> In principle.
[05:22] <Laurenceb> how sensitive are crystals to rocket motor noise?
[05:22] <hallam> I wonder how much the RTC will drift as a function of the crystal getting squished by the.. yeah
[05:22] <Laurenceb> maybe not such a good plan
[05:23] <SpeedEvil> you have that problem anyway
[05:23] <hallam> I daresay it'll affect the sampler clock too
[05:23] <SpeedEvil> if your crystal is jittering, it'll affect the samples
[05:23] <Laurenceb> well you record after burnout
[05:23] <hallam> sure, but it would be nice to record during burn too
[05:24] <hallam> since post-processing would give you a millisecond resolution trajectory
[05:24] <Laurenceb> I think the 6s plan sounds best
[05:24] <SpeedEvil> accels + gyros will give a pretty accurate dead reckoning, even without GPS
[05:24] <Laurenceb> SpeedEvil: not really
[05:24] <hallam> I've heard tales of MEMS gyros sticking from the G
[05:24] <Laurenceb> look at my test data
[05:24] <SpeedEvil> Simple enough to test.
[05:24] <Laurenceb> thats without rocket motor noise
[05:24] <Laurenceb> which really screws things up
[05:24] <hallam> don't have a 50g centrifuge handy, but we're working on it
[05:24] <SpeedEvil> For vibration at least
[05:25] <Laurenceb> yor going to be 10s of Km out
[05:25] <SpeedEvil> hallam: yes, you do.
[05:25] Action: SpeedEvil points to hallams washing machine.
[05:25] <hallam> they pull that much?
[05:25] <SpeedEvil> Of that order.
[05:25] <SpeedEvil> 1200 RPM 60cm dia
[05:26] <hallam> could be interesting
[05:26] <SpeedEvil> that's 20 rps, or 60m/s, or 3600/.3 = 1000G
[05:26] <SpeedEvil> that's 20 rps, or 60m/s, or 3600/.3 = 100G
[05:26] Action: Laurenceb starts trying to fix his soundcard
[05:27] <Laurenceb> I seriously think its time to format c
[05:27] <SpeedEvil> That'd be an interesting IMU test.
[05:27] <SpeedEvil> Position error after 1 hour boil-wash and spin cycle.
[05:28] <Laurenceb> I had a good look at MEMS for N-prize
[05:28] <hallam> think of the temperature calibration
[05:28] <hallam> horizon sense is the way to go for N-prize I think
[05:28] <Laurenceb> I think if you have an attitude/time plan, its doable
[05:28] <hallam> orrr DIY GPS
[05:29] <Laurenceb> but an x,y,z ascent plan is a bit harder
[05:29] <SpeedEvil> MEMs won't cut it for navigation. It's quite adequate for apogee though.
[05:29] <SpeedEvil> magnetometers are nice
[05:29] <Laurenceb> SpeedEvil: thermopile+magno+gyros
[05:29] <SpeedEvil> ^(for a sounding rocket)
[05:29] <Laurenceb> will work very well
[05:29] <SpeedEvil> sun sensors too maybe
[05:30] <hallam> sensors out the wazoo
[05:30] <Laurenceb> but adding accel to try and find position is going to be out by 10s of Km at the very least
[05:30] <hallam> I don't know about that, Laurence
[05:30] <Laurenceb> hallam: rocket noise
[05:30] <hallam> it's effectively an impulsive trajectory
[05:31] <hallam> the noise should be mean zero, shouldn't it?
[05:31] <Laurenceb> on their own its a few km out after 5minutes
[05:31] <SpeedEvil> you don't measure teh rocket noise
[05:31] <Laurenceb> hallam: you cant capture it
[05:31] <SpeedEvil> you measure the 0G
[05:31] <hallam> but with a rocket you just have to measure a delta V
[05:31] <hallam> only one integration
[05:31] <Laurenceb> hallam: the sensors are nonlinear
[05:31] <Laurenceb> and high frequency noise is filtered out
[05:32] <hallam> what about some mechanical damping of the IMU box?
[05:32] <Laurenceb> it will help
[05:33] <Laurenceb> but it will actually filter out some relevant event
[05:33] <Laurenceb> *events
[05:33] <hallam> how do those accel-based small rocket altimeters work? do they just not?
[05:33] gregHome (n=gleblanc@75.108.33.75) left irc: Read error: 110 (Connection timed out)
[05:33] <Laurenceb> they only integrate over a short time
[05:33] <Laurenceb> http://wiki.ukhas.org.uk/_media/code:rough_position.png
[05:34] <Laurenceb> thats only drifting be 7g=70meters over 100 seconds
[05:34] <Laurenceb> but theres no rocket noise
[05:34] <Laurenceb> thats with the sparkfun ^DOF
[05:34] <Laurenceb> *6DOF
[05:35] <hallam> but I would also only integrate for the 3 second motor burn
[05:35] <hallam> or are you talking about n-prize?
[05:35] <Laurenceb> yeah
[05:35] <Laurenceb> n-prize
[05:35] <Laurenceb> specifically the nebula guy
[05:36] <hallam> oh ok nvm
[05:36] <hallam> who's the nebula guy?
[05:36] <Laurenceb> who claims he can do it with MEMS
[05:36] <Laurenceb> http://www.nebula-prize.com/
[05:38] <hallam> heh, he's going to recover it
[05:39] <hallam> that's just icing on the cake
[05:39] <Laurenceb> hmm hes saying 2 accels
[05:39] <Laurenceb> wonder why that is
[05:40] <SpeedEvil> IMO, that proposal has problems.
[05:40] <SpeedEvil> 999 pounds - and ground launch are _very_ difficult to hit
[05:41] <SpeedEvil> As you need to keep it below mach 1 for 30-60 seconds.
[05:41] <SpeedEvil> Otherwise aero losses eat you.
[05:42] <hallam> it's also SSTO, which is moderately hilarious
[05:42] <SpeedEvil> _completely_ hilarious.
[05:42] <SpeedEvil> At the masses involved anyway
[05:42] <SpeedEvil> SSTO, with recovery of the rocket.
[05:44] <hallam> yeah
[05:44] <hallam> at least the name is appropriate
[05:44] <SpeedEvil> SSTO with a small rocket might be marginally possible - but you're looking at stuff like filliment wound carbon fibre tanks, and radiatively cooled engines.
[05:45] <SpeedEvil> And even then it's probably damn tricky.
[05:45] <SpeedEvil> And engines made from platinum group metals are not known for their cheapness.
[05:45] <hallam> from the ground, too - as you said, drag losses are killer
[05:45] <SpeedEvil> Drop tanks can help a fair bit if you're willing to accept that cheat
[05:47] <SpeedEvil> I've been looking at this sort of thing for a while and have come to the conclusion that the cheapest way is to stage early and often.
[05:47] <SpeedEvil> At low Q points
[05:48] <SpeedEvil> With _lots_ of margin in each stage for underperformance.
[05:48] <SpeedEvil> But - no funding or time to properly develop these ideas.
[05:49] <Laurenceb> hmm those ST accels have better performance than AD
[05:49] <Laurenceb> interesting
[05:50] <Laurenceb> better than the SCA3000
[05:50] Action: SpeedEvil wonders how many satellite builders there are out ther.
[05:51] <Laurenceb> and freescale
[05:51] <SpeedEvil> I mean people who'd be willing to pay 100 quid to have 10 grams in orbit.
[05:51] <Laurenceb> best I've found so far
[05:52] <SpeedEvil> Did I link you to those spendy ones?
[05:52] <Laurenceb> and it has 16 bit SPI :D
[05:52] <Laurenceb> nope
[05:52] Action: SpeedEvil waits for email search to complete
[05:55] <SpeedEvil> http://www.inertial.co.uk/enquiries.shtml
[05:56] <SpeedEvil> http://www.inertial.co.uk/silicondesignsinc.shtml
[05:57] <Laurenceb> hmm the honeywell ones are an order of magnitude better than ST
[05:57] <Laurenceb> for noise
[06:01] <Laurenceb> not much info on the silicon designs ones
[06:02] <Laurenceb> your paying two orders of magnitude more for one order of magnitude better
[06:02] <SpeedEvil> Pretty much.
[06:03] <Laurenceb> thats the sort of stuff they use on sats
[06:03] <SpeedEvil> 5uG/sqrt(Hz) noise at +-2G
[06:03] <Laurenceb> which one?
[06:03] <SpeedEvil> 1221x-002
[06:04] <Laurenceb> ST is approx 150
[06:04] <SpeedEvil> http://www.silicondesigns.com/Pdf/1221.pdf
[06:05] <Laurenceb> someone plugged a power cable in back to front for a £20000 three axis gyro unit the other day
[06:05] <SpeedEvil> Oops.
[06:05] <SpeedEvil> 'It's probably only a fuse' ?
[06:06] <SpeedEvil> Killed it?
[06:06] <Laurenceb> yeah, all three fried
[06:07] <Laurenceb> they use a kalman filter running at 1Hz on an 386 single board computer
[06:08] <Laurenceb> these things turn very slowly
[06:09] <SpeedEvil> Are the gyros dead though...
[06:09] <Laurenceb> dunno
[06:09] <Laurenceb> not sure if you'll let me have them
[06:10] Action: SpeedEvil needs to go back to bed.
[06:10] <SpeedEvil> Night/morning/whatever.
[06:10] Action: SpeedEvil wishes for a 'sleep for 8 hours' button.
[06:14] <hallam> night
[06:39] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[07:27] gregHome (n=gleblanc@75.108.33.75) joined #highaltitude.
[07:31] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[07:39] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-2a98e1ac61df8b72) left irc: "http://www.mibbit.com ajax IRC Client"
[08:10] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[08:22] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[08:32] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-6e9db400b3fc2fc7) left irc: K-lined
[09:47] edmoore (n=ed@chu-gw.churchillcambridge.co.uk) left irc: Read error: 110 (Connection timed out)
[10:17] hallam (i=836fc8c8@gateway/web/ajax/mibbit.com/x-4f36bbee1a1843f6) joined #highaltitude.
[11:20] rharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[11:42] G8KHW (n=RocketBo@82.132.136.213) joined #highaltitude.
[11:48] G8KHW (n=RocketBo@82.132.136.213) left irc: "Bye chaps"
[12:06] G8KHW (n=RocketBo@82.132.136.221) joined #highaltitude.
[12:17] G8KHW (n=RocketBo@82.132.136.221) left #highaltitude ("Bye chaps").
[12:28] rharrison (n=rharriso@gateway.hgf.com) left irc:
[12:53] G8KHW (n=RocketBo@82.132.136.209) joined #highaltitude.
[12:54] G8KHW (n=RocketBo@82.132.136.209) left irc: Client Quit
[13:57] edmoore (n=ed@triangle.chu.cam.ac.uk) joined #highaltitude.
[14:00] rharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[14:00] <rharrison> afternoon all
[14:01] <rharrison> RM modules have arrived for testing
[14:01] <rharrison> Hopefully feb for first distance testing
[14:16] rharrison (n=rharriso@gateway.hgf.com) left irc:
[14:17] edmoore_ (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[14:32] edmoore (n=ed@triangle.chu.cam.ac.uk) left irc: Read error: 113 (No route to host)
[14:32] G8KHW (n=RocketBo@82.132.136.205) joined #highaltitude.
[14:44] <edmoore_> fergusnoble: ping
[14:44] Nick change: edmoore_ -> edmoore
[14:46] <fergusnoble> edmoore: hello
[14:46] <edmoore> any news?
[14:47] <fergusnoble> on what?
[14:47] <edmoore> anything
[14:47] <fergusnoble> henry has been doing some good stuff with the gps
[14:48] <fergusnoble> hes got the data off the stick into matlab and managed to identify a satellite
[14:48] <edmoore> yeah he's been skyping re: it. looks like fun stuff
[14:48] <fergusnoble> the scope works ok but very annoyingly its not the model with digital level and north
[14:48] <edmoore> would love to see the blackfin doing it in software
[14:48] <fergusnoble> are you going to hom?
[14:48] <fergusnoble> yeah would be cool
[14:48] <edmoore> was about to ask you that
[14:48] <edmoore> I thik I will
[14:48] <fergusnoble> im going
[14:49] <edmoore> not as busy as last fri now and if i don't make time for it i'll never find time for it. SO yes.
[14:49] <edmoore> repeater?
[14:49] <fergusnoble> at least it looks like the blackfin can store enough of a chunk in ram for a fix and then slowly put it onto the sd card
[14:49] <edmoore> sure yeah
[14:49] <fergusnoble> ok
[14:49] <edmoore> that would be ideal
[14:50] <fergusnoble> you set up for the repeater?
[14:50] <edmoore> yep
[14:50] <fergusnoble> cheaper than a phone call :)
[14:50] <edmoore> just stored all the settings to a memory
[14:52] <fergusnoble> what was that?
[14:52] <edmoore> esa
[15:02] <edmoore> henry needs to get onto the repeater
[15:02] <edmoore> oh that was what i was going to say
[15:03] <fergusnoble> yeah, would be good
[15:03] <fergusnoble> need another radio
[15:03] <edmoore> lucky I didn't get the SWR too hasitily as it doesn't do 169
[15:03] <fergusnoble> ok, are there any broadband ones?
[15:03] <edmoore> the only ones which to 169 seem to be decicated VHF and up. So we may have to get two - one HF and one VHF+
[15:03] <fergusnoble> ok, not a problem
[15:04] <gordonjcp> edmoore: it will do 169
[15:04] <edmoore> go on
[15:04] <gordonjcp> if it does 144 it will be just dandy on 169
[15:05] <fergusnoble> edmoore: wonder if we could get steve on the repeater, might be pushing it a bit
[15:05] <edmoore> ok. It's just it advertised itself as have two metering units - one for 1.6-160 MHZ and one from 200 to 500mhz
[15:05] <gordonjcp> edmoore: it will probably be okay to some extent even on UHF
[15:05] <gordonjcp> sounds about right
[15:05] <edmoore> ok cool
[15:05] <edmoore> will go for it then
[15:05] <gordonjcp> 169 isn't *that* far from 144
[15:05] <gordonjcp> it might not be accurate
[15:05] <gordonjcp> but SWR meters don't need to be accurate
[15:06] <edmoore> actually the second one seems to go down as low as VHF, looking deeper
[15:06] <edmoore> so i guess that will be gravy
[15:06] <fergusnoble> yeah, you should get one that can do hf as well, so you can make yourself an hf antenna
[15:06] <gordonjcp> if you can see the reflected power change when you tune the aerial, it works
[15:06] <edmoore> gordonjcp: you're saving us lots of money and time at the moment :)
[15:06] <gordonjcp> it's not like a voltmeter
[15:07] <fergusnoble> edmoore: what time are you going to be picking us up?
[15:07] <edmoore> fergusnoble: suggest we purchase some 169 radiometrix rx/tx pairs
[15:07] <gordonjcp> edmoore: a SWR meter doesn't need to tell you exactly how much power is reflected, it just needs to tell you "LOADS/SOME/NOT MUCH/NONE"
[15:07] <edmoore> fergusnoble: well it's gonna have to be soon
[15:07] <fergusnoble> edmoore: yup, sounds good, also get a 434 rx, and maybe some more 434 rxs
[15:07] <fergusnoble> *txs
[15:07] <gordonjcp> LOADS is "ZOMG OH NOES SWITCH IT OFF!", "NONE" is "your coax is full of water"
[15:08] <edmoore> sure. let's make an nice big order
[15:08] <gordonjcp> you're aiming for "NOT MUCH"
[15:08] <fergusnoble> gordonjcp: i had to do an exam question yesterday about coax full of water
[15:08] <gordonjcp> yeah?
[15:09] <fergusnoble> gordonjcp: it worked out that the section filled with water was exactly a 1/4 wavelength long
[15:09] <gordonjcp> what was the question?
[15:09] <fergusnoble> hehe
[15:09] <edmoore> i had that in an examples paper, i remember
[15:09] <gordonjcp> heh
[15:09] <gordonjcp> meh, just increase QRO until you dry it out
[15:09] <fergusnoble> it had some spiel about a tv company not maintining their cables and one getting full of water
[15:09] <SpeedEvil> It's got a dielectric costant similar to most plastics doesn't it?
[15:09] <edmoore> worded like 'some pillock drops his cable in a pond, but then wonders how this will affect its characteristics' or something else tenuous like that
[15:10] <fergusnoble> and you had to work out what the transmission and reflection coefficients were through this bit of water
[15:10] <fergusnoble> but had to work it out from the geometry of the coax and the relative permittivity of water
[15:11] <fergusnoble> was quite a good question, if not a little rediculous
[15:11] <edmoore> fergusnoble: it may be that time is tighter than I thought
[15:11] <edmoore> it's be half past before we got there
[15:11] <edmoore> may be worth just doing whatever in town
[15:11] <fergusnoble> ok, shall i walk up then?
[15:11] <edmoore> ok
[15:11] <edmoore> i'll see you there at 4
[15:12] <fergusnoble> ok, cool
[15:12] <fergusnoble> ok, got to do some stuff, bbl
[15:12] <edmoore> cya
[15:13] Nick change: edmoore -> M0TEK
[15:13] Nick change: M0TEK -> edmoore
[15:31] G8KHW (n=RocketBo@82.132.136.205) left irc: "Bye chaps"
[16:07] The_Compiler (n=dsmoddin@unaffiliated/the-compiler) joined #highaltitude.
[17:01] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[17:02] Nick change: Bluenarf -> EI5GTB
[17:06] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[17:30] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[17:39] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[18:11] <fergusnoble> edmoore: back yet?
[18:11] <edmoore> no, i am walking particularly slowly from the CMS to churchill
[18:11] <fergusnoble> with your eee?
[18:12] <edmoore> no that was a joke
[18:12] <edmoore> i am back
[18:12] <fergusnoble> i see
[18:12] <fergusnoble> hows tricks?
[18:12] <fergusnoble> since i saw you 10 mins ago
[18:12] <edmoore> good indeed
[18:12] <edmoore> it was about 40 minutes ago
[18:13] <fergusnoble> anyway, what is the most productive use of my time this evening?
[18:13] <edmoore> could get some pesky degree out of the way?
[18:14] <fergusnoble> i could work on th badger code, the predictor, the telescope or degree work i guess
[18:14] <fergusnoble> the latter option is unlikely
[18:14] <edmoore> could you ping me the format of the csv file?
[18:14] <edmoore> also, might you maypole tomorrow?
[18:15] <edmoore> I feel a bit of compunction. They did get us the full license + I know martin is keen to talk about the talk
[18:15] <fergusnoble> yeah, i can probab ly come
[18:16] <EI5GTB> the college im going to do EE in net year had 2 applicants for the course last year :D
[18:17] <edmoore> 2 hundred?
[18:20] <EI5GTB> nope, 2 people
[18:20] <EI5GTB> so.. if you can fill out the application form your in
[18:21] <edmoore> why are you applying there?
[18:22] <EI5GTB> its a great colledge
[18:22] <EI5GTB> ots close to where i live
[18:23] <EI5GTB> and because of the low demand up here i only need to be able to fill out the applicaion form to get in
[18:23] <EI5GTB> so yea... why wouldnt i apply?
[18:28] <EI5GTB> they have one of the top engineering departments in the country
[18:43] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[18:44] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[18:52] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[19:43] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[19:50] Xenion (n=robert@p579FCF84.dip.t-dialin.net) joined #highaltitude.
[19:51] The_Compiler (n=dsmoddin@unaffiliated/the-compiler) left irc: Read error: 60 (Operation timed out)
[19:54] natrium42_ (n=natrium4@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[19:58] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[19:58] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[20:12] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[20:17] <fergusnoble> hallam: you there?
[20:17] <fergusnoble> know anything about reducing stack usage in C?
[20:18] <fergusnoble> i have some local arrays that i could make static which i guess would help
[20:18] <fergusnoble> but im struggling to account for what could be using like 10k of ram in a pretty simple piece of code
[20:25] <RocketBoy> Libraries?
[20:32] <fergusnoble> RocketBoy: not using any
[20:43] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[21:00] <hallam> hello
[21:00] <hallam> fergusnoble: have you tried changing the -O setting on the compiler?
[21:00] <fergusnoble> nope, thats a good point
[21:01] <fergusnoble> its compiling in debug mode i.e. no optimisations
[21:01] <fergusnoble> -O3 tends to be a good medium doesnt it?
[21:01] <hallam> usually
[21:02] <hallam> I don't thing debug mode necessarily has *no* optimisations, just not any that totally screw with the code layout
[21:03] <hallam> might it actually be debug data that's the problem?
[21:03] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[21:03] <hallam> too much -O can increase ram usage
[21:03] <hallam> 10k is a whole lot though
[21:03] <natrium42> try -Obama obtimization
[21:03] rjharrison (n=rharriso@80.176.172.227) left irc: Read error: 60 (Operation timed out)
[21:04] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[21:06] <hallam> I'm sure there's a witty reply to that, I just can't quite put my finger on it right now
[21:07] <fergusnoble> hallam: ive at least slightly fixed some of the sd card writing
[21:07] <fergusnoble> dinner now but bbl
[21:07] <hallam> cool, well done
[21:12] <hallam> [OT] this is a nice article: http://carlbrannen.wordpress.com/2007/07/14/measuring-the-speed-of-gravity-waves/
[21:25] akawaka (n=akawaka@external.treyarch.com) joined #highaltitude.
[21:30] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[22:11] Xenion (n=robert@p579FCF84.dip.t-dialin.net) left irc: "Verlassend"
[22:11] <SpeedEvil> I have a slight problem with all theory in advance of data.
[22:12] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[22:12] <SpeedEvil> Having said that, I really want to move from einstein to something more interesting.
[22:13] <SpeedEvil> Where more interesting is allowing fun stuff like FTL, ...
[22:14] <SpeedEvil> Hard part is working out a significant route to that that's not blocked utterly by the tiny uncertainties in existing measurements.
[22:14] <SpeedEvil> Well - and hoping the universe is cooperative.
[22:15] Action: SpeedEvil puts on his anti-gravity belt, and zooms off.
[22:39] <fergusnoble> SpeedEvil: FTL causes pretty serious paradoxes
[22:39] <fergusnoble> SpeedEvil: more than just measurement uncertainty :p
[22:39] <fergusnoble> as im sure you well know
[22:40] <SpeedEvil> Where FTL is a loose shorthand for 'fun stuff'.
[22:40] <fergusnoble> yeah i guess there are some things
[22:41] <fergusnoble> but most of them involve more power than several stars can provide
[22:41] <SpeedEvil> For example, where there turn out to be ways of accellerating to .9999C rapidly without the conventional amount of energy, so you get extreme time dilation, not FTL, but may as well be if you don't go home.
[22:41] <SpeedEvil> yeah.
[22:42] <SpeedEvil> Any recipie that begins 'Take one superjovian of exotic matter'
[22:42] <SpeedEvil> Is kind of an engineering challenge.
[22:44] <SpeedEvil> Latest CERN scandal. Order of 1500 exotic dancers.
[22:44] <fergusnoble> unfortunately most of this kind of stuff is still in the realms of well tested theory
[22:44] <SpeedEvil> Yep.
[22:44] <SpeedEvil> Gotta have a _really_ good excuse if you're trumping existing measurements.
[22:44] <fergusnoble> so there is little chance of something new round the corner allowing you to do drastically different things
[22:45] <fergusnoble> but i guess people were saying that in 1904
[22:45] <fergusnoble> maybe i need to have more vision
[22:45] <SpeedEvil> That, and high energy particles exist in nature, so if they did _really_ exotic stuff in some interactions, you've gotta explain why we don't see it.
[22:46] <fergusnoble> exactly
[22:46] <fergusnoble> brb
[22:49] Laurenceb (n=laurence@dyres221-35.surrey.ac.uk) joined #highaltitude.
[22:49] <Laurenceb> hi
[22:53] <SpeedEvil> As I see it, the traditional 'Go over 0.5C in your spaceship and you go to warp' have a probability of zero. Anything that works is going to have to be clever. See reducing drag in torpedos by going to supercavitating designs, rather than just trying to marginally improve existing ones, or fitting more powerful motors.
[22:54] <Laurenceb> http://news.bbc.co.uk/newsbeat/hi/entertainment/newsid_7842000/7842682.stm
[22:54] <Laurenceb> he lives in ashbourne :P
[22:56] Action: SpeedEvil offers a 100 quid prize for the first HAB to go superluminal.
[23:02] <Laurenceb> he'll probably have tons of press round his house now
[23:03] <SpeedEvil> That's why you have the jump-ramp on the exit from the garage, silly.
[23:08] <Laurenceb> I know his dad thats freaky
[23:10] <hallam> hi Laurenceb
[23:10] <hallam> I sped your code up a bit, would you like it back? :)
[23:10] <Laurenceb> k
[23:10] <hallam> ok I'll just tidy it
[23:10] <Laurenceb> thanks
[23:12] <Laurenceb> yeah I havent used matlab much
[23:12] kc0wys (n=kc0wys@75-130-209-194.dhcp.stls.mo.charter.com) joined #highaltitude.
[23:12] <Laurenceb> theres vectorisation and all that
[23:13] <hallam> right, and often something that you think will make it faster actually makes it slower, it's disconcerting
[23:14] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[23:15] <fergusnoble> hallam: any news on the gps?
[23:15] <fergusnoble> i saw in the logs you were close to getting velocity out?!
[23:24] <hallam> Laurenceb: http://uploads.mibbit.com/up/9p6sR2ur.m
[23:24] <Laurenceb> theres no newlines
[23:24] <hallam> fergusnoble: I've been using a modified version of laurence's acquisition code
[23:25] <hallam> I also wrote my own but his uses a faster method
[23:25] <hallam> it can identify all satellites in view and find their doppler shift and code phase
[23:26] <Laurenceb> s/;/;\n
[23:26] <hallam> if you know the start location and where the sats are, that should let you get a crude-ish velocity for the rocket
[23:26] <hallam> oh, whoops
[23:27] <hallam> http://pastebin.com/m25fc91e7
[23:27] <fergusnoble> hallam: i thought that was all you needed for the position lsbs to like 300km like we discussed?
[23:27] <fergusnoble> given the almanac and ephemeris
[23:28] <fergusnoble> but good work!
[23:28] <fergusnoble> what are you working on now?
[23:29] <hallam> yeah this is really only meant for acquisition of the sats rather than tracking them
[23:29] <hallam> it might be enough on its own to get position, but it would be slow to execute over the whole flight
[23:29] <hallam> don't worry, we'll get the whole thing done, this is just the first stage
[23:29] <fergusnoble> yep cool
[23:29] <SpeedEvil> You can get position without the data bits. - see http://en.wikipedia.org/wiki/Transit
[23:29] <SpeedEvil> But - that'd be silly
[23:29] <fergusnoble> im suprised youve made such headway so quickly
[23:30] <hallam> Laurenceb was a big help
[23:30] <SpeedEvil> GPS is not fundamentally hard.
[23:30] <Laurenceb> :P
[23:30] <Laurenceb> hallam: you could setup a costas and delay locked loop
[23:30] <fergusnoble> Laurenceb: yeah, looks like you've put a lot of work in!
[23:30] <hallam> it's a steep learning curve at first
[23:30] <SpeedEvil> The hard part of GPS is not doing it on a proper computer with lots of CPU.
[23:30] <Laurenceb> thats the next stage
[23:30] <SpeedEvil> The hard part is getting it cheap, reliable in poor signals, ...
[23:31] <Laurenceb> once you have the info from the acquisition, you can initialise the tracking loops
[23:31] <hallam> Laurenceb (and SpeedEvil I guess) I have a question
[23:31] Action: SpeedEvil has a flavour.
[23:32] <SpeedEvil> (It's a really nice pasta sauce, with salami, kabernosi, lots of tomato, oregano, lemons, olive oil, ...)
[23:32] <hallam> I was using my own code rather than Laurenceb's - mine does both code phase and freq search the slow way (code phase in time domain, freq in freq domain)
[23:32] <hallam> anyway, it can find the sats, their dopplers and code phase just fine
[23:33] <hallam> but the phase of the maximum correlation seems to change from ms to ms
[23:33] <SpeedEvil> that's noise.
[23:33] <SpeedEvil> Probably.
[23:33] <Laurenceb> yeah
[23:33] <Laurenceb> how much does it change?
[23:33] <hallam> lots
[23:33] <SpeedEvil> There is quite a lot of noise at the single frame level.
[23:33] <hallam> it looked almost like it was alternating from -1 to 1 from ms to ms
[23:33] <Laurenceb> thats not right
[23:33] <Laurenceb> -1 to 1 ?
[23:34] <SpeedEvil> you know the phase of the data bit changes the phase of the code?
[23:34] <hallam> er, pi to -pi
[23:34] <SpeedEvil> inverts it?
[23:34] <hallam> yeah I know
[23:34] <hallam> but this was happening on a ms basis, not 20ms
[23:34] <SpeedEvil> You mean it was varying +-1 chip - a microsecond
[23:35] <hallam> no, I don't think so
[23:35] <SpeedEvil> Because -1ms and 1ms on a 1ms interval are the same thing
[23:35] <hallam> the code phase stayed the same over many ms
[23:35] <Laurenceb> right...
[23:35] <SpeedEvil> (assuming no navigation bit edge)
[23:35] <hallam> well
[23:35] <hallam> even with nav bit edges, the code phase should stay the same, right?
[23:35] <SpeedEvil> What is the general term for a whole cycle of the PRN?
[23:36] <hallam> general term?
[23:36] <SpeedEvil> the code phase stays the same, but it invertys
[23:36] <hallam> right
[23:36] <SpeedEvil> chip is for one bit of the PRNs output.
[23:36] <hallam> so your correlation should go from something positive to something negative
[23:36] <Laurenceb> yes
[23:36] <SpeedEvil> I was wondering if there was a proper term for '1023 chips'
[23:36] <hallam> millisecond :P
[23:36] <SpeedEvil> I was using 'symbol' in the past
[23:37] <hallam> makes sense
[23:37] <hallam> ok
[23:37] <SpeedEvil> but that was just something I made up.
[23:37] <SpeedEvil> Or a chipshop :)
[23:37] <SpeedEvil> The code phase should not change, no.
[23:38] <hallam> now the correlation is the maximum value of the dot product of the PRN with the (local osc * sampled data)
[23:38] <hallam> right?
[23:38] <SpeedEvil> You are doing I and Q?
[23:38] <hallam> as you sweep the PRN offset
[23:38] <hallam> yeah
[23:38] <SpeedEvil> and multiplying properly?
[23:38] <hallam> yeah there's a conjugate in there somewhere
[23:38] <hallam> I think I'm multiplying properly
[23:39] <SpeedEvil> I just did it by making seperate I and Q outputs.
[23:39] <SpeedEvil> and then MACing along the PRN with the input signal.
[23:39] <Laurenceb> http://pastebin.com/m22223a5d
[23:39] <SpeedEvil> to generate a value for I and Q, then do that.
[23:39] <Laurenceb> ^ slightly easier to read
[23:39] <Laurenceb> SpeedEvil: your frontend isnt direct downconversion
[23:40] <Laurenceb> so a bit easier to do that
[23:40] <Laurenceb> SpeedEvil: do you have a maxim front end?
[23:40] <hallam> SpeedEvil: I and Q outputs of what, the front end?
[23:40] <SpeedEvil> Laurenceb: that's what I've been writing code for.
[23:40] <SpeedEvil> Well - timed psuedocode.
[23:41] <hallam> our front end gives I and Q samples, with a "near zero IF" - the datasheet quotes 0Hz, but it actually seems to be 38kHz
[23:42] <SpeedEvil> hallam: take the input signal(s), generate the PRN with +-0.125 chips. Multiply the incoming bitstream with the delayed or not-delayed PRN. Call these I and Q. The output phase reflects the chip phase.
[23:42] <SpeedEvil> multiply-accumumate over the 1ms
[23:42] <hallam> oh, interesting
[23:43] <SpeedEvil> Well - chip phase * navigation bit value
[23:43] <Laurenceb> SpeedEvil: what about carrier?
[23:44] <SpeedEvil> Laurenceb: this is assuming that you take out hte carrier by appropriately modifying the PRN signal sort-of
[23:44] <Laurenceb> ok
[23:44] <Laurenceb> but you need a carrier tracking loop
[23:44] <Laurenceb> as doppler shifts in time
[23:44] <hallam> SpeedEvil: is this for tracking or acq?
[23:45] <Laurenceb> couldnt you do acquisition by biasing your tracking loops so they search through delay/doppler space by them selves?
[23:45] gordonjcp (n=gordonjc@symmetria.fi) left irc: Remote closed the connection
[23:45] <SpeedEvil> I was ignoring doppler.
[23:46] <SpeedEvil> I'm dealing with doppler at the higher level - the IQ outputs at 1KHz from each satellite go to the higher level.
[23:46] <fergusnoble> hallam: so its looking like the fat library im using doesnt update the FAT unless you call fsync
[23:46] <fergusnoble> hallam: which i was doing, but not after every write, only periodically
[23:46] <SpeedEvil> The higher level blips the code phase of the lower level tracking loop occasionally to keep it locked.
[23:47] <Laurenceb> yeah
[23:47] <Laurenceb> sounds like one plan
[23:47] <Laurenceb> how long is your integration period?
[23:48] <Laurenceb> with convensional receivers behaviour is determined by the tracking loop filters
[23:48] <hallam> damn it
[23:48] <Laurenceb> ?
[23:48] <hallam> my brain totally had its tracking loops locked on this conversation, but now I've lost it
[23:48] gordonjcp (n=gordonjc@symmetria.fi) joined #highaltitude.
[23:49] gordonjcp (n=gordonjc@symmetria.fi) left irc: Remote closed the connection
[23:49] <hallam> fergusnoble: does fsyncing after every write do the job?
[23:49] <SpeedEvil> Laurenceb: 1ms, the integration is really all done in the higher level code, that gets 2 numbers per satellite at 1KHz
[23:49] gordonjcp (n=gordonjc@symmetria.fi) joined #highaltitude.
[23:49] gordonjcp (n=gordonjc@symmetria.fi) left irc: Client Quit
[23:49] <fergusnoble> hallam: im still investigating
[23:49] <Laurenceb> hmm
[23:49] <fergusnoble> hallam: i turned up a few other minor bugs which were clouding the issue too
[23:49] <Laurenceb> SpeedEvil: thats a decoherent integration
[23:50] <fergusnoble> hallam: but its looking good so far, havnt observed corruption since i made the changes
[23:50] <fergusnoble> will run an overnight stress test
[23:50] <SpeedEvil> Laurenceb: I'm not aiming at ultimate accuracy in this design, but least CPU.
[23:50] <Laurenceb> yeah
[23:50] <Laurenceb> it should work
[23:51] <hallam> nice
[23:51] <Laurenceb> but convensional loops with adjustable parameters give the best indoor performance ect
[23:51] gordonjcp (n=gordonjc@symmetria.fi) joined #highaltitude.
[23:51] <SpeedEvil> Laurenceb: I'm not seeing hte obvious difference.
[23:51] <hallam> ok
[23:51] <hallam> so
[23:51] <Laurenceb> I've seen one design that uses continuously varying early/late spacing to map out the correlation peak
[23:52] <Laurenceb> then identify multipaths
[23:52] <hallam> let's say I run either mine or Laurence's acqusition program once for every ms of the signal
[23:52] <Laurenceb> rather slow
[23:52] <hallam> sure
[23:52] <hallam> just a gedanken
[23:52] <SpeedEvil> Laurenceb: if I have all the input signal correlated correctly so that the I/Q outputs are synced enough to capture all the signal - where is the difference?
[23:52] <Laurenceb> none
[23:53] <Laurenceb> the iddue is you have to achieve that
[23:53] <hallam> just look at one SV
[23:53] <SpeedEvil> Laurenceb: Ah - you mean lock issues.
[23:53] <Laurenceb> indeed
[23:53] <SpeedEvil> Laurenceb: yeah. Massively parallel correlators ++
[23:53] <hallam> it finds the code phase for every ms, which changes only very slowly
[23:53] <Laurenceb> under conditions of multipath, signal fading ect
[23:54] <hallam> you plot the maximum correlation for every ms, which is a complex number
[23:54] <Laurenceb> SpeedEvil: tracking loops open up the possibility of schemes like I described for good indoor/multipath performnce
[23:55] <hallam> not the code phase of max correlation, but the correlation itself
[23:55] <hallam> what should that look like?\
[23:55] Action: Laurenceb head assplode
[23:55] <SpeedEvil> Laurenceb: doesn't that require more than 2 correlators per PRN?
[23:55] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[23:55] <Laurenceb> depends what you call a correlator
[23:56] <SpeedEvil> Laurenceb: I mean a device that takes a locally generated PRN, and MACs it with the input signal.
[23:56] <Laurenceb> hallam: I've forgotten all the fourier stuff :-/
[23:56] <SpeedEvil> Laurenceb: or something that does the equivalent in the frequency domain.
[23:56] <Laurenceb> ah ok
[23:56] <SpeedEvil> Laurenceb: for example, if you have 2048 correlators per PRN, then you have - pretty much - no lock issues.
[23:56] <Laurenceb> then a tracking loop is two or three correlators
[23:57] <Laurenceb> early,prompt,late
[23:57] <Laurenceb> or just early and late
[23:57] <Laurenceb> or some designs use prompt and early-late
[23:57] <SpeedEvil> Or even one, and dither
[23:57] <Laurenceb> hmm good point
[23:58] <Laurenceb> but you essencially chuck some information away like that
[23:58] <SpeedEvil> Of course.
[23:58] <SpeedEvil> Depends on what you want.
[23:58] <SpeedEvil> For some stuff an old-skool 1 channel GPS is just fine.
[23:59] <Laurenceb> http://en.wikipedia.org/wiki/Cross-correlation
[00:00] --- Thu Jan 22 2009