[00:00] <Laurenceb> actually there is a delay of one pwm period introduced by a static variable in the ISR (IIRC)
[00:00] <RocketBoy> It definitly looks like some form of timing problem - with quire a few test runs the data that is being sent prior to it syncing up looks the same each time - so truetty is decoding the wrong bit pattern
[00:00] <Laurenceb> so that the pwm can be set right at the start of the isr
[00:01] <Laurenceb> yes, the effect I noticed, but with fldigi its avoidable
[00:01] <RocketBoy> this looks like a serial timing problem to me - rather than anything to do with pulse shaping.
[00:01] <Laurenceb> IMO a scope view of the tune up to data transition is needed
[00:02] <Laurenceb> are you sure that truetty can handle this level of shaping?
[00:04] <Laurenceb> I'll look at the code and think about what happens with the transition, it could be that the processor just cant handle it, and misses an interrupt
[00:04] <Laurenceb> pity you dont have a programmer there, it might be worth trying a clockdiv
[00:05] <Laurenceb> halving the pwm speed shouldnt harm things
[00:07] <Laurenceb> on second thoughts, there may be ways to optimise the push/pop operations with each ISR call... need to look at the documentation
[00:07] <RocketBoy> so presumably the tune up signal goes mark (start) space (stop) and then streight into the data 1st start bit?
[00:07] <Laurenceb> yes
[00:07] <RocketBoy> should be fine then
[00:07] <Laurenceb> hmm
[00:08] <Laurenceb> with debugging enabled it goes mad as theres not enough clock cycles
[00:08] <Laurenceb> perhaps there is a minor problem at some points, and it misses a few interrupts
[00:09] <Laurenceb> actually, that wasnt the problem, the main code couldnt keep up with the isr it appeared
[00:11] <Laurenceb> I guess without a storage scope its virtually impossible to look at the end of the tune up :(
[00:11] <RocketBoy> hay/ho - I'll think about it
[00:11] <Laurenceb> yes, let me know if you spot anything in the code
[00:11] <Laurenceb> thanx for the help :D
[00:12] <Laurenceb> I'll look over it, but a clockdiv on the pwm would be a very wise thing to try
[00:12] <RocketBoy> I'm off to grab some sleep
[00:12] <Laurenceb> cya
[00:14] RocketBoy (n=grunge@ left #highaltitude.
[00:25] Laurenceb (n=laurence@dhcp38-010.sthughs.ox.ac.uk) left irc: Remote closed the connection
[00:32] Laurenceb (n=laurence@dhcp38-010.sthughs.ox.ac.uk) joined #highaltitude.
[00:33] <Laurenceb> yeh RocketBoys simcode is working
[00:33] <Laurenceb> I have a nmea file
[00:52] yansa (n=yans@host-89-167-37-237.pronet.lublin.pl) left irc: "Ex-Chat"
[03:47] akawaka (n=akawaka@external.treyarch.com) left irc: Read error: 110 (Connection timed out)
[04:13] Laurenceb (n=laurence@dhcp38-010.sthughs.ox.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[04:18] icez (n=icez@ip68-98-34-247.ph.ph.cox.net) joined #highaltitude.
[04:30] akawaka (n=akawaka@cpe-76-173-152-142.socal.res.rr.com) joined #highaltitude.
[06:58] icez (n=icez@ip68-98-34-247.ph.ph.cox.net) left irc: "Lost terminal"
[07:53] MetaMorfoziS (n=khmhm@4d6f5419.adsl.enternet.hu) joined #highaltitude.
[07:57] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[09:10] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[09:34] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[10:23] mc- (n=mfcastle@cpc4-glfd1-0-0-cust538.glfd.cable.ntl.com) joined #highaltitude.
[10:23] mc- (n=mfcastle@cpc4-glfd1-0-0-cust538.glfd.cable.ntl.com) left irc: Client Quit
[10:31] borism (n=boris@84-50-200-175-dsl.est.estpak.ee) left irc: Client Quit
[10:33] akawaka (n=akawaka@cpe-76-173-152-142.socal.res.rr.com) left irc: Read error: 110 (Connection timed out)
[10:33] flowolf (n=flowolf@host254-234-dynamic.3-79-r.retail.telecomitalia.it) joined #highaltitude.
[10:45] borism (n=boris@84-50-200-175-dsl.est.estpak.ee) joined #highaltitude.
[11:35] flowolf (n=flowolf@host254-234-dynamic.3-79-r.retail.telecomitalia.it) left irc: "Leaving"
[11:57] flowolf (n=flowolf@host254-234-dynamic.3-79-r.retail.telecomitalia.it) joined #highaltitude.
[12:03] borism_ (n=boris@195-50-206-126-dsl.krw.estpak.ee) joined #highaltitude.
[12:09] borism (n=boris@84-50-200-175-dsl.est.estpak.ee) left irc: Read error: 145 (Connection timed out)
[12:36] flowolf_ (n=flowolf@host3-234-dynamic.3-79-r.retail.telecomitalia.it) joined #highaltitude.
[12:36] flowolf (n=flowolf@host254-234-dynamic.3-79-r.retail.telecomitalia.it) left irc: Read error: 145 (Connection timed out)
[12:47] Laurenceb (n=laurence@fwnat-pub-1.physics.ox.ac.uk) joined #highaltitude.
[12:50] Laurenceb (n=laurence@fwnat-pub-1.physics.ox.ac.uk) left #highaltitude ("Leaving").
[13:31] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[13:57] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) left irc:
[14:24] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: "pwned!"
[15:23] flowolf_ (n=flowolf@host3-234-dynamic.3-79-r.retail.telecomitalia.it) left irc: "Leaving"
[15:28] Laurenceb (n=laurence@fwnat-pub-1.physics.ox.ac.uk) joined #highaltitude.
[15:44] Laurenceb (n=laurence@fwnat-pub-1.physics.ox.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[16:17] flowolf (n=flowolf@host3-234-dynamic.3-79-r.retail.telecomitalia.it) joined #highaltitude.
[16:26] flowolf (n=flowolf@host3-234-dynamic.3-79-r.retail.telecomitalia.it) left irc: "Leaving"
[16:44] akawaka (n=akawaka@cpe-76-173-152-142.socal.res.rr.com) joined #highaltitude.
[17:11] jcoxon (n=jcoxon@host86-129-61-253.range86-129.btcentralplus.com) joined #highaltitude.
[17:14] yansa (n=yans@host-89-167-37-237.pronet.lublin.pl) joined #highaltitude.
[17:32] <jcoxon> hey all
[17:54] akawaka (n=akawaka@cpe-76-173-152-142.socal.res.rr.com) left irc: Read error: 110 (Connection timed out)
[18:10] natrium42 (n=alexei@libnaa39.uwaterloo.ca) joined #highaltitude.
[18:12] flowolf (n=flowolf@ joined #highaltitude.
[18:25] Laurenceb (n=laurence@dhcp39-033.sthughs.ox.ac.uk) joined #highaltitude.
[18:25] <Laurenceb> hi all
[18:25] <natrium42> hey lb
[18:25] <natrium42> so
[18:25] <Laurenceb> good news, I've got the gps and phone working
[18:25] <natrium42> still on schedule?
[18:25] <natrium42> :)
[18:25] <Laurenceb> hopefully....
[18:26] <natrium42> what happens if there's a failure?
[18:26] <Laurenceb> the gps had to have the onboard back up cell shorted for a bit
[18:26] <natrium42> you don't graduate? :/
[18:26] <Laurenceb> lol
[18:26] <Laurenceb> as long as I submit a report
[18:26] <Laurenceb> by the second week of trinity
[18:27] <natrium42> have you seen this tracker device btw?
[18:27] <Laurenceb> what device?
[18:27] <natrium42> the one that's meant to track people in emergencies
[18:27] <natrium42> forgot the name...
[18:27] <natrium42> might be useful for a backup
[18:27] <natrium42> one sec
[18:27] <natrium42> maybe i will find it again
[18:27] <Laurenceb> ah yes
[18:27] <Laurenceb> I've seen those
[18:28] <Laurenceb> a bit expensive, and you can make one quite easily
[18:28] <natrium42> oh right
[18:28] <natrium42> spot
[18:28] <natrium42> http://www.dirtnewz.com/products/racerxspot-2-12-08.shtml
[18:28] <natrium42> doesn't seem to have altitude it seems
[18:28] Action: natrium42 looks angrily at the developers
[18:29] <Laurenceb> hehe
[18:29] <Laurenceb> this rfsolutions gps seems quite good, gets a lock fast
[18:29] <Laurenceb> once I powered it up outside, it took <30 seconds
[18:29] <natrium42> cool
[18:30] <natrium42> are you going to have any watchdogs?
[18:30] <Laurenceb> no, but the code will restart
[18:30] <Laurenceb> I hope (dont know hoew to do that yet)
[18:30] <Laurenceb> respawn... ?
[18:31] <natrium42> there should be one built into the arm processor you're using
[18:31] <Laurenceb> avr
[18:31] akawaka (n=akawaka@external.treyarch.com) joined #highaltitude.
[18:31] <natrium42> isn't it arm?
[18:31] <Laurenceb> no, avr32
[18:31] <natrium42> aah
[18:31] <natrium42> ok
[18:31] <natrium42> there are some watchdog facilities in linux
[18:31] <natrium42> but i never tried to use them
[18:32] <Laurenceb> I think I'd be happy with some sort of respawn
[18:32] <Laurenceb> is that what its called?
[18:33] <natrium42> well, some process just sends a heartbeat to the hardware watchdog built into the arm32
[18:33] <Laurenceb> there was something like that setup for a terminal on /dev/ttyS0 but i commented it out so it could be used for the phone
[18:33] <natrium42> and if the heartbeat stops, arm32 si rebooted by the hardware
[18:33] <Laurenceb> interesting
[18:34] <Laurenceb> I think there might still be a few bugs in the sms code, it stopped working one time, and some of my messages have "@" on the end
[18:34] <Laurenceb> probably a badly terminated loop
[18:34] <Laurenceb> as "@"=0x00
[18:35] <natrium42> is it sending them at an interval?
[18:35] <natrium42> or do you have to request the position via sms?
[18:36] <Laurenceb> at an interval
[18:36] <Laurenceb> the code is on the wiki
[18:36] <natrium42> are you using timeouts?
[18:36] <Laurenceb> yes
[18:36] <natrium42> good
[18:37] <Laurenceb> http://wiki.ukhas.org.uk/projects:aerosol_code
[18:37] <natrium42> maybe if it keeps timing out for a while, you could reset the communication line somehow
[18:38] <Laurenceb> RocketBoy's been testing the radio, I think we know what the problem is...
[18:38] <natrium42> perhaps by closing serial port and opening it again
[18:38] <Laurenceb> but the cause is another matter...
[18:38] <Laurenceb> some characters coming over the radio have pauses in them
[18:39] <Laurenceb> I think its this problem: http://wiki.ukhas.org.uk/_media/projects:dscn0961.jpg?cache=cache
[18:39] <akawaka> what kind of phone are you using?
[18:39] <Laurenceb> but I still cant come up with an explanation of what causes that...
[18:39] <Laurenceb> ericsson t610
[18:41] <Laurenceb> its not caused by missing interrupts
[18:42] <Laurenceb> I though it was due to printf blocking the main code... but it still seems to be happening
[18:42] <Laurenceb> it cant be missing interrupts, as the ramp up takes the correct amount of time
[18:43] <Laurenceb> apparently it happens for the first few bytes in most transmissions
[18:44] <Laurenceb> anyone got any ideas?
[18:45] <Laurenceb> ( the pulse shaping is done by an interrupt)
[18:45] <Laurenceb> thats called on timer1 overflow, the main code bit bangs the data into a global variable used by the interrupt
[18:46] jcoxon (n=jcoxon@host86-129-61-253.range86-129.btcentralplus.com) left irc: "Leaving"
[18:54] <akawaka> not sure what i'm looking at, what is that signal supposed to look like?
[18:55] <Laurenceb> http://wiki.ukhas.org.uk/_detail/projects:radio_project.jpg?id=projects%3Aaerosol&cache=cache
[18:55] <Laurenceb> thats a different timebase
[18:58] <Laurenceb> the shaped transitions seem to take the correct amount of time, but there are pauses inbetween
[19:00] <Laurenceb> if I was missing interrupts, then the transitions would take too long
[19:01] <Laurenceb> so it must be that the main code doesnt have enough time to run... strange
[19:03] <Laurenceb> its only shuffing bits about... guess I'd better check it again
[19:13] Action: Laurenceb ---> food
[19:21] natrium42 (n=alexei@libnaa39.uwaterloo.ca) left irc: "pwned!"
[19:30] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[19:58] RocketBoy (n=grunge@ joined #highaltitude.
[19:58] <Laurenceb> hey there RocketBoy
[19:58] <Laurenceb> thanx for the photos
[19:58] <RocketBoy> np
[19:58] <Laurenceb> interesting
[19:58] <Laurenceb> I think I can see what the problem is
[19:58] <Laurenceb> but the cause is a slight mystery
[19:59] <Laurenceb> http://wiki.ukhas.org.uk/_detail/projects:dscn0961.jpg?id=projects%3Aaerosol&cache=cache
[19:59] <RocketBoy> do you agree with my thoughts in the email
[19:59] <Laurenceb> I think thats whats happening
[19:59] <Laurenceb> yes, certainly
[20:00] <Laurenceb> but I cant see how missed interrupts would cause the same issue
[20:00] <Laurenceb> it looks like for some reason the output is hovering fully on or off for too long
[20:01] <Laurenceb> not that its going too slow due to missed/clashing interrupts
[20:02] <RocketBoy> ok
[20:02] <Laurenceb> I'm wondering if some variable is overflowing, or some error like that, ie a code error, not specifically a timing problem with interrupts
[20:02] <RocketBoy> yep i follow
[20:03] <Laurenceb> as it looks like its hovering at pwm=100% or 0%, not taking too long to transition
[20:03] <Laurenceb> or at least not just taking too long
[20:03] <Laurenceb> also theres the fact that it doesnt seem to matter how much data you send it
[20:04] <Laurenceb> the beginning is always corrupted
[20:04] <Laurenceb> odd that fldigi could decode it ok
[20:05] <akawaka> are you only handling a single interrupt type (timer) and disabling everything else?
[20:05] <RocketBoy> perhaps it isn't as picky - it works ok sometimes
[20:05] <Laurenceb> akawaka: theres timer1 and uart recieve
[20:06] <Laurenceb> I hope, one thing I need to check is that other interrupts arent going off in error
[20:06] <Laurenceb> but it sleeps ok between tune up pulses, and its set to wake on interrupt then
[20:07] <akawaka> and you are taking into account the amount of time it takes the proc jump to the interupt vector, etc?
[20:07] <RocketBoy> I have noticed that sometimes it doesn't send the data immediatly after its sent in
[20:08] <edmoore> arm7tdmi takes 21 cycles, for example. more of a polite tap on the shoulder than an interrupt
[20:08] <RocketBoy> perhaps a 3 or 4 second delay
[20:09] <Laurenceb> RocketBoy: before tune up pulse?
[20:10] <RocketBoy> no - I wait for the tune up and then send it after - or perhaps at the tail end of it being sent
[20:10] <RocketBoy> (the tail end of the tune up that is)
[20:11] <Laurenceb> ok, so a delay between you sending it in and what happening?
[20:11] <RocketBoy> and the tune up prior to data transmission
[20:11] <Laurenceb> ?!?
[20:11] <Laurenceb> you sure?
[20:12] flowolf (n=flowolf@ left irc: Read error: 113 (No route to host)
[20:12] <Laurenceb> hmmm
[20:12] flowolf_ (n=flowolf@ joined #highaltitude.
[20:12] Action: Laurenceb looks at the code
[20:12] <RocketBoy> so I wait for the self tune up - at the end I hit paste into hyperterm then there is a delay (3-4sec) and then it sends the data tune up followed by data
[20:13] <RocketBoy> but only some times
[20:13] <Laurenceb> is it your pc?
[20:14] <Laurenceb> do you get all the data?
[20:14] <RocketBoy> yep it could be - I have no way of knowing at the mo - I don't think so though - its a seperate PC and its not doing anything else -
[20:15] <Laurenceb> theres no way the code could do that
[20:15] <RocketBoy> I havn't noticed any corrolation between the 2 problems
[20:15] <Laurenceb> at least as far as I can see
[20:15] <Laurenceb> the sleep is for 3.5 sec until the timer overflows
[20:16] <Laurenceb> but it will wake on uart
[20:16] <Laurenceb> and it must do, or you would be able to get any data
[20:16] <Laurenceb> oh
[20:17] Action: Laurenceb sees whats going on
[20:17] <Laurenceb> you data arrives just before it enters the sleep
[20:17] <Laurenceb> so it doesnt check, and goes to sleep anyway
[20:17] <Laurenceb> not a "problem" but a minor bug I suppose
[20:18] <Laurenceb> have you got the code there?
[20:19] <Laurenceb> http://pastebin.com/d1afdaf27
[20:20] <RocketBoy> ugg - I only have one word to say - indenting
[20:21] <Laurenceb> hmm its come out a bit odd, looks better on here
[20:23] <Laurenceb> so line 403=self tuneup
[20:23] <Laurenceb> if data arrives between then and the sleep it wont know about it
[20:24] <RocketBoy> ah - ok its not a serious problem - and if its not related to the other problem then its not worth worrying about
[20:25] <Laurenceb> yes, thats whats happening for sure
[20:26] <Laurenceb> 439 is the sleep
[20:29] <Laurenceb> I wonder if the fact that the lookup table pointer is only incremented and decremented is to blame
[20:30] <Laurenceb> it is never given a set value, I just assumed that the tune up pulse would leave it at pulse_res_minus1
[20:30] <Laurenceb> line 109
[20:34] <RocketBoy> BBL
[20:47] <Laurenceb> hmm I cant see it :(
[20:48] <Laurenceb> send looks good to me, as does overflow
[21:06] <Laurenceb> RocketBoy: think I might have a clue, PWM uses match not compare
[21:06] <Laurenceb> that might be the problem
[21:06] <Laurenceb> the pwm shoulnt go below about 40
[21:07] <Laurenceb> as it takes 40 cycles or so to get to the pwm setting point
[21:16] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[21:16] Laurenceb (n=laurence@dhcp39-033.sthughs.ox.ac.uk) left irc: Read error: 104 (Connection reset by peer)
[21:20] Laurenceb (n=laurence@dhcp39-033.sthughs.ox.ac.uk) joined #highaltitude.
[21:20] <Laurenceb> $££$$% machine
[21:20] <Laurenceb> ubuntu just rebooted for no reason, deleting all my work
[21:29] RocketBoy (n=grunge@ left irc: Read error: 110 (Connection timed out)
[21:33] <Laurenceb> http://imagebin.org/14551
[21:46] jcoxon (n=jcoxon@host86-129-61-253.range86-129.btcentralplus.com) joined #highaltitude.
[21:46] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[21:49] <jcoxon> ooooo high altitude balloons on makezine blog
[21:49] <jcoxon> http://homepage.mac.com/jsbusque/PhotoAlbum5.html
[22:05] yansa_ (n=yans@host-89-230-211-114.lublin.mm.pl) joined #highaltitude.
[22:20] yansa (n=yans@host-89-167-37-237.pronet.lublin.pl) left irc: Read error: 113 (No route to host)
[22:27] Laurenceb (n=laurence@dhcp39-033.sthughs.ox.ac.uk) left irc: Remote closed the connection
[22:48] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[23:04] Laurenceb (n=laurence@dhcp39-033.sthughs.ox.ac.uk) joined #highaltitude.
[23:08] <akawaka> its funny
[23:09] <akawaka> when me and my friends started planning to do this it seemed novel and new
[23:09] <jcoxon> akawaka, hehe
[23:09] <akawaka> the more you look into it its like everyone and their mom has been doing it for 40 years
[23:09] <jcoxon> its still not easy!
[23:09] <akawaka> i know
[23:09] <akawaka> and its still fun
[23:10] <akawaka> hopefully we can get airborne before the end of the month
[23:10] <jcoxon> excellent
[23:10] <akawaka> jcoxon: how heavy are your payloads?
[23:10] <Laurenceb> its certainly taking off
[23:10] <Laurenceb> excuse the pun
[23:10] <akawaka> groan
[23:10] <jcoxon> akawaka, mine are quite light
[23:10] <jcoxon> FHALP-2 itself was 340g
[23:10] <jcoxon> but that wasn't without the camera
[23:11] <Laurenceb> Mihab1 was 320
[23:11] <akawaka> wow, that is really light
[23:11] <jcoxon> but we've launched up to 2kg
[23:11] <akawaka> we're going for 1.5kg
[23:11] <jcoxon> and i've launched in africa payloads of 100kg :-p
[23:11] <Laurenceb> the AOPP project is close to that
[23:11] <akawaka> i'd like to keep it below 1kg myself
[23:11] <Laurenceb> (2kg not 100 :P )
[23:12] <akawaka> but we're going with a lot of off the shelf parts
[23:12] <jcoxon> yeah
[23:12] <jcoxon> most payloads are 1kg
[23:13] <akawaka> the packet radio is kind of exciting
[23:13] <akawaka> we're hoping to get at least a few low res pictures transmitted during the flight
[23:13] <jcoxon> excellent
[23:13] <jcoxon> natrium42, managed to get some pictures on his flight
[23:14] <jcoxon> just make sure you have the basics working! so you can find it!
[23:15] <akawaka> piff, details details!
[23:15] <jcoxon> haha
[23:16] <Laurenceb> akawaka: what packet radio?
[23:18] <akawaka> just an off the shelve handheld 2m transceiver
[23:18] <Laurenceb> :( I want one
[23:18] <Laurenceb> where are you?
[23:18] <akawaka> california
[23:18] <Laurenceb> ah
[23:18] <akawaka> don't have the restrictions you guys have
[23:18] <Laurenceb> hehe
[23:19] <Laurenceb> 434MHz is still exciting
[23:19] <Laurenceb> but my code needs a bit more work, I'm still no closer to the problem it seems
[23:19] <Laurenceb> I'm going to use line in and audacity to capture a whole packet I think
[23:22] <akawaka> don't really know how powerful our radios need to be though
[23:22] <akawaka> don't know enough about them
[23:22] <jcoxon> akawaka, we scrap through with 10mW
[23:22] <jcoxon> :-p
[23:22] <jcoxon> so something like 500mW would be nice
[23:22] <akawaka> hopefully some of the hams that are will be able to help us with that
[23:22] <jcoxon> yeah
[23:22] <Laurenceb> 10mW can work really well if properly designed
[23:24] <akawaka> wow
[23:24] <akawaka> yeah, we have no idea
[23:24] <akawaka> we were thinking 5W!
[23:24] <jcoxon> go for it!
[23:25] <akawaka> hah, maybe you guys will be able to hear it:)
[23:26] <jcoxon> hehe
[23:26] <jcoxon> sadly my radio only does the 70cm badn
[23:26] <jcoxon> band*
[23:26] <jcoxon> but i'm sure someone will be listening
[23:26] <Laurenceb> akawaka: theoretically you can get 10000Km at 300bps with 10mw
[23:27] <jcoxon> right i'm off
[23:27] <jcoxon> night all
[23:27] <Laurenceb> cya
[23:27] jcoxon (n=jcoxon@host86-129-61-253.range86-129.btcentralplus.com) left irc: "Leaving"
[23:27] <akawaka> Laurenceb: would depend on the receiver sensitivity though, right?
[23:27] <Laurenceb> realistically, a few 1000Km with a huge yagi, GaAs preamp and reed solomon coding
[23:28] <natrium42> yagi seems the way to go
[23:28] Action: natrium42 wants a huge yagi
[23:28] <Laurenceb> I tried to order some GaAs preamps from AD, but no reply :(
[23:29] <Laurenceb> Farnell have some, but not as good as AD's latest ones
[23:29] <Laurenceb> interestingly, completely homebrew designs can get better performance
[23:30] Action: Laurenceb wants a hardcore LN2 cooled reciever
[23:30] <natrium42> use Jodrell Bank
[23:31] <akawaka> given the frequency, the distance and the wattage how would I go about calculating the theoretical signal strength at the receiver?
[23:31] <Laurenceb> I saw someone used a homebre LN2 cooled GaAs preamp and small yagi to watch US tv bouncing off the moon in Australia
[23:32] <Laurenceb> akawaka: theres a spreadsheet on the wiki
[23:32] <Laurenceb> or wikipedia
[23:34] fnoble (n=fnoble@fn217.quns.cam.ac.uk) joined #highaltitude.
[23:34] <Laurenceb> hey fnoble
[23:34] <Laurenceb> how goes the rocket design?
[23:34] <fnoble> hello
[23:34] <fnoble> not done so much, been writing software for the new flight computer
[23:35] <Laurenceb> how good are you with AVRs ?
[23:35] <fnoble> does anyone know about arms?
[23:35] <fnoble> never tried, sorry
[23:35] <Laurenceb> I hope to learn soon :P
[23:35] <Laurenceb> not enough time :(
[23:36] <Laurenceb> you'r working on ARM with no AVR experience ? Or have you used PIC?
[23:37] <Laurenceb> I havent yet found a good place to look for ARM code examples, one reason I haven't used them
[23:37] <fnoble> have used pics and some zilogs
[23:37] <Laurenceb> ok cool
[23:38] <Laurenceb> I was going to say that was jumping in at the deep end :P
[23:38] <fnoble> my main problems are with gcc though at the moment
[23:38] <Laurenceb> yes, it seems to go that way when starting with something new
[23:38] <fnoble> all the gcc standard libs are compiled with hardware floating point, so they wont link
[23:39] <fnoble> as the arm requires soft FP
[23:39] <Laurenceb> hmm isnt there arm-gcc, like avr-gcc ?
[23:40] <akawaka> yeah
[23:40] <Laurenceb> arent there packages out there to help you?
[23:40] <fnoble> im using arm-gcc
[23:40] <Laurenceb> cool
[23:41] <fnoble> i think some arms have hard FP though, dunno really
[23:41] <fnoble> info is scant on the interwebs
[23:41] <Laurenceb> I know, thats put me off ARM
[23:41] <Laurenceb> theres always AVR32, but its BGA, not good for a rocket
[23:42] <akawaka> which std libs?
[23:43] <fnoble> libc
[23:44] <akawaka> and you are passing -msoft-float to the compiler?
[23:44] <akawaka> are you calling ld manually, or using gcc to call it?
[23:46] <Laurenceb> hmm not bad - http://maps.google.co.uk/maps?f=q&hl=en&geocode=&q=51.759213N,1.255698W&ie=UTF8&ll=51.759081,-1.256033&spn=0.000724,0.002511&t=h&z=19&iwloc=addr
[23:46] <fnoble> using ld manually, and passing -msoft-float
[23:46] <Laurenceb> its about 10 feet from my lab :P
[23:46] <akawaka> fnoble: whats the errors its giving you?
[23:47] <fnoble> many like this:
[23:48] <fnoble> ok, was too big, will put in pastebin, 1 sec
[23:49] <fnoble> http://pastebin.com/m1767e564
[23:50] <Laurenceb> looks like you need a different lib
[23:50] <Laurenceb> is there #arm on here maybe?
[23:51] <Laurenceb> bah no there isnt :(
[23:53] <akawaka> can you paste the output of arm-gcc -v ?
[23:54] <fnoble> fergus-nobles-computer:~/nova stuff/svn/fc1 software fergusnoble$ arm-elf-gcc -v
[23:54] <fnoble> Using built-in specs.
[23:54] <fnoble> Target: arm-elf
[23:54] <fnoble> Configured with: ./configure --target=arm-elf --prefix=/usr/local/arm --enable-interwork --enable-multilib --enable-languages=c,c++ --with-newlib --with-headers=../../src/newlib-1.14.0/newlib/libc/include
[23:54] <fnoble> Thread model: single
[23:54] <fnoble> gcc version 4.1.0
[23:57] <fnoble> its strange really, as none of this should really need floating point
[00:00] --- Wed Mar 5 2008