highaltitude.log.20100725

[00:10] LazyLeopard (~irc-clien@chocky.demon.co.uk) left irc: Quit: Bye
[00:18] [STAR]Atanyi|HCs (~Upu@ubn.upuaut.net) left irc:
[00:22] natrium42 (~natrium42@12.130.118.15) joined #highaltitude.
[00:38] SpeedEvil (~user@tor/regular/SpeedEvil) left irc: Ping timeout: 246 seconds
[00:44] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) joined #highaltitude.
[00:49] <jcoxon> evening
[00:49] <natrium42> yo jcoxon
[00:50] <natrium42> you were looking for moi?
[00:50] <jcoxon> oui but no worries
[00:50] <jcoxon> it was to get the predictor working
[00:50] <jcoxon> but i worked
[00:50] <jcoxon> it out
[00:52] <natrium42> cool
[00:52] <natrium42> who is launching?
[00:52] <jcoxon> it was GPSL today
[00:52] <natrium42> aah
[00:52] <natrium42> i missed it :(
[00:53] <natrium42> is it still up?
[00:53] <natrium42> 25km alt
[00:53] <natrium42> lol, we just flew by their launch location
[00:54] Action: natrium42 is en route to LA
[00:54] <jcoxon> hehe oh they ran out of credit on their 3g modem
[00:55] <natrium42> oops
[00:55] <jcoxon> wb8elk made a talk about spacenear.us
[00:55] <jcoxon> at teh confernece
[00:55] <natrium42> bah, we really need to rework it
[00:55] <natrium42> and make a proper backend
[00:56] <jcoxon> yeah
[00:57] SpeedEvil (~user@tor/regular/SpeedEvil) joined #highaltitude.
[00:59] Laurenceb (~laurence@host86-160-237-64.range86-160.btcentralplus.com) left irc: Remote host closed the connection
[01:04] gamers600 (~gamers600@ip68-99-230-95.ph.ph.cox.net) left irc: Quit: gamers600
[01:04] gamers600 (~gamers600@ip68-99-230-95.ph.ph.cox.net) joined #highaltitude.
[01:11] grummund (~grummund@unaffiliated/grummund) joined #highaltitude.
[01:12] Dan-K2VOL (~steamatom@69.64.6.67) joined #highaltitude.
[01:21] <jcoxon> hey Dan-K2VOL hows the globaltuners going?
[01:22] <Dan-K2VOL> Hey jcoxon, great!! Got the rig interface working for the first time
[01:22] <natrium42> hey dan
[01:22] <Dan-K2VOL> Now punching holes thru the hackerspace firewall
[01:22] <jcoxon> oh thats fun
[01:22] <Dan-K2VOL> Hi Alexei
[01:22] <jcoxon> i had port forwarding
[01:22] <Dan-K2VOL> Yeah, pizza just arrived, brb
[01:23] juxta (juxta@ppp203-122-193-94.static.internode.on.net) joined #highaltitude.
[01:23] <natrium42> i'll have the cheese one
[01:36] Dan-K2VOL (~steamatom@69.64.6.67) left irc: Ping timeout: 259 seconds
[01:48] Dan-K2VOL (~steamatom@69.64.6.67) joined #highaltitude.
[01:54] MoALTz (~no@188.146.36.18.nat.umts.dynamic.eranet.pl) left irc: Quit: Leaving
[02:02] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) left irc: Quit: Leaving
[02:09] Dan-K2VOL (~steamatom@69.64.6.67) left irc: Quit: Colloquy for iPhone - http://colloquy.mobi
[02:13] SpeedEvil (~user@tor/regular/SpeedEvil) left irc: Quit: Leaving.
[02:24] Dan-K2VOL (~steamatom@69.64.6.67) joined #highaltitude.
[02:24] <Dan-K2VOL> Hey natrium42
[02:24] <natrium42> hi, how was pizza?
[02:24] MindSpigot (~random@78-86-167-25.zone2.bethere.co.uk) joined #highaltitude.
[02:25] <Dan-K2VOL> Mmm mmm good, pepperoni, thin NY style
[02:27] dcrand (~d_crand@68-117-98-7.dhcp.eucl.wi.charter.com) joined #highaltitude.
[02:27] dcrand (d_crand@68-117-98-7.dhcp.eucl.wi.charter.com) left #highaltitude.
[02:28] <Dan-K2VOL> How are you doing alexei
[02:29] <natrium42> great, en route to LA
[02:29] <natrium42> over Arizona right now
[02:29] <natrium42> how are you?
[02:32] <Dan-K2VOL> Oh wow, what are you up to there? In flight wifi?
[02:32] <Dan-K2VOL> Or did you make a bigger balloon
[02:32] <natrium42> yeah, virgin america wifi
[02:32] <natrium42> going to SIGGRAPH conference
[02:32] <natrium42> computer graphics related
[02:33] <Dan-K2VOL> Cool
[02:33] <Dan-K2VOL> Be sure to go to the Griffith Observatory/planetarium if u have time one night
[02:33] <Dan-K2VOL> The have a huge public telecope
[02:33] <Dan-K2VOL> And an amazing science museum
[02:34] <natrium42> cool, i will look it up
[02:35] <natrium42> going to be landing soon
[02:35] <Dan-K2VOL> Ok, drop out when needed
[02:35] <natrium42> :)
[02:35] <Dan-K2VOL> What's the status of your spot hacking?
[02:36] <natrium42> well, i did one test flight, it worked well
[02:36] <natrium42> got SPOT2 for personal use, but didn't take it apart yet
[02:37] <natrium42> want to see if they changed the satellite transmitter portion of it
[02:37] <Dan-K2VOL> Nice, I think I may try your mods, some guys at the local hackerspace in my new city are interested in balloons
[02:39] <natrium42> cool, you can actually borrow my hacked SPOT if you like
[02:39] <natrium42> but i will help you out if you want to hack yours
[02:44] <Dan-K2VOL> Thank you!
[02:45] <Dan-K2VOL> I will talk to you more about that sometime soon. Not sure if I can convince these guys to try long duration
[02:49] <natrium42> kk
[02:52] <Dan-K2VOL> Going to go try to string up an urban alley dipole!
[02:54] <natrium42> ok, i am off
[02:54] <natrium42> see you!
[02:54] natrium42 (~natrium42@12.130.118.15) left irc: Quit: My other car is a cdr.
[03:18] gamers600 (~gamers600@ip68-99-230-95.ph.ph.cox.net) left irc: Quit: gamers600
[03:27] Dan-K2VOL (~steamatom@69.64.6.67) left irc: Remote host closed the connection
[03:29] SpeedEvil (~user@tor/regular/SpeedEvil) joined #highaltitude.
[03:36] jasonb (~jasonb@m370536d0.tmodns.net) joined #highaltitude.
[04:00] jasonb (~jasonb@m370536d0.tmodns.net) left irc: Ping timeout: 240 seconds
[06:07] jrs4569_ (~john@c-76-113-181-137.hsd1.mn.comcast.net) joined #highaltitude.
[07:40] jrs4569_ (~john@c-76-113-181-137.hsd1.mn.comcast.net) left irc: Quit: Ex-Chat
[07:49] Upu (~Upu@ubn.upuaut.net) joined #highaltitude.
[09:46] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) joined #highaltitude.
[09:49] Jasperw (~jasperw@212-98-44-230.static.adslpremium.ch) joined #highaltitude.
[09:52] <jcoxon> morning all
[10:01] <DanielRichman> morning
[10:01] <jcoxon> DanielRichman, you back from greece?
[10:01] <DanielRichman> yeah
[10:02] <jcoxon> cool
[10:03] <DanielRichman> how are you?
[10:03] <jcoxon> good thank you
[10:03] <jcoxon> you?
[10:03] <DanielRichman> yeah I'm good
[10:03] <DanielRichman> reading the BH5 stuff
[10:03] MoALTz (~no@188.146.174.201.nat.umts.dynamic.eranet.pl) joined #highaltitude.
[10:03] <jcoxon> oh right - that was a while ago!
[10:04] <DanielRichman> yeah :P It looks like it was fun
[10:04] <jcoxon> guess i'll have to do BH6
[10:04] <jcoxon> just to prove it :-p
[10:04] <jcoxon> but not straight away
[10:06] <DanielRichman> oh of course; apex launched too
[10:06] <DanielRichman> how did their uplink go?
[10:07] <jcoxon> not sure about hte uplink - missed that flight
[10:16] <DanielRichman> hmmm a lot has happened while I've been awol. BBC even have a new news homepage
[10:16] <DanielRichman> and farnell still haven't replied to my email
[10:17] <DanielRichman> nor have they taken delivery of any atmegaxa4s :'(
[10:17] <jcoxon> farnell are just rubbish
[10:17] <DanielRichman> it would seem so
[10:19] <DanielRichman> ahh well RS are doing better http://www.rs-components.com/offline/europe.html
[10:19] <DanielRichman> oh it's back now.
[10:31] chembrow (~chris@188-221-15-153.zone12.bethere.co.uk) joined #highaltitude.
[10:58] Hiena (~Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[11:07] <jcoxon> ping DanielRichman
[11:07] <DanielRichman> hi
[11:07] <jcoxon> http://pegasus4.no-ip.org/~jamescoxon/dl-fldigi.php
[11:08] <DanielRichman> :)
[11:09] <DanielRichman> I like it
[11:12] fsphil_ (~fsphil@82.132.248.231) joined #highaltitude.
[11:12] <fsphil_> yay, 3G
[11:32] <jonsowman> hi DanielRichman
[11:32] <DanielRichman> hi
[11:32] <jonsowman> uplink worked fine :)
[11:33] <DanielRichman> cool
[11:33] <jonsowman> we never used the controlled cutdown, but we pinged the payload and it responded
[11:36] <DanielRichman> nice
[11:37] <jcoxon> any html/php magicians around? want a smal project...
[11:37] <jcoxon> small*
[11:37] <jonsowman> jcoxon: go on
[11:37] <jonsowman> DanielRichman: see packet 311 at http://balloon.hexoc.com/apex-ii/data.txt
[11:38] <jcoxon> jonsowman, http://pegasus4.no-ip.org/~jamescoxon/dl-fldigi.php
[11:39] <jcoxon> so that now can control dl-fldigi - really just needs a better interface
[11:39] <jonsowman> heh very neat
[11:39] <jonsowman> i'm pretty busy at the moment but if nobody else takes it up, I can work on it
[11:40] <jcoxon> basically i use phpxmlprc to directly interface with dl-fldigi
[11:40] <jcoxon> so now you can pass any of these commands:
[11:40] <jcoxon> http://www.w1hkj.com/FldigiHelp-3.12/xmlrpc-control.html
[11:40] <jonsowman> nice
[11:41] <jonsowman> that's really cool
[11:41] <jcoxon> i'll email the ukhas list - see if there is anyone wanting to get involved
[11:42] <jonsowman> i'm definitely up for helping
[11:42] <jonsowman> is the php code anywhere I can have a look over it?
[11:42] <jcoxon> its probably worth us adding a few xmlrpc commands of our own
[11:42] <jcoxon> let me start a new github thingy
[11:44] fsphil_ (~fsphil@82.132.248.231) left irc: Ping timeout: 264 seconds
[11:45] <jonsowman> ok
[11:50] <jcoxon> jonsowman, http://github.com/jamescoxon/dl-fldigi-XMLRPC
[11:50] <jcoxon> its a mess as i only wrote it this morning and don't really do php
[11:50] <DanielRichman> anything ending in .php is a mess
[11:50] <DanielRichman> the language is designed that way
[11:51] <jonsowman> heh
[11:51] <jonsowman> I don't entirely agree, but anyway
[11:52] <jonsowman> I shall have a look over it :)
[11:54] <jonsowman> I think perhaps make all of this AJAX'y
[11:54] <jonsowman> it need to refresh the entire page
[11:55] <DanielRichman> you can never have enough ajax
[11:55] <jonsowman> *not
[11:55] <jcoxon> hehe okay, i've no idea about web stuff
[11:55] <DanielRichman> is there any way of double buffering (orsmthing) the images so that there isn't a flicker when the image reloads?
[11:55] <jcoxon> haven't coded a webpage for about 10 years
[11:55] <DanielRichman> javascript preload style?
[11:55] <jonsowman> DanielRichman: yep easily done
[11:56] <jonsowman> to be honest, I think refreshing the image with an AJAX request will prevent it flickering
[11:56] <jcoxon> we could actually jsut 'recreate' dl-fldigi in web based form
[11:56] <jonsowman> jcoxon: that's what I was thinking
[11:57] <jonsowman> if we're doing that it pretty much confirms using AJAX, as otherwise every user interaction will cause the page to refresh
[11:57] <jcoxon> okay
[11:57] <jcoxon> i've never worked with ajax
[11:57] <jonsowman> jQuery makes it lovely to use
[11:57] <jcoxon> maybe i should stick to the dl-fldigi side :-p
[11:57] <jonsowman> coding ajax stuff in native javascript is a pain - never do it
[11:58] <jonsowman> I'll start putting together an ajax'y interface for it
[11:58] <jonsowman> jcoxon: how do you want to do the git side of things?
[11:58] <jonsowman> shall I just push/pull to/from your repo?
[11:58] <jonsowman> or shall I fork?
[11:59] <jcoxon> ummm push/pull i guess
[11:59] <jcoxon> how do i give you permission to do that?
[11:59] <jonsowman> in repo admin, add me as a collaborator
[12:00] <jonsowman> "jonsowman"
[12:00] <jonsowman> it should find me as you start typing it
[12:00] <jcoxon> done
[12:00] <jonsowman> thanks :)
[12:01] <jonsowman> i have to disappear for a bit
[12:02] <jonsowman> bbl
[12:02] <jcoxon> np
[12:18] <chembrow> afternoon all. I've got an issue with transmitting from an arduino and an NTX2 I hope someone can assist with?
[12:18] <jcoxon> chembrow, yup
[12:18] <jcoxon> go for it
[12:19] <chembrow> I've got the 'duino outputting at 7N1
[12:19] <chembrow> and when I send a short string, say "Hello World" fldigi picks it up fine
[12:19] <chembrow> but when I send a longer string, of 80+ characters, it drops out towards the end then recovers
[12:19] <chembrow> this is fairly consistent
[12:20] <chembrow> so "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890abcdefghijklmnopqrstuvwxyz"
[12:20] <chembrow> comes up as "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ123456789\.Nn'7GWgwqrstuvwxyz"
[12:20] <chembrow> any ideas?
[12:20] <jcoxon> could be a timing issue
[12:20] <jcoxon> what code are you using?
[12:21] <chembrow> it's my own arduino code, using the timer2 to control the transmit rate
[12:21] <jcoxon> odd that it drops out but then recovers
[12:22] <chembrow> every time the timer interrupts it just sends the next bit
[12:22] <DanielRichman> chembrow: that's good; much better than using delay
[12:22] <chembrow> I looked at what else was potentially using the interrupts, but all that should be running is the standard hardware serial, which is trnsmitting
[12:23] <chembrow> DanielRichman TBH, it's based on your code from alien :)
[12:23] <chembrow> the principle, anyway
[12:23] <DanielRichman> :)
[12:25] <chembrow> I'm outputting to the hardware serial port what I'm sending over the NTX2, and thats fine, so it's parsing the string properly
[12:26] <chembrow> I did have an issue with the software serial interfering (which took a while to figure out) but I've disabled all that code
[12:28] <DanielRichman> in both of your tests are you sending continuously?
[12:29] <DanielRichman> ie Hello World continuously and the long string continuously?
[12:29] <DanielRichman> can we see your code?
[12:30] <chembrow> not continuosuly, every 30 seconds (10 with hello world) it rebuilds the message - the sending code is continuous (except when the message building is happening)
[12:30] <chembrow> I will put the code somewhere, give me 5
[12:32] <chembrow> it's in multiple files in the arduino IDE, just putting them together
[12:35] <chembrow> http://www.pixelseventy2.net/code.txt
[12:42] <chembrow> basically, every 30 seconds it should read the GPS, sensors etc... then re-build the message to transmit. the transmit should happen immediately, as long as there is something to send
[12:44] <jcoxon> chembrow, had issues with strcat on the arduino
[12:44] <jcoxon> ended up using sprintf
[12:45] <jcoxon> it does ring a bell about having problems with long strings but i used delay rather then interrupt so might be a bit different
[12:45] <DanielRichman> strcat manpage:
[12:45] <DanielRichman> The strings may not overlap, and the dest string must have enough space for the result.
[12:46] <DanielRichman> just be sure that you don't bust the buffer's length
[12:46] <chembrow> in this case, the _buildMessage function containing the strcat isn't running
[12:46] <chembrow> although the message length is ~90 chars, and the buffer is 128
[12:47] <chembrow> at the moment I'm hard-coding the message as "abc..."
[12:48] <DanielRichman> are you sending two stop bits?
[12:49] <chembrow> 1 stop - using 7N1
[12:49] <DanielRichman> try 2 stops
[12:49] <chembrow> OK
[12:54] <chembrow> just to confirm, that's just sending 2 marks before the next character?
[12:54] <DanielRichman> yeah
[12:54] <DanielRichman> two stop bits
[12:55] <DanielRichman> just have STATE_STOP_1 and STATE_STOP_2
[12:55] <chembrow> ta, that's what I thought.
[12:55] <chembrow> yeah, that's what I did
[12:55] <chembrow> I've changed the code to send 2 stops, and it now rebuild the message at the end of the current one, not on the timer (at 30 seconds)
[12:55] <chembrow> hello world goes continuously fine, just gonna try a longer message
[12:57] <chembrow> looking good so far
[12:58] <DanielRichman> ok if 2 stop bits fixes it then you may want to look at the timing
[12:58] <DanielRichman> or just accept it as fixed :)
[12:58] <chembrow> :) I'll see if it was removing the message build from the timer loop, or the 2 stop bits
[13:05] <chembrow> it's definitely the 2 stops that fixes it, not sure there's much else I can do with the timing - the only thing that's running on the timer now is the sending
[13:05] <chembrow> *shrugs*
[13:06] <chembrow> thanks for the help
[14:12] chembrow (chris@188-221-15-153.zone12.bethere.co.uk) left #highaltitude.
[14:28] dcrand (~d_crand@68-117-98-7.dhcp.eucl.wi.charter.com) joined #highaltitude.
[14:28] dcrand (d_crand@68-117-98-7.dhcp.eucl.wi.charter.com) left #highaltitude.
[14:30] <fsphil> home sweet home
[14:32] <jcoxon> hey fsphil
[14:33] <fsphil> g'day jcoxon, seems I missed a right bit
[14:33] <jcoxon> what did you miss?
[14:33] <jcoxon> :-)
[14:35] <fsphil> remote control dl-fldigi? :) that sounds cool
[14:35] <jcoxon> oh yeah
[14:35] <jcoxon> finally got my head around xmlrpc in php
[14:37] <fsphil> what all can you do with it?
[14:37] <jcoxon> fsphil, http://pegasus4.no-ip.org/~jamescoxon/dl-fldigi-XMLRPC/dl-fldigi.php
[14:37] <jcoxon> well we can control nearly everything
[14:38] <fsphil> I'd tried controlling it over vnc but the gsm signal is too patchy to make it worth while
[14:38] <jcoxon> just my web programming is terrible
[14:38] <jcoxon> so i'm recruiting :-)
[14:38] <jcoxon> i think jonsowman had some ajax plans for it
[14:38] <fsphil> that would be so much quicker as a jpeg :)
[14:38] <fsphil> but very sweet
[14:38] <DanielRichman> no it should be a gif really
[14:39] <fsphil> gif won't help
[14:39] <DanielRichman> I think I chose png because libpng was the easiest to use at the time
[14:39] <DanielRichman> there's only like 3 colours in that image
[14:39] <jcoxon> i've added a text box to allow you to change the save location of the png
[14:39] <DanielRichman> ideal for pallette
[14:40] <fsphil> use a png with a palette then :)
[14:40] <fsphil> still thing jpeg would be better, it doesn't have to be pixel perfect
[14:40] <DanielRichman> hmm you can can't you
[14:40] <DanielRichman> true
[14:40] <fsphil> png can go down to 2-bit if you want it too
[14:40] <DanielRichman> we can do some tests to see what would be the most efficient
[14:40] <fsphil> yea
[14:41] <DanielRichman> I'm up for writing something that will allow you to aim the red crosshairs on the waterfall
[14:41] <DanielRichman> welll not crosshairs
[14:41] <DanielRichman> but the aiming things.
[14:42] <jcoxon> i call them decode lines
[14:42] <jcoxon> :-)
[14:42] <fsphil> "those things" is as far as I get
[14:44] <jcoxon> i'm going to focus on adding a few xmlrpc calls to add the new dl-fldigi features
[14:45] <DanielRichman> btw make sure that choosing the save location of the png doesn't allow you to overwrite system files
[14:45] <jcoxon> ooo thats a good point :-)
[14:45] <DanielRichman> actually just make sure that the person connecting to the web interface can't change it
[14:45] <DanielRichman> then it's up to whoever sets up dl-fldigi
[14:45] <jcoxon> oh thats the way i see it
[14:45] <jcoxon> its something you setup on your server
[14:58] <jcoxon> bbiab
[14:58] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) left irc: Quit: Leaving
[15:14] DaveyC (~IceChat7@188-221-51-13.zone12.bethere.co.uk) joined #highaltitude.
[16:02] MoALTz (~no@188.146.174.201.nat.umts.dynamic.eranet.pl) left irc: Quit: Leaving
[16:16] juxta (juxta@ppp203-122-193-94.static.internode.on.net) left irc: Quit: Leaving
[16:27] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) joined #highaltitude.
[17:29] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) left irc: Quit: Leaving
[17:44] MoALTz (~no@188.146.174.201.nat.umts.dynamic.eranet.pl) joined #highaltitude.
[17:51] m1x10 (~mixio@ppp089210099199.dsl.hol.gr) joined #highaltitude.
[18:06] jcoxon (~jcoxon@host86-162-96-133.range86-162.btcentralplus.com) joined #highaltitude.
[18:28] <m1x10> hi all
[18:33] <fsphil> hullo m1x10
[18:36] Hiena (~Hiena@81.93.195.181.datatrans.hu) left irc: Quit: -=Got bored from the net. Gone blowing up things.=-
[18:51] m1x10 (~mixio@ppp089210099199.dsl.hol.gr) left irc:
[19:08] <jcoxon> evening all
[19:14] <fsphil> quiet evening
[19:14] <jcoxon> yeah
[19:14] <fsphil> I'm cleaning my desk before I loose or break something
[19:14] <jcoxon> hehe, i'm packing - very slowly
[19:14] <jcoxon> probably a box an hour
[19:14] <fsphil> ah, that's right .. the big move. when's the eta?
[19:15] <jcoxon> hehe spread over 2 weeks
[19:15] <jcoxon> can't actually move in till 10th
[19:15] <jcoxon> but need to be at work on weds
[19:15] <jcoxon> so will be living in hospital accomodation
[19:17] <fsphil> not so bad then
[19:17] <jcoxon> oh yeah, just a shame it can't be easier :-p
[19:18] <fsphil> muhaha .. moving sucks, even when it goes well. worth it though
[19:18] <fsphil> usually
[19:20] <jcoxon> wb8elk seemed very keen in your jpeg/rtty
[19:21] <fsphil> yes, and on HF too -- I'd love to see that working
[19:21] <jcoxon> interesting about legalities
[19:21] <jcoxon> on our licence exempt can do what we want
[19:22] <jcoxon> but i guess the data is encrypted in the form of a jpeg
[19:23] <fsphil> tricky one that .. jpeg is well documented, and I'll need to document the TX format I'm using
[19:23] <jcoxon> i think the US licence has set formats
[19:23] <fsphil> yea, unusually they are stricter about that than here
[19:24] <fsphil> the mode itself is plain rtty, just the content that differs
[19:24] <jcoxon> thats true
[19:24] <fsphil> bandwidth might be an issue too, 300 baud is quite wide
[19:24] <jcoxon> fsphil, we should try some HF on the ground
[19:24] <fsphil> absolutely
[19:25] <fsphil> I'm doodling with some code atm to make it resistant to packet drops
[19:26] <fsphil> fill in the blanks with valid jpeg data
[19:26] <fsphil> I should make a TX window in dl-fldigi too
[19:27] <fsphil> what HF bands do you have access too?
[19:28] <jcoxon> well i've got a 817
[19:28] <jcoxon> and a longwire over my roof
[19:28] <jcoxon> so can rx
[19:28] <jcoxon> tx is not really possible as I don't have a ATU
[19:28] <fsphil> yea
[19:29] <fsphil> I've never really worked on HF, I wonder if I have enough power to get that far
[19:30] <jonsowman> hi jcoxon
[19:30] <jcoxon> fsphil, yeah i've never really done it - just don't have space for an antenna
[19:30] <jcoxon> hey jonsowman
[19:31] <jonsowman> just looking over the xmlrpc code
[19:31] <jcoxon> fsphil, still worth trying, as its in dl-fldigi we could borrow a number of people to listen in
[19:31] <jonsowman> looks reasonably straighforward
[19:31] <jcoxon> jonsowman, oh yes, all we really need is a load of buttons
[19:31] <jcoxon> the xmlrpc bit is great for interfacing
[19:36] <jcoxon> jonsowman, what should we do about getting teh rx data
[19:38] <jonsowman> you mean sending the decoded information back to the webpage?
[19:38] <jcoxon> sort of
[19:38] <jcoxon> so you've lined up the decode lines
[19:38] <jcoxon> but you've got no feed back about if you are decoding
[19:38] <jonsowman> ah yes I see
[19:39] <DanielRichman> you might have trouble rxing without an atu
[19:39] <jonsowman> fldigi spits out everything that appears in the decode window on a TCP port right?
[19:39] <DanielRichman> isn't there an rpc call to grab the contents of the text box?
[19:39] <jcoxon> yeah there is
[19:40] <DanielRichman> easier than having a persistent process listen/connect to a port
[19:40] <jonsowman> DanielRichman: good point\
[19:40] <jonsowman> would grabbing the data and displaying suffice?
[19:40] <jcoxon> yeah
[19:40] <jcoxon> i was thinking something a little more clever
[19:40] <jonsowman> go on\
[19:41] <jcoxon> why not just grab the strings
[19:41] <jcoxon> that we've decoded and parsed
[19:41] <jcoxon> yeah we are going to miss the junk data
[19:41] <DanielRichman> I think you need to be able to see the garbage
[19:41] <jcoxon> then how about an either/or
[19:41] <jonsowman> decoded as in complete checksum verified strings?
[19:42] <jcoxon> jonsowman, yeah
[19:42] <jonsowman> i think either/or
[19:42] <jonsowman> i agree with DanielRichman in that seeing garbage data can be helpful
[19:43] <jcoxon> the ajax can easily poll the rx data then?
[19:44] <jonsowman> i don't know xmlrpc that well. can the current php page get data back from fldigi?
[19:44] <jcoxon> yeah so the xmlrpc call gets a response
[19:44] <jonsowman> right so php 'knows' the returned data
[19:44] <jcoxon> so text.get_rx 0 100
[19:45] <jonsowman> ok that's fine then
[19:45] <jcoxon> would grab the first 100chars
[19:45] <jonsowman> getting the data back to the ajax frontend is trivial from there
[19:45] <jcoxon> jonsowman, yeah currently the php page gets the the carrier freq and displays it
[19:45] <jcoxon> so when you click up and down that moves
[19:46] <jonsowman> understood
[19:46] <jcoxon> $decoded_response = php_xmlrpc_decode($result->value());
[19:46] <jcoxon> the more i think about this the easier it is
[19:46] <jonsowman> so the ajax frontend is just an additional layer on top of the php layer
[19:46] <jcoxon> we could use perl if thats easier
[19:47] <jcoxon> just need an implimentation of xmlrpc
[19:47] <jonsowman> personally i prefer php as I know it better
[19:47] <jcoxon> or java
[19:48] <jcoxon> http://www.zentus.com/js/xmlrpc.js.html
[19:48] <jonsowman> i intend to write a complete implentation of the frontend in php/ajax
[19:48] <jonsowman> but that's not to say others can't do it too in whatever language they want :)
[19:48] <jcoxon> no that sounds good
[19:49] <jcoxon> what do you need me to do?
[19:49] <jonsowman> nothing at the moment :)
[19:49] <jonsowman> just work out what custom rpc things we (as in the HAB community) want to add to fldigi
[19:50] <jonsowman> and which ones out of that massive list I really need to implement
[19:50] <jcoxon> conviently there are sort of replications
[19:50] <jcoxon> such as get_afc set_afc and toggle_afc
[19:50] <jcoxon> just need to use toggle_afc
[19:51] <jonsowman> yes that helps a lot
[19:51] <DanielRichman> ok now this is interesting
[19:51] <jonsowman> do i understand correctly in saying that the XML part of xmlrpc just refers to the format in which the API expects data?
[19:51] <DanielRichman> line 532 of dl-fldigi.cxx; the problem line
[19:51] <DanielRichman> first of all we have a branch; if (result == 0)
[19:52] <jcoxon> jonsowman, yeah it passes the data in xml file
[19:52] <DanielRichman> the problem line is in the else { block so you would have thought result couldn't be zero
[19:52] <DanielRichman> yet this: fprintf(stderr, "dl_fldigi: (thread %li) curl result (%i) %p\n", pthread_self(), result, curl_easy_strerror(result));
[19:52] <jonsowman> jcoxon: right. really I think json-rpc is much better for the ajax frontend
[19:52] <DanielRichman> results in dl_fldigi: (thread 37062728) curl result (0) 0x6
[19:52] <DanielRichman> so it's clear what's causing the segfault: curl_easy_sterror returns 0x6 which clearly isn't a pointer to a string
[19:52] <jonsowman> since AJAX throws data around in JSON format it'd make sense to use json-rpc
[19:53] <DanielRichman> however I have no idea why that line gets executed when result seems to be 0
[19:53] <jonsowman> there is a PHP implementation of json-rpc but I don't know about other languages
[19:53] <DanielRichman> oh wait.... maybe.... hmm
[19:54] <fsphil> DanielRichman, doesn't windows have two versions of the standard io stuff, one thread safe and one not?
[19:54] <DanielRichman> the segfault is caused by curl_easy_strerror(0) == 0x6 which isn't a valid string pointer
[19:54] <DanielRichman> the question is why does curl_easy_sterror get called
[19:55] <DanielRichman> firstly result shouldn't equal 0 since the download should have failed with no net connection
[19:55] <DanielRichman> secondly in the else {} block result shouldn't equal 0
[19:55] <DanielRichman> CURLcode itself is an enum
[19:56] <DanielRichman> which might be a problem
[19:56] <fsphil> I modified a version to write the curl_easy_strerror output to a file, it wrote the correct message but then crashed on the fprintf(stderr that followed
[19:56] <DanielRichman> eeeh?!
[19:56] <fsphil> yea
[19:56] <fsphil> try writing to a file instead of stderr
[19:56] <DanielRichman> but check the line I copied above
[19:56] <DanielRichman> I replaced %s with %p
[19:56] <DanielRichman> so it should print the memory location that it would have dereferenced
[19:58] <jcoxon> jonsowman, http://www.thomasfrank.se/xml_to_json.html
[19:58] <jcoxon> hehe, some sort of interface between the 2?
[19:59] <jonsowman> well i was thinking just generating the RPC requests in JSON format
[19:59] <fsphil> my windows builds didn't work entirely anyway, so there could have been something else at play
[19:59] <DanielRichman> brb; killing my 'net to test again
[19:59] <jonsowman> php has a nice group of json_ functions to generate a json from an assoc. array and vice versa
[19:59] <jonsowman> makes it really nice and easy to work with
[19:59] <jcoxon> fair enough
[19:59] <jcoxon> will leave it in your hands
[20:00] <jonsowman> I will try it with json first
[20:00] <jcoxon> now all this is easy on linux/os x - how about windows...
[20:00] <jonsowman> hmm yeh
[20:00] <jcoxon> could we perhaps find a standalone http/php server binary
[20:00] <jcoxon> and use it with our scripts
[20:01] <jonsowman> or build it into dl-fldigi
[20:01] <jonsowman> have an 'enable web interface' checkbox
[20:01] <jonsowman> then http://localhost:port for the web-gui
[20:01] <jcoxon> i think thats going to result in a lot more work - this is more for particular people
[20:02] <DanielRichman> well you can bundle apache and libphp into the dl fldigi installer
[20:02] <jonsowman> yea it would be more work to build it into dl-fldigi
[20:02] <DanielRichman> or even lighty since that's smaller and easier to use
[20:02] <jonsowman> \o/ lighty
[20:03] <DanielRichman> :)
[20:03] <jonsowman> excellent webserver
[20:03] <jonsowman> though i run cherokee mostly
[20:03] <DanielRichman> :o
[20:03] <jonsowman> best configuration interface ever
[20:03] <jonsowman> uses almost no memory, super-fast
[20:04] <jonsowman> just generally good really :)
[20:04] <jcoxon> lets keep it seperate
[20:04] <jonsowman> jcoxon: agreed
[20:04] <jcoxon> if they want to setup remote control its going to take them a bit of work
[20:07] <jonsowman> yea
[20:07] <jcoxon> DanielRichman, i think one thing we need to get onto dl-fldigi --hab is rig control
[20:07] <fsphil> +1 :D
[20:07] <jonsowman> that'd be neat
[20:09] <DanielRichman> dl_fldigi: (thread 139951351650576) curl result (6) Couldn't resolve host name
[20:10] <DanielRichman> that's what it should say
[20:10] <DanielRichman> that's interesting, because the value result should be is 6
[20:10] <jonsowman> jcoxon: the frontend need not run on the same server as dl-fldigi
[20:10] <DanielRichman> yet it seems that fprintf thinks that it's the curl_easy_strerror result which is 6
[20:11] <DanielRichman> so how did th ose variables get misplaced?
[20:11] <jonsowman> we could host the frontend with a 'server/port' input box which connects over the net to the dl-fldigi machine
[20:11] <jcoxon> yes thats very true, cause fo teh xmlrpc
[20:11] <jcoxon> i've got something very special up my sleeve once we get this working
[20:11] <jonsowman> as long as firewalls and NATs are set up correctly the
[20:12] <jonsowman> n it should be fine
[20:12] <jcoxon> jonsowman, http://code.google.com/p/android-xmlrpc/
[20:12] <jcoxon> oh yes mobile control...
[20:13] <jonsowman> :D
[20:14] GW8RAK (~chatzilla@client-86-29-50-214.glfd.adsl.virginmedia.com) joined #highaltitude.
[20:15] <fsphil> can anyone with better google-foo than me find the pin descriptions for a 7333-A voltage regulator
[20:15] Upu (~Upu@ubn.upuaut.net) left irc: Ping timeout: 240 seconds
[20:17] <jonsowman> fsphil: any more text on the package?
[20:17] <DanielRichman> ok I've found the bug jcoxon
[20:17] <jonsowman> fsphil: also, what package type?
[20:17] <jcoxon> DanielRichman, oh?
[20:17] <fsphil> jonsowman, afraid not. all I can say is that it's a surface mount vreg .. three terminals on the bottom, one larger on the top
[20:18] <fsphil> I'm trying to verify the pin description is right, it's on another uart camera I found but I can't seem to get any life out of it
[20:19] <jonsowman> interesting
[20:19] <jonsowman> sounds like a weird package
[20:21] <DanielRichman> ok basically jcoxon line 532 that you commented out is indeed the problem line
[20:21] <DanielRichman> fprintf(stderr, "dl_fldigi: (thread %li) curl result (%i) %s\n", pthread_self(), result, curl_easy_strerror(result));
[20:21] <jonsowman> fsphil: http://www.westfloridacomponents.com/mm5/graphics/t073.jpg
[20:21] <jonsowman> that package?
[20:21] <DanielRichman> now when we see the crash it prints "curl result (0)" -- and then segfaults
[20:21] <DanielRichman> this is a trick!
[20:22] <DanielRichman> result is actually equal to 6, but for some reason (?) fprintf is using the result parameter for %s
[20:22] <DanielRichman> and when it tries to dereference result as if it were a pointer, it crashes
[20:22] <DanielRichman> I am not 100% sure why the variables are slipping like that yet
[20:23] <fsphil> jonsowman, not exactly .. one sec I'll show it
[20:23] <jcoxon> DanielRichman, only on windows as well
[20:23] <fsphil> jonsowman, http://www.flickr.com/photos/fsphil/4828012280/
[20:24] <fsphil> it's on the bottom left
[20:24] <DanielRichman> yup. I trust someone's tried dlfldigi on 32bit on linux and it's not the 64/32 change that's causing it?
[20:24] <fsphil> it's suppose to run of 3.3v, not sure why the regular is even there
[20:25] <jonsowman> fsphil: can you find a known GND on the board and continuity test each of the 4 terminals
[20:25] <jonsowman> that'll tell you what gnd is
[20:26] <jonsowman> i would guess at the centre tab of the three, and the large top tab, both being GND
[20:26] <fsphil> hmm, I just noticed the + and - terminals at the bottom of the board
[20:26] <jonsowman> yeh that's what I was looking at
[20:26] <jonsowman> that would indicate the left of the three on that image being Vin
[20:26] <jcoxon> DanielRichman, i haven't
[20:27] <jcoxon> actually i have!
[20:27] <jcoxon> my linux box is 32bit
[20:27] <fsphil> left pin is gnd
[20:27] <DanielRichman> and does it work w/o net?
[20:27] <jonsowman> fsphil: oo
[20:27] <fsphil> top and middle pin are fout
[20:27] <fsphil> hmm
[20:27] <fsphil> or vin
[20:28] <fsphil> yes, vin
[20:28] <jcoxon> DanielRichman, can't remember - sorry - i've deconstructed my box now
[20:28] <DanielRichman> d/w
[20:29] <fsphil> i've got a feeling they've sent me the 5v version
[20:29] <jonsowman> ah
[20:31] <fsphil> ah but there's no serial driver .. the 5v version has proper serial
[20:32] <jonsowman> serial? on a vreg?
[20:32] <fsphil> the camera itself
[20:33] <jonsowman> oh right I see, sorry
[20:33] <jonsowman> sorry off topic but where did you get the c328 from?
[20:33] <fsphil> the original one from sparkfun, but they're sold out - these from cool components
[20:33] <jonsowman> thanks
[20:33] <fsphil> and they're running out
[20:33] <jcoxon> activerobots is where i got mine from
[20:33] <jonsowman> going to get hold of one before they disappear completely from the face of the earth
[20:34] <fsphil> yea the main chip was discontinued a while back
[20:34] <jonsowman> so i heard. better get one soon hadn't it :)
[20:34] <fsphil> anyone here good with fpga? make a replacement ;-)
[20:34] <jonsowman> I think this is something Randomskk was looking into
[20:35] <jonsowman> a while back
[20:40] <jonsowman> hmm might get an mbed whilst im at it
[20:44] GW8RAK (~chatzilla@client-86-29-50-214.glfd.adsl.virginmedia.com) left irc: Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]
[20:44] <DanielRichman> I think I might not use one of those; just get one of the camera modules
[20:44] <DanielRichman> Don't they have i2c interfaces?
[20:45] <DanielRichman> that might be nicer to use than a uart since you can pause anything half way through if you're outputting slowly
[20:46] <fsphil> that would be ideal
[20:46] <fsphil> this version has a habit of going to sleep if left too long
[20:47] <jonsowman> fsphil: that version of the camera you mean?
[20:49] <fsphil> the one I got from sparkfun
[20:49] <jonsowman> ah right :)
[20:49] <fsphil> the other ones likely do the same, if I could get them working anyway :)
[20:52] <fsphil> tha vreg is putting out 2.87v
[20:53] <jonsowman> :\
[20:53] <DanielRichman> is it meant to?
[20:53] <jonsowman> DanielRichman: 3v3
[20:54] <DanielRichman> well I know that fsphil mentioned that you're mention to supply it with 3v3 (?)
[20:54] <fsphil> yes
[20:54] <jonsowman> oh yea
[20:54] <DanielRichman> but don't you get some ~2.8 chips?
[20:54] <jonsowman> that is true
[20:54] <jonsowman> i think 2v7
[20:54] <jonsowman> 1v8 is also a standard
[20:55] <DanielRichman> can you id the vreg?
[20:55] <jonsowman> DanielRichman: we were trying to
[20:55] <jonsowman> it has 7333-A on it and nothing else
[20:55] <fsphil> DanielRichman, http://www.flickr.com/photos/fsphil/4828012280/
[20:55] <jonsowman> http://www.flickr.com/photos/fsphil/4828012280/
[20:55] <jonsowman> bottom left
[20:55] <jonsowman> oh haha
[20:55] <jonsowman> sorry fsphil
[20:56] <fsphil> no worries :)
[20:56] <DanielRichman> hmm you *could* increase the vin and see if it's the dropout that's causing that 2.8 and it's meant to be supplied with 5v or if it's actually a 2.7 vreg
[20:56] <DanielRichman> but that might be bad.
[20:56] <fsphil> there is a 5v model, but it does proper serial level voltages on the tx/rx lines. this board has no serial driver
[20:57] <DanielRichman> does the vin go anywhere other than the vreg?
[21:00] <fsphil> doesn't seem to .. goes through a diode, then the vreg
[21:00] <fsphil> bit difficult to follow though
[21:01] <jonsowman> diode... hmm
[21:01] <jonsowman> diode = 0.6V voltage drop roughly
[21:01] <jonsowman> 3v3 - 0v6 = 2v7
[21:02] <jonsowman> is the diode between power terminal and reg's Vin?
[21:03] <fsphil> looks like it, one sec I'll flip it over
[21:03] <jonsowman> that would make sense and it prevent reverse polarity destroying the reg
[21:04] <jonsowman> which it definitely does
[21:04] <jonsowman> but that would imply that you need to give the board >3V3
[21:04] <jonsowman> which surely can't be true
[21:04] <jonsowman> :\
[21:06] <fsphil> it would help if they wrote the model somewhere !
[21:07] <jonsowman> yes it would :(
[21:07] <fsphil> this isn't a terribly good photo: http://www.flickr.com/photos/fsphil/4828156864/
[21:08] <fsphil> on the four soldered pins on the right, the bottom is 3.3v and gnd is the one above it
[21:09] <fsphil> I'm assuming that D1 "000" is a diode
[21:09] <jonsowman> i would assume so
[21:09] <jonsowman> a quick multimetering would confirm :)
[21:10] <fsphil> metering as we speak :)
[21:11] DrLuke (~luke@pD9E39686.dip.t-dialin.net) joined #highaltitude.
[21:11] <fsphil> right, it goes through D1, seems to be connected to both the copper pads to the left .. and the other smaller "000" diode
[21:12] <fsphil> and the blob of solder above that
[21:12] <fsphil> also U1 .. whatever that may be
[21:13] <jonsowman> no idea what U1 might be
[21:13] <jonsowman> any text on it? can't see in that photo
[21:14] <fsphil> very small text, yea -- I can take a better one
[21:17] <jonsowman> just wondering if that might shed any light on whats going on with the 2.87v issue
[21:18] <fsphil> http://www.flickr.com/photos/fsphil/4828190246/
[21:18] <fsphil> "5KID"?
[21:19] <jonsowman> do the manufacturers of the ICs on this thing have something against printing useful information on them?
[21:19] <fsphil> lol
[21:20] <fsphil> it appears the smaller "000" has three tracks coming from it?
[21:20] <jonsowman> :\
[21:20] <fsphil> actually looking at it now, they're the same size
[21:20] <fsphil> the other just has more solder
[21:20] <fsphil> this board is weird
[21:20] <jonsowman> very
[21:23] <fsphil> I'm going to have to email them, see if they can tell me how to identify it. they should be able to compare two there
[21:27] <jonsowman> yea
[21:27] <jonsowman> the whole 2v8 thing out is odd
[21:28] <DanielRichman> ok 32bit seems to be fine
[21:28] <DanielRichman> so it's the windows that's causing it
[21:29] <DanielRichman> perhaps an odditiy of the the x compiler; maybe the differences in pthread on win32 and linux
[21:29] gamers600 (~gamers600@ip68-99-230-95.ph.ph.cox.net) joined #highaltitude.
[21:32] <fsphil> DanielRichman, I read about the -mthread flag for gcc on windows for linking against the thread-safe windows libraries. I didn't get anywhere with it, kept telling me it was an unknown option
[21:32] <DanielRichman> the problem is this variable passing to fprintf
[21:33] <DanielRichman> which I'm pretty sure is part of mingw
[21:38] Jasperw (~jasperw@212-98-44-230.static.adslpremium.ch) left irc: Quit: Leaving.
[21:39] LazyLeopard (~irc-clien@chocky.demon.co.uk) joined #highaltitude.
[21:42] gamers600 (~gamers600@ip68-99-230-95.ph.ph.cox.net) left irc: Quit: gamers600
[21:45] Upu (~Upu@ubn.upuaut.net) joined #highaltitude.
[22:00] <DanielRichman> oh I know why it is
[22:00] <DanielRichman> on linux pthread_t is essentially an int
[22:00] <DanielRichman> on windows (ptw32) it's a struct containing a pointer and an integer (!?)
[22:00] <DanielRichman> which is shunting all the arguments one to the right since fprintf expects a long int
[22:01] <DanielRichman> great success -.-'
[22:01] <DanielRichman> jcoxon: ok I've found the sauce of the problem
[22:02] <LazyLeopard> ...but is it HP?
[22:02] Action: LazyLeopard ducks.
[22:02] Action: DanielRichman swings
[22:05] <DanielRichman> http://gist.github.com/489883
[22:05] <jonsowman> :D
[22:11] <fsphil> lol
[22:12] <fsphil> so here's a question .. why did it work when I fprintf'ed to a file
[22:22] <DanielRichman> did you include the pthread_self() bit?
[22:23] <DanielRichman> and use the same windows libraries?
[22:26] <fsphil> yea
[22:27] <fsphil> ah wait, no
[22:27] <fsphil> found the code, I just printed the curl error
[22:27] <fsphil> msg = curl_easy_strerror(result);
[22:27] <fsphil> fprintf(f, "Message: %s\n", msg);
[22:27] Action: fsphil slaps self
[22:37] <jcoxon> DanielRichman, good work!
[22:37] <DanielRichman> Unless there are any objections the fix involves an #ifdef MINGW32
[22:37] <jcoxon> nah
[22:37] <jcoxon> no problems
[22:43] <fsphil> well caught
[22:43] <fsphil> was the compiler putting out any warnings about it?
[22:47] <DanielRichman> well the compiler complained that it expected %li but got pthread_t
[22:47] <DanielRichman> however I ignored it (/slap self) because I thought that was the difference between 32 and 64 bit
[22:47] <DanielRichman> I need to tidy up most of the fprintf things in there. I think there is a gnice way to do it across 32 and 64 bit
[22:47] <DanielRichman> with fprintf int sizes
[22:47] <DanielRichman> I'll google and roll it into the same fix
[22:49] <DanielRichman> ping jcoxon
[22:49] <DanielRichman> -#!/usr/bin/perl
[22:49] <DanielRichman> +#!/opt/local/bin/perl
[22:49] <DanielRichman> http://github.com/jamescoxon/dl-fldigi/commit/73dce4074b64a2c85aed00c9ede28bd23d2e47ad
[22:49] <DanielRichman> ?
[22:50] <jcoxon> hehe oh yeah
[22:50] <jcoxon> i have mutiple versions of perl
[22:51] <DanielRichman> :o mind if I revert that?
[22:51] <jcoxon> that was for the xmlrpc-php thingy
[22:51] <jcoxon> yeah
[22:53] Action: jcoxon needs DanielRichman to keep an eye on his code
[22:56] <DanielRichman> yeah btw jcoxon you accidentally removed fsphil's ssdv options from the conf dialog
[22:56] <DanielRichman> that was on my todo list for a while: fsphil (admonish) modified the cxx directly rather than using fluid
[22:56] <DanielRichman> so the fl never contained those items
[22:56] <fsphil> I fixed that not long ago DanielRichman
[22:56] <DanielRichman> :O
[22:56] <DanielRichman> really?
[22:57] <fsphil> yea, the tab should be in the .fl file now -- it's only one text box though, I took most of it out
[22:57] <DanielRichman> aah right sorry
[22:57] <jcoxon> hehe
[22:57] <DanielRichman> I saw the lines removed in one of the commits while catching up and jumped to a conclusion
[22:57] <DanielRichman> :P
[22:57] <jcoxon> no worries
[22:57] <jcoxon> its the sort of thing i'd do
[22:59] DaveyC (IceChat7@188-221-51-13.zone12.bethere.co.uk) left #highaltitude.
[23:01] <fsphil> is there any point keeping the 'detect and extract' checkbox?
[23:04] <DanielRichman> I don't think so, no
[23:05] <DanielRichman> we have the online checkbox instead
[23:05] <jonsowman> fsphil: I was wondering the other day if that checkbox did anything
[23:07] <fsphil> it's not used outside the conf dialog -- I'll snip it out now but it's gonna leave that enable tab awful empty
[23:07] <jonsowman> you could replace it with another Online checkbox
[23:07] <jonsowman> so that Online can be switched from that tab or from the dl menu
[23:07] <jonsowman> bit pointless I realise
[23:07] <jonsowman> fills spaces though :)
[23:08] <fsphil> or put the text box for the upload url
[23:08] <fsphil> and the payload xml
[23:09] <fsphil> although there's little need to ever change them, and doing so could cause problems :)
[23:09] <jonsowman> i think the upload url should be a configurable option
[23:09] <jonsowman> though a "Use default" button would be worthwhile
[23:10] <jcoxon> jonsowman, thats coming - soon
[23:10] <jcoxon> once we work out a few more things
[23:10] <jonsowman> jcoxon: right :)
[23:10] <fsphil> hehe, what the enable + detect checkbox does: fprintf(stderr, "dl_fldigi: TODO Detection and Extraction toggle box\n");
[23:10] Upu_ (~Upu@ubn.upuaut.net) joined #highaltitude.
[23:10] <jonsowman> haha
[23:10] <jonsowman> nice
[23:10] <jonsowman> :D
[23:11] <jonsowman> well at least it does /something/
[23:11] <fsphil> it's the thought that counts
[23:11] <jonsowman> absolutely
[23:12] <fsphil> I wish my version of fluid didn't keep changing things it shouldn't -- is there any way for me to have git take only certain changes?
[23:13] <jonsowman> what is fluid changing that it shouldnt?
[23:14] <fsphil> it's removing the casting for colours, eg.:
[23:14] <fsphil> - inpMyName->labelcolor((Fl_Color)FL_FOREGROUND_COLOR);
[23:14] <fsphil> + inpMyName->labelcolor(FL_FOREGROUND_COLOR);
[23:14] <jonsowman> weird
[23:14] <jonsowman> hmm I don't know how to make git ignore that
[23:15] <jonsowman> though that's really solving the symptom rather than the cause
[23:15] <fsphil> yea it's going to keep happening
[23:19] <fsphil> seems to be an older version of fluid than what created or last edited the file
[23:23] Upu (~Upu@ubn.upuaut.net) left irc:
[23:23] Upu_ (~Upu@ubn.upuaut.net) left irc:
[23:30] <fsphil> okie, bed time. night all!
[23:30] fsphil (~phil@beastie.sanslogic.co.uk) left irc: Quit: zzzzzzzzzz
[23:30] Action: jcoxon is in cambridge tomorrow - anyone around?
[23:31] DrLuke (~luke@pD9E39686.dip.t-dialin.net) left irc:
[23:48] <jcoxon> just looking at hte ARHAB records
[23:49] <jcoxon> as a group UKHAS has the 58 launches which would put us 3rd in the overal launch list
[23:49] <jcoxon> that said its missing quite a few people
[00:00] --- Mon Jul 26 2010