highaltitude.log.20100511

[00:14] natrium42 (~natrium@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[00:20] G8DSU (~chatzilla@cpc3-mort4-0-0-cust192.croy.cable.virginmedia.com) left irc: Quit: ChatZilla 0.9.86 [Firefox 3.5.9/20100315083431]
[00:44] rharrison (~rharrison@gateway.hgf.com) left irc: Ping timeout: 240 seconds
[00:44] rharrison_ (~rharrison@80.4.177.225) left irc: Ping timeout: 268 seconds
[00:52] juxta (fourtytwo@203.122.193.94) joined #highaltitude.
[01:00] juxta (fourtytwo@203.122.193.94) left irc: Read error: Connection reset by peer
[01:06] juxta (fourtytwo@203.122.193.94) joined #highaltitude.
[01:10] Randomskk_ (~adam@li184-103.members.linode.com) joined #highaltitude.
[01:10] Randomskk_ (~adam@li184-103.members.linode.com) left irc: Client Quit
[02:08] darknesslord_ (~darknessl@189.182.46.134) joined #highaltitude.
[02:18] darknesslord_ (~darknessl@189.182.46.134) left irc: Quit: can i haz interlolz?
[02:20] SpeedEvil (~user@tor/regular/SpeedEvil) left irc: Quit: Leaving.
[02:21] SpeedEvil (1000@tor/regular/SpeedEvil) joined #highaltitude.
[02:26] hapt1K (dongs@188-221-43-87.zone12.bethere.co.uk) left #highaltitude ("Leaving").
[02:37] juxta_ (~blah@120.156.49.190) joined #highaltitude.
[02:41] jasonb (~jasonb@dsl027-180-244.sfo1.dsl.speakeasy.net) left irc: Ping timeout: 246 seconds
[03:05] juxta_ (~blah@120.156.49.190) left irc: Ping timeout: 246 seconds
[03:48] Jasperw (~jasperw@93.89.81.29) left irc: Quit: Leaving.
[04:00] borism (~boris@ec2-184-73-184-235.compute-1.amazonaws.com) left irc: Remote host closed the connection
[04:04] zeusbot (zeusbot@77.92.67.64) left irc: Ping timeout: 265 seconds
[04:06] zeusbot joined #highaltitude.
[04:13] zeusbot (zeusbot@77.92.67.64) left irc: Ping timeout: 276 seconds
[04:27] zeusbot joined #highaltitude.
[05:22] juxta_ (~blah@120.156.174.51) joined #highaltitude.
[05:24] jasonb (~jasonb@m380536d0.tmodns.net) joined #highaltitude.
[05:29] MoALTz (~no@92.0.127.167) left irc: Quit: Leaving
[05:35] juxta- (~blah@120.156.174.51) joined #highaltitude.
[05:36] juxta_ (~blah@120.156.174.51) left irc: Ping timeout: 260 seconds
[05:40] natrium42 (~natrium@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: Remote host closed the connection
[05:44] juxta- (~blah@120.156.174.51) left irc: Ping timeout: 240 seconds
[05:56] jasonb (~jasonb@m380536d0.tmodns.net) left irc: Ping timeout: 258 seconds
[06:37] Upu (~Upu@ubn.upuaut.net) joined #highaltitude.
[06:37] ms7821 (~Mark@flat.ms) left irc: Disconnected by services
[06:37] ms7821 (~Mark@flat.ms) joined #highaltitude.
[07:11] Simon-MPFH (~simon@phantom.mpfh.co.uk) joined #highaltitude.
[07:27] jasonb (~jasonb@adsl-66-124-73-250.dsl.sntc01.pacbell.net) joined #highaltitude.
[08:46] GW8RAK (~chatzilla@host86-153-50-29.range86-153.btcentralplus.com) joined #highaltitude.
[09:04] simon_ (~simon@phantom.mpfh.co.uk) joined #highaltitude.
[09:04] Nick change: simon_ -> Guest15922
[09:18] rharrison_ (~rharrison@gateway.hgf.com) joined #highaltitude.
[09:18] rharrison (~rharrison@gateway.hgf.com) joined #highaltitude.
[10:41] <earthshine> morning
[10:56] Branche (~smealum@82.243.132.64) joined #highaltitude.
[10:57] smealum (~smealum@82.243.132.64) left irc: Ping timeout: 252 seconds
[10:59] <rharrison_> morning earthshine
[11:18] GW8RAK_ (~chatzilla@host86-153-50-29.range86-153.btcentralplus.com) joined #highaltitude.
[11:20] GW8RAK (~chatzilla@host86-153-50-29.range86-153.btcentralplus.com) left irc: Ping timeout: 265 seconds
[11:20] Nick change: GW8RAK_ -> GW8RAK
[11:38] <rharrison_> ping jonsowman
[11:38] <rharrison_> Your XML is done
[11:44] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) joined #highaltitude.
[11:44] <Laurenceb> http://www.sensirion.com/en/04_differential_pressure_sensors/01_sdp600-differential-pressure-sensors/00_sdp600-differential-pressure-sensors.htm
[11:45] <Laurenceb> ^ wow
[11:45] <Laurenceb> so much for hot wire/film based anemometery
[11:46] <Laurenceb> 0.2Pa - thats ~0.5m/s about stationary
[11:49] <Laurenceb> http://uk.farnell.com/sensirion/sdp610/sensor-pressure-i2c-500pa/dp/1696081
[11:54] <SpeedEvil> :)
[11:56] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) left irc: Ping timeout: 240 seconds
[12:15] LazyLeopard (~irc-clien@chocky.demon.co.uk) joined #highaltitude.
[12:38] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) joined #highaltitude.
[13:12] rharrison (~rharrison@gateway.hgf.com) left irc: Quit: Leaving
[13:13] Simon-MPFH (~simon@phantom.mpfh.co.uk) left irc: Quit: Leaving
[13:13] Guest15922 (~simon@phantom.mpfh.co.uk) left irc: Read error: Connection reset by peer
[13:51] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) left irc: Ping timeout: 248 seconds
[14:07] ContraSF` (email@89-180-225-95.net.novis.pt) joined #highaltitude.
[14:09] ContraSF (~email@89-180-211-240.net.novis.pt) left irc: Ping timeout: 246 seconds
[14:15] Jasperw (~jasperw@93.89.81.29) joined #highaltitude.
[14:57] rharrison (~rharrison@gateway.hgf.com) joined #highaltitude.
[14:57] rharrison (~rharrison@gateway.hgf.com) left irc: Client Quit
[15:22] Akiraa (~Akiraaaa@79.112.44.66) left irc: Quit: Daisy, Daisy, give me your answer, do...
[15:27] Akiraa (~Akiraaaa@79.112.44.66) joined #highaltitude.
[15:40] Akiraa (~Akiraaaa@79.112.44.66) left irc: Quit: Daisy, Daisy, give me your answer, do...
[15:57] ContraSF` (email@89-180-225-95.net.novis.pt) left #highaltitude.
[16:02] Akiraa (~Akiraaaa@79.112.44.66) joined #highaltitude.
[16:03] Akiraa (~Akiraaaa@79.112.44.66) left irc: Client Quit
[16:27] jasonb (~jasonb@adsl-66-124-73-250.dsl.sntc01.pacbell.net) left irc: Ping timeout: 240 seconds
[16:41] jasonb (~jasonb@m330536d0.tmodns.net) joined #highaltitude.
[16:42] DanielRichman (~DanielRic@unaffiliated/danielrichman) joined #highaltitude.
[17:21] GW8RAK (~chatzilla@host86-153-50-29.range86-153.btcentralplus.com) left irc: Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]
[17:23] juxta (fourtytwo@203.122.193.94) left irc: Ping timeout: 258 seconds
[17:25] jasonb (~jasonb@m330536d0.tmodns.net) left irc: Ping timeout: 276 seconds
[17:28] jasonb (~jasonb@m3c0536d0.tmodns.net) joined #highaltitude.
[17:41] jasonb (~jasonb@m3c0536d0.tmodns.net) left irc: Ping timeout: 246 seconds
[18:02] jasonb (~jasonb@dsl027-180-244.sfo1.dsl.speakeasy.net) joined #highaltitude.
[18:26] Jasperw (~jasperw@93.89.81.29) left irc: Quit: Leaving.
[19:37] Jasperw (~jasperw@78-86-9-131.zone2.bethere.co.uk) joined #highaltitude.
[19:47] GW8RAK (~chatzilla@client-86-31-171-140.oxfd.adsl.virginmedia.com) joined #highaltitude.
[20:18] [STAR]Atanyi|MnG (~Upu@ubn.upuaut.net) joined #highaltitude.
[20:20] Upu (~Upu@ubn.upuaut.net) left irc: Ping timeout: 252 seconds
[20:26] natrium42 (~natrium@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) joined #highaltitude.
[20:41] Matt_sot1n (~Matt_soto@62.18.44.156) left irc: Quit: Lost terminal
[20:53] MoALTz (~no@92.19.24.104) joined #highaltitude.
[20:58] fsphil (~phil@beastie.sanslogic.co.uk) joined #highaltitude.
[21:12] SpeedEvil1 (~user@tor/regular/SpeedEvil) joined #highaltitude.
[21:14] SpeedEvil (1000@tor/regular/SpeedEvil) left irc: Ping timeout: 240 seconds
[21:15] Nick change: SpeedEvil1 -> SpeedEvil
[21:20] junderwood (~John@adsl.jcu.me.uk) joined #highaltitude.
[21:26] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) joined #highaltitude.
[21:26] <Laurenceb> hi all
[21:26] <LazyLeopard> hiya. kind-of quiet in here this afternoon...
[21:29] Action: Laurenceb is annoyed by pressure sensor parametric searches on digikey and farnell
[21:29] <Laurenceb> they havent provided the full specs on the site - so its pretty useless
[21:31] <GW8RAK> Evening. I'm working on the data packet output and am wondering if using a shorter minimum content data packet will give improved decoding.
[21:32] <GW8RAK> Additional data could then be output in a separate data packet.
[21:32] <GW8RAK> Any comments on this approach please?
[21:32] <SpeedEvil> Yes.
[21:32] <junderwood> It will give it more chance of getting through the checksum - fewer bits to be corrupted
[21:32] <SpeedEvil> But you need the packets to be _really_ short
[21:32] <SpeedEvil> I was looking at a three byte packet a while back
[21:32] <junderwood> But the packets need to be identifiable (i.e. different headers)
[21:32] <SpeedEvil> In practice, FEC is probably a more sane approach
[21:33] <GW8RAK> That was what I was thinking. Is there any experience of using short packets?
[21:33] <GW8RAK> Or rather, improved decoding?
[21:33] <junderwood> Not that I'm aware of.
[21:33] <SpeedEvil> Improved decoding - fldigi blows rather for this.
[21:33] <fsphil> I've dabbled with reed-solomon codes for large packets, sorta worked
[21:33] <SpeedEvil> For example - it throws away the whole byte if you've got any framing error
[21:34] <GW8RAK> In the UK, there seem to be enough receivers to always get a decode, but is that just luck?
[21:34] <junderwood> You need to judge the size carefully. With a small payload, the packet will be mostly header and checksum.
[21:34] <junderwood> Recently a lot of hams seem to have got interested in decoding
[21:34] <junderwood> (like you?)
[21:34] <GW8RAK> Principally, I'm wondering about time, counter, lat, long and alt. in one packet and optional data in the following packet.
[21:35] <SpeedEvil> If you 'just' fixed fldigi to output the raw bits - not bytes - a software decoder would be quite simple.
[21:35] <GW8RAK> junderwood - could be!
[21:35] <fsphil> SpeedEvil, I've made some modifications to estimate the lost bytes and pad the stream out
[21:35] <Laurenceb> fldigi rather sucks
[21:35] <Laurenceb> I was working on a decoder... but got bored
[21:35] <Laurenceb> sorry :-/
[21:35] <junderwood> the new version has an improved RTTY decoder
[21:35] <SpeedEvil> GW8RAK: I was thinking earlier of something like: Three byte packets. Four bit packet type. Eight bit data. twelve bit checksum.
[21:35] <Laurenceb> basically you want a FLL and DLL
[21:35] <Laurenceb> for locating the bit edges and carrier
[21:36] <GW8RAK> I've done a lot of datacomms in radio, but the maths and programming is beyond me.
[21:36] <junderwood> The idea is that packets are human-readable to encourage newcomers.
[21:36] <junderwood> byte-coding wouldn't be easy to read!
[21:37] <SpeedEvil> GW8RAK: You send the bytes in the sequence: LATminor LONminor ALTminor LATminor LONminor ALTminor LATmajor LATminor ...
[21:37] <fsphil> also having text is handy for when the signal is weak -- bit easier to pick apart
[21:37] <Laurenceb> gcc can compile c99
[21:37] <Laurenceb> so complex support :P
[21:37] <SpeedEvil> GW8RAK: So that the often changing bits are far more comon.
[21:37] <GW8RAK> That was another idea I was wondering about. After sending a data packet, send one stating "Lat is XXX, Long is AAA etc.
[21:37] <junderwood> In fact, with byte-coding it would be difficult to know whether you were decoding correctly!
[21:37] <Laurenceb> which is very handy for this
[21:37] <SpeedEvil> GW8RAK: But this makes it lots harder to decode and pick apart by eye.
[21:38] <SpeedEvil> On the flipside, the checksums make it quite unlikely - combined with a proablistic model - that you get stuff wrong.
[21:38] <GW8RAK> I wasn't thinking of clever coding or integrity checking, just maximising the probability of a successful decode
[21:38] <SpeedEvil> But at that point - it's probably more sane to do something like have the normal sentance - followed by 15 bytes of binary FEC.
[21:38] <fsphil> I was thinking base64 encoded FEC
[21:39] <Laurenceb> to be honest I suspect the best gains will be had by rewriting the decoder
[21:39] <Laurenceb> talking to the sound card on a linux system isnt hard
[21:39] <SpeedEvil> indeed
[21:39] <junderwood> My experience is that reception tends to drop off quite rapidly when you cross the radio horizon. If the payload is above the horizon, someone will decode it correctly.
[21:39] <GW8RAK> It's all getting too technical for a chemist and an old one at that.
[21:39] <junderwood> If it's below the horizon, no amount of error correcting is going to help
[21:39] <SpeedEvil> junderwood: Indeed
[21:39] <SpeedEvil> junderwood: I think you can get another 3-6dB or more into the noise
[21:40] <SpeedEvil> junderwood: With relatively minor tweaks
[21:40] <SpeedEvil> junderwood: but even that is fairly useless if it's going behind the horizon
[21:40] <SpeedEvil> As it rapidly fades more than that
[21:40] <junderwood> The last flight I monitored (Alien) went from 100% decode to nothing visible on the waterwall in the space of 2 packets
[21:40] <SpeedEvil> Indeed
[21:41] <SpeedEvil> So you might get another packet - in the case of the above
[21:41] <junderwood> that's a lot of work for a single packet
[21:41] <SpeedEvil> Indeed.
[21:41] <natrium42> what if he gets married?
[21:42] <fsphil> lol
[21:42] <junderwood> groan
[21:42] <GW8RAK> Is there a way of sending just the change in value? Such as 12345 in packet 1 becomes 12346 in packet 2 without sending all bytes?
[21:42] <GW8RAK> Groan
[21:42] <fsphil> GW8RAK, you'd need the previous packet to make sense of the new one
[21:42] <natrium42> thanks, i will be here all day
[21:42] <Randomskk> GW8RAK: but then, if you missed packet 1, packet 2 was useless
[21:42] <DanielRichman> I might try that on Alien 2
[21:42] <SpeedEvil> GW8RAK: yes - see the above 3 byte packet idea
[21:43] <DanielRichman> which is arguably a "let's mess with comms" payload
[21:43] <fsphil> better to run at 300 baud, send more packets
[21:43] <GW8RAK> True, I was thinking of another system which had handshaking.
[21:43] <GW8RAK> SpeedEvil, yes, I've got that.
[21:43] <SpeedEvil> GW8RAK: you send the fastest changing - least significant - bytes of the info - the least significant bytes of the lat/lon/alt at 5* the rate of the next - ...
[21:43] <SpeedEvil> k
[21:44] <junderwood> I wouldn't rely on subsequent packets relying on previous ones. Have you ever seen a jpg with one byte wrong?
[21:44] <SpeedEvil> Sorry - I'm stupidly tired today for no good reason, andnot tracking very well.
[21:44] <SpeedEvil> junderwood: yes they would - but there is also obvious cross-checking
[21:45] <SpeedEvil> junderwood: Firstly - you've got the 12 bit checksum. Secondly you've got the fact that it's unlikely to move at >velocity
[21:45] <junderwood> I think our messages crossed. Nevertheless, velocity type sanity checks is what we used to do before checksums.
[21:47] <stilldavid> woot, just got off the phone with the first person from the FAA who's been helpful!
[21:47] <fsphil> sweet
[21:48] <stilldavid> any other US based launches jump through hoops?
[21:49] <GW8RAK> Has anyone run a full flight with 300 baud? I'm aware of the Irish one recently with 300 baud downlink for pictures.
[21:49] <GW8RAK> In practice how much difference is there?
[21:49] <natrium42> i think cusf do
[21:49] <fsphil> I sent telemetry at 300 baud between the image data GW8RAK
[21:49] <fsphil> received most of the strings fine
[21:50] <fsphil> a few others did too I believe
[21:50] <GW8RAK> Perhaps I'll run some tests once the tx is configured
[21:50] <fsphil> yea - I think 300 baud would be fine
[21:51] <jiffe> stilldavid: I spoke with the FAA back in nov about a launch, basically they said so long as the payload was under 4 lbs they didn't care
[21:51] <Randomskk> yea, I understand cusf did 3000 fine before 50 became the cool thing to do
[21:51] <GW8RAK> If the RTTY which is commonly used is just 2 tones and packet radio is also 2 tones, will there be any difference in performance by using a packet radio tnc?
[21:52] <GW8RAK> 300 baud is easily done with a Picaxe chip, while 50 baud needs a bit more processing.
[21:52] <stilldavid> jiffe, that's lucky... the guy I talked to said I need to fill out a form 7711-2 and file with the Regional Coordinator for Ballooning
[21:53] <stilldavid> gotta follow regulation FAR-101, y'know
[21:53] <stilldavid> (you can't make this stuff up)
[21:53] <fsphil> stilldavid, did you fix the tx problem you had?
[21:53] <jiffe> yeah, that is what he referenced originally, but there is another part somewhere that states a 4 lb limitation
[21:54] <stilldavid> fsphil, still buggy after 32 characters :-/ banged my head against a wall a couple hours last night then gave up
[21:54] <fsphil> so the first 32 characters are received fine?
[21:54] <stilldavid> jiffe, I might call him back tomorrow before filing and double check. there's a 2-week turnaround for the RCfB, and I want to launch this weekend if I can
[21:54] natrium42 (~natrium@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc: Quit: Leaving
[21:54] <stilldavid> fsphil, yes plus or minus a character or two
[21:55] <stilldavid> I might try disabling interrupts before xmitting, then re-enabling upon completion
[21:56] <stilldavid> .. but I'm using the dummy serial which I thought had the same effect.
[21:56] <DanielRichman> stilldavid, how many stop bits do you have?
[21:57] <stilldavid> DanielRichman, 8n1
[21:57] <DanielRichman> stilldavid, make it 8n2 but leave fldigi configured for 8n1 and see what happens
[21:58] <fsphil> I don't think fldigi even cares about the stop bits .. it just waits however long it takes for the start bit
[21:58] <stilldavid> DanielRichman, interesting... any particular reason that might work?
[21:58] <DanielRichman> exactly fsphil
[21:58] <DanielRichman> if the timing is slightly off
[21:58] <DanielRichman> maybe the errors accumalate over 32 characters
[21:58] <DanielRichman> so an extra stop bit may instead cause it to wait for the start?
[21:58] <DanielRichman> resetting any difference in the timing. I can't know for sure
[21:59] <fsphil> but at 300 baud I found fldigi was much more reliable if I sent 1.5 or 2 stop bits
[21:59] <SpeedEvil> If so - fldigi is broken
[21:59] <stilldavid> I'd think that it might work twice as long before the errors start again, which would probably be acceptable
[21:59] <stilldavid> I'll try that, for sure though
[21:59] <SpeedEvil> It should resync - at least somewhat - every char
[22:00] <DanielRichman> stilldavid, I'm not intending it to be a solution, more a diagnosis of a potential problem
[22:00] <stilldavid> ah, gotcha.
[22:00] <DanielRichman> SpeedEvil, indeed. I may be totally wrong
[22:00] <stilldavid> any ideas what might be throwing the timing off in general>
[22:00] <GW8RAK> What is 1.5 stop bits like? Is it just a longer bit?
[22:00] <stilldavid> at the risk of being totally laughed at: http://github.com/stilldavid/high-altitude/blob/master/balloon/balloon.pde
[22:00] <fsphil> GW8RAK, yea
[22:00] <stilldavid> don't ask me to explain any of it :P
[22:01] <SpeedEvil> DanielRichman: I'm not saying you're not right. And indeed, it's not a ad idea.
[22:01] <fsphil> lol, "This works out to a baud rate of 50 bps. Somehow."
[22:01] <stilldavid> and it's obviously not the same loop() I'll be sending up, it's just where I left it.
[22:01] <stilldavid> :-D
[22:01] <stilldavid> I tried a few different methods of delay()ing, and that seemed to work alright
[22:01] <DanielRichman> are you using the same arduino as the guy who wrote that code?
[22:02] <fsphil> brb, food
[22:02] <DanielRichman> stilldavid, line 102. Just duplicate it
[22:02] <stilldavid> hmm, don't know for sure but I thought that the compiler did magic to make delay() work
[22:03] <stilldavid> DanielRichman, at work currently, but will report back tomorrow once it's dupe'd
[22:03] <DanielRichman> avr-libc's #include <util/delay.h> _delay_ms and _delay_us functions are certainly magical
[22:03] <DanielRichman> however those are written by the arduino guys. Also the timing takes into account the speed of the horrendously slow digitalWrite functions
[22:03] <DanielRichman> which may differ between arduino boards which have to do different look ups
[22:03] <stilldavid> is there a better way to get the correct timing?
[22:04] <DanielRichman> use one of the Atmega's peripheral timers
[22:04] <DanielRichman> the 16bit timer will do nicely
[22:04] <jiffe> stilldavid: he may have been referencing 101.1
[22:05] <stilldavid> Icarus used delaymicroseconds, looks like: http://www.pegasushabproject.org.uk/wiki/doku.php/ideas:notes?s[]=rtty
[22:05] <DanielRichman> stilldavid, but doing so requires some knowledge of the bare AVR libc
[22:05] <stilldavid> #define BAUD_RATE 20150 // 10000 = 100 BAUD 20150
[22:06] <stilldavid> DanielRichman, I'm not a terribly good programmer, to be honest, but I think I can give it a shot...
[22:06] <DanielRichman> stilldavid, well see if double stopbits with fldigi still on 8n1 helps
[22:06] <DanielRichman> then you might be closer to finding your problem
[22:06] <stilldavid> well, I'm a web programmer by trade so this is all pretty new to me
[22:06] <stilldavid> DanielRichman, so what am I looking for in doubling the stop bits?
[22:07] <DanielRichman> it magically starting to work
[22:07] <stilldavid> if it works past 32 chars, or past 64 chars, or whatever?
[22:07] <DanielRichman> otherwise, you could make a recording of your payload not working using Fldigi -> File -> Audio -> RX Capture
[22:07] <DanielRichman> and we can have a closer look at ti
[22:07] <stilldavid> if I can't get it to work, I'll most certainly do that.
[22:08] <stilldavid> thanks so much for your (continued) help!
[22:08] <stilldavid> brb
[22:21] GW8RAK (~chatzilla@client-86-31-171-140.oxfd.adsl.virginmedia.com) left irc: Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]
[22:22] DanielRichman (~DanielRic@unaffiliated/danielrichman) left irc: Quit: Leaving
[22:26] Randomskk_ (~adam@paladin.randomskk.net) joined #highaltitude.
[22:29] Randomskk_ (~adam@paladin.randomskk.net) left irc: Client Quit
[22:35] MoALTz (~no@92.19.24.104) left irc: Quit: Leaving
[22:39] <jiffe> stilldavid: so do you have 2 independent remotely controllable cutdown devices?
[22:39] <stilldavid> well, the balloon bursting is one, and I've got nichrome wire as a secondary
[22:40] <stilldavid> was going to try to get away without the nichrome for the first launch, but might have to use it after all
[22:40] <stilldavid> I'm not sure how they expect it to be remotely controlled, like if it has to be on a radio at your beck-and-call, or if it can have some other logic to it
[22:40] <stilldavid> I'd ideally have it cut down after a preset amount of time (eg: 5 hrs) or something
[22:40] <stilldavid> just compare GPS timestamps
[22:41] <fsphil> or both -- incase you loose gps lock
[22:41] <jiffe> yeah thats what we set it up for, although it never triggered it should have, we ended up underfilling the balloon so the flight lasted longer than expected
[22:41] <jiffe> far101 just says it needs to be remotely controlled in the event of bad weather
[22:42] <stilldavid> so is a time-based cutdown acceptable?
[22:42] <fsphil> you're required to have a cut-down mechanism?
[22:42] <stilldavid> as per far101, yeah fsphil
[22:42] <jiffe> according to far101 it wouldn't be, but the fsdo guy I talked to said that didn't apply to us
[22:43] <stilldavid> jiffe, I might call my guy back and see what his interpretation is
[22:43] <stilldavid> looking at the waiver he wanted me to fill out, it seems applicable to moored balloons and not so much untethered ones
[22:44] <stilldavid> "provisions made for policing of the event" and such
[22:45] <jiffe> yeah, subpart d doesn't really say anything about documentation, just notification 6-24 hours prior to launch
[22:47] <jiffe> launching in SD is probably pretty easy, not likely to hit anything
[22:47] <jiffe> although there is an afb not too far away
[22:49] Jasperw (~jasperw@78-86-9-131.zone2.bethere.co.uk) left irc: Quit: Leaving.
[22:54] <stilldavid> FAA guy told me that there are "8 arrival/departure vectors for Denver International"
[22:54] <stilldavid> or something like that :P
[22:55] <stilldavid> I should just drive up into the hills and launch from there
[22:55] <jiffe> yeah, but you're ok so long as you're above 2000 ft when within someone's airspace
[22:56] <stilldavid> how do you mean?
[22:56] <jiffe> well the balloon needs to be above 2000 ft before entering an airport's airspace
[22:57] <stilldavid> ah, okay.
[22:58] LazyLeopard (~irc-clien@chocky.demon.co.uk) left irc: Quit: Bye
[22:58] <jiffe> when are you looking to launch?
[22:59] <stilldavid> well, was hoping this weekend, but I think I've got quite a bit more work to do :P
[22:59] <stilldavid> I called around a couple weeks ago, and just got called back today
[23:00] <jiffe> ah wow yeah I think I got a callback the next day, but I kind of got the run around for a while
[23:00] <stilldavid> I called 5 or 6 different numbers
[23:00] <stilldavid> from the FAA 800 line to DEN to the local municipal airport
[23:02] <jiffe> yeah its a pain
[23:03] <stilldavid> well, my payload is <4lbs, so I'm calling back
[23:04] <jiffe> yeah the guy I talked to directed me to 101 subpart d and was going to look into it further and then got back to me saying it didn't matter since the payload was less than 4 lbs
[23:04] <jiffe> which made things a whole lot easier
[23:13] <Laurenceb> SpeedEvil: ping
[23:13] [STAR]Atanyi|MnG (~Upu@ubn.upuaut.net) left irc:
[23:13] <SpeedEvil> ?
[23:13] <Laurenceb> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=REG104GA-5CT-ND
[23:13] <Laurenceb> I'm looking at adding a servo reg for my board
[23:13] <Laurenceb> still working on it... :-/
[23:14] <Laurenceb> do you think that that would be ok with EN left floating?
[23:14] rharrison_ (~rharrison@gateway.hgf.com) left irc: Ping timeout: 240 seconds
[23:14] <Laurenceb> would the internal zener be enough to pull it down?
[23:14] <SpeedEvil> Sorry - my net is slow - ...
[23:19] <Laurenceb> http://www.procerusuav.com/productPricing.php
[23:19] <Laurenceb> ^ niiiiccccceeee
[23:22] SpeedEvil (~user@tor/regular/SpeedEvil) left irc: Ping timeout: 240 seconds
[23:24] junderwood (~John@adsl.jcu.me.uk) left irc: Quit: Leaving
[23:24] <Laurenceb> I dont believe it - http://www.sparkfun.com/commerce/product_info.php?products_id=9801
[23:26] <stilldavid> disclaimer: I now work for Sparkfun Electronics
[23:27] <Laurenceb> heh
[23:27] <Laurenceb> you do?
[23:27] <stilldavid> sure do.
[23:27] <jiffe> do you get good discounts? :)
[23:28] <stilldavid> actually, Nate (the Big Boss) is super interested in my HAB project, so I fully expect a HAB-centric board soon
[23:28] <Laurenceb> nice
[23:28] <stilldavid> combining gps, radio, weather, cutdown
[23:28] Action: Laurenceb is looking for a diff pressure sensor
[23:28] <Laurenceb> I'm working on an autopilot board
[23:28] <stilldavid> I'm sure you're all up on DIYdrones
[23:29] <Laurenceb> yeah
[23:29] <Laurenceb> thats good http://gb.mouser.com/ProductDetail/Honeywell/HSCMRRN001PD2A3/?qs=sGAEpiMZZMtNN8B0DWOGd2pjm63TFfUi0DsWrfDDam8%3d
[23:29] <Laurenceb> but not stocked
[23:30] <Laurenceb> and 20 MOQ :-(
[23:31] <stilldavid> I'd buy one from you just to play with it
[23:31] <Laurenceb> theres these things which have insane performance http://www.sensirion.com/en/04_differential_pressure_sensors/01_sdp600-differential-pressure-sensors/00_sdp600-differential-pressure-sensors.htm
[23:31] <Laurenceb> but GBP66 a shot and rather large
[23:33] <Laurenceb> ooh hang on a sec
[23:33] <Laurenceb> http://www.sensirion.com/en/04_differential_pressure_sensors/01_sdp600-differential-pressure-sensors/02_freesampling-sdp610.htm
[23:36] SpeedEvil (~user@tor/regular/SpeedEvil) joined #highaltitude.
[23:36] <SpeedEvil> (11:14:37 PM) SpeedEvil: Sorry - my net is slow - ...
[23:36] <SpeedEvil> (11:23:07 PM) SpeedEvil: As I read it - there is no internal zener
[23:36] <SpeedEvil> (11:23:26 PM) SpeedEvil: that is a suggestion for an external circuit if you are using a enable voltage that may exceed 10v
[23:36] <SpeedEvil> (11:23:50 PM) SpeedEvil: fig 4 - implies that at best it's a very high impedence input - so should be tied to vin
[23:36] <SpeedEvil> (11:24:53 PM) SpeedEvil: (unless vin exceeds 10v - then you need the resistor/zener or a logic output)
[23:36] <SpeedEvil> Laurenceb:
[23:37] <Laurenceb> oh
[23:37] Action: Laurenceb reads
[23:37] <Laurenceb> thamks
[23:37] <SpeedEvil> s/slow/fucking broken/
[23:38] <Laurenceb> "Internal to the part, the Enable pin is connected to an input
[23:38] <Laurenceb> resistor-zener diode circuit, as shown in Figure 3, creating a
[23:38] <Laurenceb> nonlinear input impedance.
[23:38] <Laurenceb> "
[23:38] <Laurenceb> apparently not
[23:39] <SpeedEvil> it's horribly written
[23:40] <Laurenceb> heh, but a very nice reg
[23:40] <Laurenceb> I'm thinking of sticking a solder jumper on the EN pin
[23:40] <SpeedEvil> Anyway - the above comments about the high impedence stand
[23:40] <Laurenceb> so you can disable the reg
[23:41] <jiffe> sweet, winter weather advisory for tomorrow
[23:41] <jiffe> and here I thought it was may :\
[23:41] MoALTz (~no@92.19.24.104) joined #highaltitude.
[23:41] <SpeedEvil> It would seem tomakemore sense to not populate it.
[23:41] <SpeedEvil> jiffe: You're in the US?
[23:41] Action: SpeedEvil forgets
[23:41] <Laurenceb> yeah, but solder jumpers are kind of removable
[23:41] <jiffe> yeah, south dakota
[23:41] <SpeedEvil> suppose
[23:41] <Laurenceb> wondering if the EN will float low ok
[23:42] Action: SpeedEvil ponders what he knows about south dakota.
[23:42] <Laurenceb> as running out of board space for a pulldown
[23:42] <SpeedEvil> Very little, other than there is probably a north dakota.
[23:42] <Laurenceb> heh
[23:42] <Laurenceb> tornadoes?
[23:42] <SpeedEvil> Laurenceb: Look at the curve - and the input spec - it specifies nanoamps of input current at around the switching voltage.
[23:42] <SpeedEvil> Laurenceb: This means you need a pullup.
[23:42] <jiffe> haha yes, and now you know it snows in may, actually we had a pretty bad blizzard in may 2 years ago I think
[23:42] <Laurenceb> down you mean
[23:43] <Laurenceb> SpeedEvil: will a voltage on VOUT fry it?
[23:43] <jiffe> east side gets some tornadoes, not really over here on the west, and not very frequent
[23:43] <Laurenceb> - of VIN is gnd along with EN
[23:43] <SpeedEvil> 'this pin is active high' - enable
[23:44] <SpeedEvil> Laurenceb: It doesn't seem to say you can't.
[23:45] <SpeedEvil> Laurenceb: there is no caveat on the 'input input or output voltage range
[23:46] <Laurenceb> I guess with a large decoupling cap on VOUT
[23:46] <Laurenceb> its going to experience the same sort of conditions in normal use
[23:47] <Laurenceb> hmm yeah figure 4 shown _very_ low currents
[23:47] <SpeedEvil> Also - as I read the circuit diagram - it shouldn't be inherently vulnerable to that
[23:47] <Laurenceb> guess its needs a pull down
[23:47] <SpeedEvil> As it is designed for substrate voltages to exceed vout
[23:49] <Laurenceb> yeah
[23:49] <Laurenceb> oh well I'm off, cya
[23:49] <SpeedEvil> wave
[23:49] Action: SpeedEvil wonders how many kitchen sinks this thing will have when done.
[23:53] Laurenceb (~laurence@host213-120-39-84.range213-120.btcentralplus.com) left irc: Ping timeout: 240 seconds
[23:58] juxta (fourtytwo@203.122.193.94) joined #highaltitude.
[23:58] Randomskk_ (~adam@paladin.randomskk.net) joined #highaltitude.
[23:59] fsphil (~phil@beastie.sanslogic.co.uk) left irc: Quit: Vote Me!
[00:00] --- Wed May 12 2010