highaltitude.log.20061212

[00:36] kc0wys (n=macfreak@24-107-152-228.dhcp.stls.mo.charter.com) joined #highaltitude.
[00:52] kc0wys (n=macfreak@24-107-152-228.dhcp.stls.mo.charter.com) left irc: "¡Ayúdame!"
[03:54] kc0wys (n=kc0wys@24-107-152-228.dhcp.stls.mo.charter.com) joined #highaltitude.
[03:54] kc0wys (n=kc0wys@24-107-152-228.dhcp.stls.mo.charter.com) left irc: Client Quit
[04:03] icez_ (n=icez@ip68-3-56-121.ph.ph.cox.net) joined #highaltitude.
[04:10] icez (n=icez@ip68-3-56-121.ph.ph.cox.net) left irc: Read error: 60 (Operation timed out)
[04:21] defy (n=defy@60-234-174-220.bitstream.orcon.net.nz) left irc: Read error: 113 (No route to host)
[05:55] icez_ (n=icez@ip68-3-56-121.ph.ph.cox.net) left irc: Remote closed the connection
[11:40] defy (n=defy@60-234-174-220.bitstream.orcon.net.nz) joined #highaltitude.
[12:33] qdot (n=mlodutb@18.125.0.112) joined #highaltitude.
[13:39] Nick change: Tiger^_ -> Tiger^
[14:20] icez (n=icez@ip68-3-56-121.ph.ph.cox.net) joined #highaltitude.
[16:27] Ebola (n=Ebola@host81-152-204-231.range81-152.btcentralplus.com) joined #highaltitude.
[18:57] rocketboy (n=steve@217.47.75.133) joined #highaltitude.
[20:14] LaurenceB (n=laurence@host86-137-224-84.range86-137.btcentralplus.com) joined #highaltitude.
[20:15] <LaurenceB> Hi everyone
[20:17] <LaurenceB> rocketboy: I just sent you an email :D
[21:02] <rocketboy> sorry Laurence - I was just cuttind some code
[21:05] <LaurenceB> What for?
[21:06] <rocketboy> a balloon payload
[21:06] <LaurenceB> I've been trying to get my unit from display 3000 to work but no luck, it's just running a demo pogram
[21:06] <rocketboy> just getting this PIC to parse GPS
[21:06] <LaurenceB> Are you using C?
[21:07] <rocketboy> yes PIC18 C
[21:07] <LaurenceB> I've got the full version of bascom now
[21:07] <rocketboy> there are a few extra reserved words for controlling proram and data space
[21:08] <rocketboy> I have never been a fan of basic - I have used it though - going back to the legindary ZX81
[21:08] <LaurenceB> Thats interesting, I've been keen on bascom as it has lots o libraries for micros
[21:09] <LaurenceB> It makes things very fast, you can parse strings with a few lines of code
[21:10] <LaurenceB> I find basic a bit stupid as it uses wods for everything, it's too much to type and the code is hard to follow
[21:10] <LaurenceB> -words
[21:11] <rocketboy> so bascom is quite different to basic?
[21:13] <LaurenceB> No it's basic, I'm just saying I don't really like it, I just use it as it has no end of inbuilt functions and very good documentation
[21:13] <LaurenceB> It even supports FAT32 and can run as a webserver
[21:14] <LaurenceB> One guy has a bascom site running off a solar powered micro on his windowsill!
[21:14] <rocketboy> To be honest I haven't really got a hang up over basic/C/pascal... especialy for this application - as long as it can process strings and floating point and handle interrupts some how
[21:15] <rocketboy> yeah FAT32 support would be good - I was thinking of coding that myself for and SD card on the PIC
[21:16] <LaurenceB> you can solder a micro straight onto a harddrive (almost) and bascom can take care of the rest, a few lines of code and you can reformat, write files ect.
[21:16] <rocketboy> and a SD card?
[21:16] <LaurenceB> It also supports SD MMC compactflash ect
[21:17] <LaurenceB> Unfortunately it wont install on my laptop lol
[21:17] <LaurenceB> I've now got it running by copying a dll from another installation
[21:18] <LaurenceB> The problem is that when I try to program the unit I bought from display3000 the micro will not ID itself to the programmer
[21:20] <LaurenceB> AVRs ID themselves to the programmer then the programming SW only goes ahead if the target micro in the code is correct
[21:21] <LaurenceB> Correction the main code is in one hex file and the target processor is in another file output by the compiler
[21:22] <LaurenceB> I can only guess it's set to use JTAG or the port is fried (I've seen this happen before)
[21:22] <rocketboy> so periphereals have an ID that is recogined by the target processor - which then uses the right code
[21:23] <LaurenceB> Other way round, processors have an ID recognised by programmer
[21:23] <rocketboy> humm - yes fried chips - I fried 2 x PIC recently
[21:24] <LaurenceB> AVR's are virtually impossible to fry, you just take out some of the internal hardware
[21:24] <LaurenceB> I'm guessing the In system programming is fried
[21:25] <LaurenceB> I'll blame it on the guy in Germany, as I've just soldered a battery on
[21:25] <LaurenceB> So I've asked him if I can send it back
[21:27] <LaurenceB> If you look on the atmel site, theres some cool stuff like an avr micro with inbuilt JPEG and MP3 decoding
[21:29] <LaurenceB> Theres a site somewhere (I've forgotten) where someones built the "YPOD" music player and photo viewer with one, it's pretty cool
[21:29] <LaurenceB> Anyway are you launching a payload in January?
[21:30] <rocketboy> hope to - just somthing basic - GPS,Radio,phone,camera
[21:30] <LaurenceB> Have you got a phone working yet?
[21:31] <rocketboy> no not yet - but I have some code that should work
[21:31] <LaurenceB> I found the phone quite tricky, but I didn't know about how meggage centers worked ect.
[21:31] <LaurenceB> -message
[21:32] <rocketboy> I'm starting with the GPS parser - so far I have the USART working - I can send and recive strings
[21:32] <LaurenceB> Are you using buffered serial input
[21:33] <LaurenceB> I've set up buffered input for my glider servo test rig, but even though it collects all the strings, 1hz is not fast enough
[21:33] <rocketboy> there is double buffering on the USART chip - but you have to write the ISR to do more buffering if you need it.
[21:34] <LaurenceB> what is double buffering?
[21:34] <rocketboy> its a 2 deep FIFO buffer
[21:34] <LaurenceB> 2byte?
[21:34] <rocketboy> yep
[21:35] <LaurenceB> Okay I'm using 200 byte FIFO buffer !
[21:35] <rocketboy> is that implemented by the processor or the USART>
[21:35] <rocketboy> ?
[21:35] <LaurenceB> or maybe it's not the same thing..
[21:36] <LaurenceB> the input isr is trigered from a 1 byte hardware buffer, then stacks the bytes into a 200 byte SW buffer
[21:36] <rocketboy> could be a USART buffer
[21:37] <rocketboy> ah Ok thats the way i was planning on doing it on the PIC - I have had that working using assember - now I have to move it to C
[21:38] <LaurenceB> I've been testing the rig on my bike, and with the PI algorithm it works quite well
[21:38] <LaurenceB> PI- proportional integral
[21:38] <LaurenceB> servo position = a*integral + b*error
[21:39] <LaurenceB> a is very small compared with b
[21:40] <LaurenceB> I need a way to get the heading several times a second tho
[21:41] <rocketboy> could you extrapolate it from the last 2 readings
[21:42] <rocketboy> or do you need a faster GPS?
[21:42] <LaurenceB> I've been looking for faster GPS units, but I cant seem to find one, at least not cheaply
[21:43] <LaurenceB> They all have update 1hz or slower
[21:44] <LaurenceB> I was thinking of a compass module, then you don't need to compensate for wind
[21:45] <LaurenceB> however, the heading is off if it's not horizontal
[21:45] <rocketboy> perhaps a rate gyro - corrected by GPS
[21:46] <LaurenceB> That is the best solution, you can also calibrate th rate gyro
[21:46] <LaurenceB> from the gps
[21:46] <LaurenceB> and add a time ofset between when heading is measured and when it gets to the micro
[21:46] <rocketboy> yes the drift is slow enough to correct over several seconds
[21:47] <LaurenceB> about 300ms time lag I calculate with my module at 4800 baud
[21:48] <LaurenceB> However, with any gps based heading calculations you need to subtract the wind
[21:48] <LaurenceB> from the absolute velocity vector
[21:48] <rocketboy> well the reading will be difference between the current position and the previous position - so assume its 800 (500 + 300ms) out of date
[21:50] <LaurenceB> ? i have a main loop running continuously, so once a gps sentence is input into buffer it will be parsed immediately
[21:51] <LaurenceB> oh I guess your saying the gps uses data collected half way through the prev second
[21:51] <rocketboy> ( I suspect any heading vector on GPS will be calclaued as the difference between 2 readings)
[21:51] <LaurenceB> probably correct
[21:51] <rocketboy> its possible its calculated by doplar (but I suspect not)
[21:52] <LaurenceB> I think it uses dopple shift tho, I remember seeing a diagram of this
[21:52] <LaurenceB> as the gps knows the positions of the different sats
[21:52] <LaurenceB> from doppler shifts it can find the velocity
[21:53] <rocketboy> possible - I know the wind profiler RadioSonds use GPS doppler
[21:53] <LaurenceB> The position bounces all over the place so velocity wuld be way off if found from difference
[21:54] <LaurenceB> Do you think wind is constant enough for us to assume its the same on th way down as on the way up?
[21:55] <rocketboy> in which case direction/speed is probably up to date (less usart and processing time)
[21:55] <rocketboy> I think that depends how close the landing site is to the launch site - and elapsed time
[21:55] <LaurenceB> Or do you think a compass would be better (not horizontal problem)
[21:56] <rocketboy> I think a 3 axis compas or horizon sensor is essentual to know which way is up
[21:57] <rocketboy> you cant tell that from GPS - and a gryo will drift
[21:57] <LaurenceB> with a 3 axis compass your not much better off, you can calc the third axis off a two axis sensor I think
[21:57] <defy> hey rocketboy you were using thermopile sensors yeah?
[21:58] <LaurenceB> You know the glider will glider by itself into an upright pos
[21:58] <LaurenceB> -glide
[21:59] <defy> not sure if you guys saw this but I threw a wireless cam on my glider a few days ago and flew off the coast of nz...nothing too specacular, it's pretty shakey...I'll get some better video next time (hopefully today, the weather is perfect for it) http://stonedlogic.com/glider/
[21:59] <LaurenceB> I've read some people saying that thermopiles are easily confused by clouds and the sun
[22:00] <defy> well that was my next question, how well they work in a real world environment
[22:00] <LaurenceB> defy: do you have any experience of this?
[22:00] <LaurenceB> I found a paper by some guys at MIT
[22:01] <LaurenceB> they said they were only reliable under centain conditions- low alt, no direct sun
[22:01] <defy> I have 2 thermopiles but I'm yet to test them on a glider..I'm currently working on getting the gps/gyro/thermopiles/wireless modules all hooked into my glider so I can get some sensor readings back while I fly it...nothing autonomous yet
[22:01] <defy> yeah, I've read the same
[22:01] <defy> I want to combine thermopiles and a rotation rate gyro and see how well it works
[22:01] <defy> hopefully I'll have some results in the next week or so
[22:01] <LaurenceB> I'm planning on a simple glider with just rudder control
[22:02] <defy> yeah, thats how the gpsboomerang guy does it..it says its more of a controlled freefall than a glider
[22:02] <defy> even though it is a glider
[22:02] <defy> it=he
[22:03] <LaurenceB> I was wondering wether to use a compass or rate gyros, gps and wind vector ino gathered on the way up
[22:03] <LaurenceB> the former is mch simpler
[22:04] <rocketboy> its doen't so much fly as plummet (for monty python fans)
[22:04] <defy> hehe
[22:04] <LaurenceB> and it doesn't matter if the wind changes, but compass modules give different results when off horizontal
[22:05] <rocketboy> I think that is what you need 3 axis
[22:05] <LaurenceB> Has anyone emailed the gpsboomrang guy?
[22:05] <rocketboy> the magnetic field is a 3 axis vector
[22:05] <defy> I've spoken to him before, yeah
[22:05] <LaurenceB> and asked him how he does it?
[22:06] <defy> it's gps only
[22:06] <LaurenceB> COOL
[22:06] <LaurenceB> I'm guessing it updated at more than 1Hz
[22:06] <defy> yeah, the glider does the rest, he just uses the gps to get the glider pointing in the right direction, which a little bit of very simple math
[22:07] <defy> not too sure, although I think 1hz would be fine
[22:07] <LaurenceB> I'm got a GPS only based rudder control on my bike for testing
[22:07] <LaurenceB> It worked very well
[22:07] <defy> his rudder is very tiny on the plane, so I think the changes that the plane makes are quite slow and steady
[22:08] <defy> hehe cool
[22:08] <LaurenceB> Yes that was my idea
[22:08] <defy> I did my direction control via boat first
[22:08] <defy> and am only just now moving over to getting it all up in the air
[22:08] <LaurenceB> I can input a target and then cycle along and obey the rudder
[22:09] <defy> just keep adjusting the rudder untill the desired heading is achieved?
[22:09] <LaurenceB> Problem with gps is you need to compensate for wind
[22:10] <LaurenceB> I use a PI loop to deal with trim errors
[22:10] <defy> he sells his glider for about $75 nzd
[22:11] <defy> its just an EPP foam cutout...probably not too hard to replicate
[22:11] <defy> although that kind of takes the fun out of it, hehe
[22:12] <LaurenceB> cool but the electronics is the main thing
[22:12] <defy> yea
[22:13] <LaurenceB> defy: how are you controlling the rudder
[22:14] <defy> I still haven't designed on an airframe, I like the simplicity of rudder only but part of me really wants to make horizontal stability
[22:14] <LaurenceB> With horizontal stability can you change the airspeed?
[22:15] <defy> so I'm not going to decide untill I get some data back from the glider/sensors...I'm using xbee wireless modules which let me hookup serial and ADC devices directly, so I dont need an onboard computer just yet
[22:15] <LaurenceB> or are you limited to the airspeed where lift = weight ?
[22:15] <LaurenceB> nice !
[22:15] <LaurenceB> I've got to go now :(
[22:15] <defy> probably limited
[22:16] <LaurenceB> So I'll see you all
[22:16] <defy> cya :)
[22:16] LaurenceB (n=laurence@host86-137-224-84.range86-137.btcentralplus.com) left irc:
[22:16] <rocketboy> CU
[22:16] rocketboy (n=steve@217.47.75.133) left irc: "Leaving"
[23:04] Ebola (n=Ebola@host81-152-204-231.range81-152.btcentralplus.com) left irc: Remote closed the connection
[00:00] --- Wed Dec 13 2006