highaltitude.log.20090216

[00:22] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-5e1469c58e62438b) joined #highaltitude.
[00:24] <Laurenceb> http://www.youtube.com/watch?v=NMShvQa4SI0
[00:32] <SpeedEvil> :)
[00:33] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[00:45] <Laurenceb> whats best for gluing wood to polyurethane foam? gorilla glue or epoxy?
[00:47] <SpeedEvil> By PU, you mean kingspan-like stuff?
[00:47] <SpeedEvil> Hmm.
[00:47] <Laurenceb> yeah
[00:48] <SpeedEvil> I'd try both.
[00:48] <Laurenceb> think I'll go for gorilla as it'll be a bit lighter
[00:48] <SpeedEvil> The foam is very weak
[00:48] <Laurenceb> this is pretty strong
[00:48] <SpeedEvil> I mean in tension, compared to usual glues
[00:48] <Laurenceb> - its blue foam
[00:49] <SpeedEvil> oh - that stuff
[00:49] <SpeedEvil> Isn't that polystyrene?
[00:49] <Laurenceb> dont think so
[00:49] <Laurenceb> everyone calls it polystyrene
[00:49] <Laurenceb> bu I'm not sure it is
[00:50] <SpeedEvil> PS varies quite a bit depending on how much it's blown, and any plasticisers that are added.
[00:51] <SpeedEvil> I think the easiest way to differentiate is probably solvent resistance
[00:53] <Laurenceb> its made by DOW
[00:54] <Laurenceb> but on their site they mension polyisocyanurate
[00:56] <Laurenceb> but all the modelling sites say the dow stuff is polystyrene
[00:56] <Laurenceb> but I've ordered polyisocyanurate foam from gyproc and its pink.... the same sites claim the pink foam is polystyrene
[00:58] <SpeedEvil> Burn it on a hot flame. If you die, it contains cyanide.
[00:58] <Laurenceb> not true
[00:58] <Laurenceb> the whole point is fire resistance
[00:59] <Laurenceb> thats why I has to use it - building regs required it
[01:01] <SpeedEvil> Random sort-of-connected question. What was the film involving massive quantities of expanding foam in tunnels/caves underground?
[01:02] <Laurenceb> as in a documentary?
[01:02] <SpeedEvil> no
[01:02] <SpeedEvil> http://en.wikipedia.org/wiki/On_Hostile_Ground_(2000_film)
[01:02] <SpeedEvil> ah
[01:04] <Laurenceb> they use rapid setting foam it nuclear warhead transport containers
[01:04] <Laurenceb> IIRC its poyurethane with a catalyst
[01:05] <Laurenceb> open the canister when your not supposed to and the whole area becomes a big plastic blob
[01:06] <SpeedEvil> I know there is foam used inside the warhead for isothermalising reasons.
[01:06] <Laurenceb> sure, I meant as an antitheft device
[01:06] <SpeedEvil> To form a hot plasma under pressure of x-rays, to compress the spark plug for the fusion reactoin.
[01:09] <Laurenceb> wonder if you could use the same device of cars
[01:11] <Laurenceb> just hack out the chavs after they've suffocated
[01:31] <natrium42> Laurenceb, so is it ok?
[01:31] <Laurenceb> wut?
[01:31] <Laurenceb> dont follow sorry
[01:31] <natrium42> [18:20] <natrium42> it's ok if the PCB is thinner than the usual, right?
[01:31] <natrium42> [18:20] <natrium42> my main project needs 0.6 mm thin pcb
[01:31] <natrium42> [18:20] <natrium42> and it's going to be gold plated
[01:31] <Laurenceb> oh
[01:31] <Laurenceb> no the transmission line will be off
[01:32] <Laurenceb> just a sec
[01:32] <natrium42> ok, do you need to know the exact thickness?
[01:32] <Laurenceb> yeah, please
[01:32] <Laurenceb> and permittivity
[01:32] <Laurenceb> if you have it, but its usually 4.5
[01:35] <natrium42> hmm
[01:36] <Laurenceb> its a lot thinner
[01:36] <natrium42> "2layers 0.024", FR4 1oz GOLD"
[01:36] <Laurenceb> http://chemandy.com/calculators/microstrip-transmission-line-calculator-hartley27.htm
[01:36] <Laurenceb> ok FR4 is ~4.2 to 4.6
[01:36] <Laurenceb> 1oz gold... theres copper underneath right?
[01:37] <natrium42> yeah, it's gold plated
[01:37] <natrium42> looks like some engrish
[01:37] <Laurenceb> right
[01:37] <natrium42> 1oz copper probably
[01:37] <Laurenceb> hmm ok guess I'd better fire up eagle and take a look
[01:37] <natrium42> k
[01:37] <Laurenceb> I'll try and be fast
[01:37] <natrium42> it's fine, i am going to stay up late
[01:37] <natrium42> very late :)
[01:38] <Laurenceb> this is good as there appeared to be some RFI issues before
[01:38] <Laurenceb> and now I'll have more room for shielding
[01:38] <natrium42> why?
[01:39] <Laurenceb> smaller line
[01:39] <natrium42> aah, cool
[01:40] <Laurenceb> how do I switch to metric?
[01:40] Action: Laurenceb has forgotten how to use eagle
[01:40] <natrium42> View -> Grid...
[01:40] <natrium42> then select mm
[01:40] <Laurenceb> ta
[01:40] <natrium42> np
[01:41] <Laurenceb> is the gold plating on pads only?
[01:42] <natrium42> every exposed copper surface
[01:42] <natrium42> pads, vias, etc
[01:42] <Laurenceb> yeah ok
[01:45] <Laurenceb> hmm the sma connectors I'm using arent designed for 0.61mm board
[01:45] <Laurenceb> guess it'll be ok... but the pad design wont quite be the same as the datasheet
[01:46] <natrium42> sorry :P
[01:46] <Laurenceb> its cool
[01:46] <natrium42> pcb is going to be much lighter, though
[01:46] <Laurenceb> I cant see why it'll be a huge problem, the datasheet is considering ~10GHz or so
[01:46] <Laurenceb> 434MHz shouldnt mind 1mm or so of off spec trace
[01:47] <Laurenceb> I'll just use extra solder to fill in the gaps
[01:48] <natrium42> can't you add a matching coil if there's a problem?
[01:51] <Laurenceb> well its a 50 ohm line to a 50ohm sma
[01:52] <Laurenceb> but the sma is for thicker board, and the reference pad layout is for thewider transmission line
[01:52] <natrium42> it should be no problem
[01:53] <natrium42> short runs of higher resistance don't have much effect
[01:54] <natrium42> for example the gps chip i am using has not enough space between the pads for a 50 ohm line
[01:54] <shellevil> What's the total distance at 434?
[01:54] <natrium42> so i had to wedge it in
[01:55] <shellevil> very small fraction of a wave.
[01:57] <Laurenceb> yeah
[01:58] <Laurenceb> I've got a bent track, and I want to split it
[01:58] <Laurenceb> but when I use the split tool, the track below the split point goes straight
[01:58] <Laurenceb> I want to keep the track below the split in its origional position, then adjust above the split point
[01:59] <Laurenceb> any ideas?
[02:00] <natrium42> split it twice, then restore the position of that track
[02:00] <natrium42> bbl food
[02:03] <Laurenceb> ok I think I've worked out my problem
[02:03] <Laurenceb> the bend tool uses a constant radius
[02:40] <natrium42> back
[02:40] <Laurenceb> ok finished
[02:42] <Laurenceb> emailed
[02:53] <natrium42> nice, got it
[03:10] <Laurenceb> all ok?
[03:11] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[03:52] <Laurenceb> [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
[03:54] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-5e1469c58e62438b) left irc: "http://www.mibbit.com ajax IRC Client"
[04:34] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) left irc: Read error: 113 (No route to host)
[07:12] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[07:59] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[08:06] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[08:06] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: Read error: 104 (Connection reset by peer)
[08:07] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[08:38] Laurenceb (i=83e34f19@gateway/web/ajax/mibbit.com/x-d291405573019da3) joined #highaltitude.
[08:38] <Laurenceb> hello
[08:38] Nick change: Laurenceb -> Laurenceb|wurk
[08:40] <natrium42> elloh
[08:40] <Laurenceb|wurk> still up?
[08:40] <natrium42> yep
[08:40] <Laurenceb|wurk> how goes the pcb design?
[08:40] <natrium42> not going to get done tonight :P
[08:40] <natrium42> meh, tomorrow is fine
[08:41] <Laurenceb|wurk> any chance you could do one with a 0.1'' header?
[08:41] <Laurenceb|wurk> - for the gps
[08:41] <natrium42> hmm, sure
[08:41] <natrium42> if i don't forget
[08:42] <Laurenceb|wurk> the gps has two serial ports?
[08:43] <natrium42> 1xUART and 1xSPI
[08:43] <Laurenceb|wurk> ok
[08:43] <natrium42> but the SPI is only for logging
[08:43] <Laurenceb|wurk> right
[08:43] <Laurenceb|wurk> so you config over the UART?
[08:43] <natrium42> you can, yes
[08:44] <Laurenceb|wurk> the binary command pdf says nothing about position data
[08:44] <natrium42> i have two sarantel gps helix antennas lying around
[08:44] <Laurenceb|wurk> I'm a bit confused... so it can only give NMEA output?
[08:44] <natrium42> might make a pcb with them
[08:44] <Laurenceb|wurk> omg
[08:45] <Laurenceb|wurk> have you made an eagle part for it?
[08:45] <natrium42> yeah, i didn't find anything to read position using binary protocol
[08:45] <natrium42> it only seems to be for config
[08:45] <Laurenceb|wurk> yeah, that sucks
[08:46] <Laurenceb|wurk> NMEA is stupid for embedded work
[08:46] <natrium42> i remember making a 3d model of it, dunno about eagle part
[08:46] <natrium42> it's just 3 pads :)
[08:46] <Laurenceb|wurk> no the gps chipset
[08:47] <Laurenceb|wurk> did you make an eagle part for it?
[08:48] <natrium42> yep
[08:49] <Laurenceb|wurk> neat
[08:52] <Laurenceb|wurk> where did you get the sarantel antennas from?
[08:54] <natrium42> http://www.jdgastore.com
[08:54] <natrium42> (they really suck at web design)
[08:57] <Laurenceb|wurk> or... https://samples.sarantel.com/
[08:57] <natrium42> nice :)
[08:58] <Laurenceb|wurk> Wellingborough UK
[08:58] <Laurenceb|wurk> should be fast delivery :D
[09:00] <Laurenceb|wurk> hmm ok... can I ask a big favour? any chance you could stick the sarantel geohelix onto a board with 0.1'' header?
[09:00] <Laurenceb|wurk> I'll get the antenna
[09:00] <Laurenceb|wurk> I'll also see if I can get you one too while I'm at it :P
[09:01] <natrium42> with the gps chip?
[09:01] <Laurenceb|wurk> yeah
[09:02] <natrium42> ok, sure
[09:02] <Laurenceb|wurk> thanks :D
[09:03] <natrium42> do they include their connector thingy?
[09:03] <natrium42> or is it better to solder the antenna directly to pcb?
[09:04] <natrium42> hmm, pad layout is the same for either option
[09:04] <Laurenceb|wurk> https://samples.sarantel.com/downloads/SL1300%20Product%20Spec_v2_09-08.pdf
[09:04] <natrium42> so it's fine then
[09:04] <natrium42> yeah, looking at it
[09:04] <natrium42> i have a few of those connectors
[09:04] <Laurenceb|wurk> looks like through hole
[09:04] <natrium42> but their purpose seems to be only to simplify machine assembly
[09:04] <Laurenceb|wurk> or surface with a connector
[09:05] <Laurenceb|wurk> yeah
[09:05] <Laurenceb|wurk> you could surface mount it without the connector
[09:05] <natrium42> how about soldering the antenna onto the edge?
[09:05] <natrium42> it's ok?
[09:05] Action: natrium42 thinks this is the best way
[09:05] <Laurenceb|wurk> yeah that looks fine
[09:05] <Laurenceb|wurk> that connector looks like its just to simplify assembly
[09:06] <natrium42> yep
[09:06] <natrium42> i should get some sleep
[09:06] <natrium42> g'nite
[09:06] <Laurenceb|wurk> the three pins are inline and presumable are impedance matched to 50 ohm
[09:06] <Laurenceb|wurk> cya, thanks
[09:06] <natrium42> sure thing
[09:09] <Laurenceb|wurk> ooh one more thing, battery backup is important
[09:09] <Laurenceb|wurk> didnt see it on your board
[09:11] <natrium42> i have it connected to vcc
[09:12] <Laurenceb|wurk> hmm as soon as the NDS is turned off you lose ephemeris
[09:12] <Laurenceb|wurk> its going to increase TTFF
[09:12] <Laurenceb|wurk> by several minutes Id guess
[09:12] <natrium42> meh
[09:13] <natrium42> technically i could get it using binary protocol
[09:13] <Laurenceb|wurk> lassen iq takes 14 minutes but it should be a bit faster
[09:13] <Laurenceb|wurk> hmm I'd at least add a pad
[09:13] <natrium42> 14 minutes? wtf
[09:13] <Laurenceb|wurk> yes
[09:13] <Laurenceb|wurk> all the specs are for ephermeris
[09:13] <natrium42> mine has never taken that long, weird
[09:14] <Laurenceb|wurk> with no ephemeris or RTC, you have to search all the sats and get valid nav data
[09:14] <Laurenceb|wurk> well usually its less
[09:14] <Laurenceb|wurk> but >10 most of the time
[09:14] <Laurenceb|wurk> with ephemeris its less than a minute
[09:15] <natrium42> Laurenceb|wurk, "Cold start 29 seconds average"
[09:15] <Laurenceb|wurk> yeah cold start
[09:15] <Laurenceb|wurk> !=start with no ephemeris
[09:15] <natrium42> eh? maybe you mean warm start?
[09:15] <Laurenceb|wurk> cold start the tracking loops have to be reinitialised
[09:16] <Laurenceb|wurk> no
[09:16] <Laurenceb|wurk> cold start location and time unknown
[09:17] <natrium42> hmm
[09:17] <Laurenceb|wurk> warm the tracking loops have to be restarted (I think) but time and pos is roughly known
[09:17] <Laurenceb|wurk> hot your just getting the tracking loops back onto the signal properly
[09:18] <Laurenceb|wurk> we're talking about a start from scratch, with time=0 and no ephemeris or positrion
[09:18] <Laurenceb|wurk> they never give that in the datasheet
[09:18] <Laurenceb|wurk> as you always back up, and consumer stuff has that done at the factory
[09:19] <Laurenceb|wurk> the module on the aerosol project has some sort of bug, and goes to the factor in tiawan sometimes when it boots
[09:19] <natrium42> haha
[09:22] <Laurenceb|wurk> looking at the specs I'd guess 4 minutes with no ephermeris
[09:27] <Laurenceb|wurk> theres an example of using a rechargeble lithium cell int eh datasheet
[09:28] <natrium42> yeah, hmm
[09:28] <natrium42> i may add it then
[09:28] <natrium42> at least for the proto
[09:29] <Laurenceb|wurk> its nice to have a fast lock from power on
[09:40] Action: natrium42 Zzzz
[09:41] <Laurenceb|wurk> http://www.timeanddate.com/worldclock/city.html?n=1203
[10:03] Action: Laurenceb|wurk contemplates packet radio
[10:03] <Laurenceb|wurk> arg too many modes
[10:47] rjharrison (n=rharriso@gateway.hgf.com) joined #highaltitude.
[11:19] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[11:56] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[12:13] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[12:33] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) left irc: Read error: 60 (Operation timed out)
[13:08] borism (n=boris@195-50-197-158-dsl.krw.estpak.ee) left irc: Read error: 145 (Connection timed out)
[13:20] <Laurenceb|wurk> http://bigredbee.com/BeeLineGPS.htm
[13:40] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[13:45] <Laurenceb|wurk> hi ed seen this? http://bigredbee.com/BeeLineGPS.htm
[13:46] <edmoore> nope, but looks cool
[13:46] <edmoore> a bit like what badger cub will look like
[13:46] <Laurenceb|wurk> yeah I think we want to move to packet
[13:46] <Laurenceb|wurk> screw dominoex and all that
[13:46] <edmoore> i'm not sure we have the power for reliable 1200bps packet. but I base that on very little
[13:46] <edmoore> but sure, if we could, then yes
[13:47] <Laurenceb|wurk> well there 300bps packet
[13:47] <edmoore> i mean i'd want to actually transmit on aprs freqs so we can take advantage of the pre-existing network, which is better than most people think
[13:47] <Laurenceb|wurk> and it'll be faster and more reliable than rtty
[13:47] <Laurenceb|wurk> yeah
[13:47] <Laurenceb|wurk> but its 144MHz
[13:47] <edmoore> right, i have a lecture, then I'm going underground for a day or two
[13:47] <Laurenceb|wurk> cya
[13:48] Action: Laurenceb|wurk looks up pactor2
[13:48] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[13:50] <Laurenceb|wurk> annoyingly it needs ARQ
[15:09] borism (n=boris@195-50-197-158-dsl.krw.estpak.ee) joined #highaltitude.
[15:10] edmoore (n=edmoore@pomegranate.chu.cam.ac.uk) joined #highaltitude.
[15:27] <Laurenceb|wurk> hi edmoore
[15:27] <edmoore> hi
[15:27] <Laurenceb|wurk> I cant find any linux software for receiving packet
[15:27] <Laurenceb|wurk> but AX25 looks very cool
[15:29] <Laurenceb|wurk> http://garydion.com/projects/whereavr/
[15:32] <edmoore> it's a nice protocol
[15:33] <edmoore> anyhoo, as i said, I'm going to head underground for a bit. buzz is super important
[15:33] Nick change: edmoore -> edmoore|busy
[16:21] rjharrison (n=rharriso@gateway.hgf.com) left irc:
[16:26] mc- (n=mfcastle@cpc3-glfd1-0-0-cust439.glfd.cable.ntl.com) joined #highaltitude.
[16:46] <Laurenceb|wurk> hi mc-
[16:53] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[17:00] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[17:04] <mc-> hi Laurence
[17:07] <jcoxon> hey Laurenceb|wurk, just looking at the logs, you know that AX25 is built into the linux kernel, you can use soundmodem for example
[17:07] <jcoxon> but i've found that truetty in wine does the job much better (pegasus VI can do 300baud packet
[17:07] <jcoxon> )
[17:09] <jcoxon> hey mc-
[17:09] <jcoxon> hows things?
[17:12] <Laurenceb|wurk> hi jcoxon
[17:12] <Laurenceb|wurk> yeah, but soundmodem is a bit poor
[17:12] <Laurenceb|wurk> really need some form of frequency tracking
[17:12] <mc-> hi jcoxon, haven't managed to do much HABing recently
[17:13] <mc-> Laurenceb, had a quick question on Domino
[17:13] <Laurenceb|wurk> yeah
[17:13] <mc-> I can't work out why it's 18 tones, when it doesn't repeat the tones which are -1,0,+1?
[17:13] <mc-> I think it's 19 tones
[17:14] <Laurenceb|wurk> its designed so theres never repeating tones
[17:14] <Laurenceb|wurk> so the dll works better
[17:14] <mc-> there's 16 tones + 3 tones, so it doesn't repeat.
[17:15] <Laurenceb|wurk> 16+3!=18
[17:16] <Laurenceb|wurk> the idea is you never have one tone equal to the previous tone or the prev tone +-1
[17:16] <Laurenceb|wurk> hang on thats 15...
[17:16] Action: Laurenceb|wurk doesnt get it
[17:17] <jcoxon> hehe
[17:18] <jcoxon> Laurenceb|wurk, yeah soundmodem is pretty rubbish, there are some micro based decoders but i'm not sure how good they are - truetty does the job pretty well
[17:18] <mc-> I emailed the domino designer about this, but he didn't reply
[17:18] <Laurenceb|wurk> yeah, I was thinking some C code is hardly tricky
[17:18] <Laurenceb|wurk> especially on linux
[17:19] <Laurenceb|wurk> could make a basic AX25 APRS type receiver
[17:19] <jcoxon> Laurenceb|wurk, well rocketboy has code to generate Ax25 packets
[17:19] <jcoxon> in C that is
[17:19] <Laurenceb|wurk> i.e. no ARQ or networking
[17:19] <Laurenceb|wurk> ah cool
[17:19] <jcoxon> runs nicely on the gumstix
[17:19] <mc-> why do you say "hang on thats 15..."
[17:19] <Laurenceb|wurk> well theres already an AVR TNC
[17:20] <Laurenceb|wurk> 18-3=15
[17:20] <jcoxon> hmmm wiki is down but i think some of its on there
[17:20] <mc-> ah ok
[17:20] <Laurenceb|wurk> and you cant have prev tone +-1 or 0
[17:20] <mc-> did you find some source code for domino?
[17:20] <Laurenceb|wurk> no, wrote it myself
[17:20] <Laurenceb|wurk> its on the wiki
[17:20] <mc-> so do you get 19 tones then?
[17:21] <Laurenceb|wurk> no
[17:21] <Laurenceb|wurk> at least not it my code....
[17:21] <mc-> so you only have 15 possible symbols?
[17:21] <Laurenceb|wurk> no thats not right... I dont think
[17:22] <mc-> perhaps only +1,0 tones are not transmitted on the next symbol?
[17:23] <Laurenceb|wurk> yeah
[17:23] <mc-> that doesn't make sense to me though
[17:23] <Laurenceb|wurk> http://www.qsl.net/zl1bpu/DOMINO/Technical.htm
[17:26] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "This computer has gone to sleep"
[17:27] <mc-> yes, I was reading that, it says adjacent tones aren't repeated
[17:29] <Laurenceb|wurk> x+15+2==x+17
[17:29] <Laurenceb|wurk> which in mod 18 will be adjacent
[17:30] <mc-> exactly, I'll try and email ZL1BPU again
[17:33] <Laurenceb|wurk> yeah there 54 cases of 15 in the varicode
[17:51] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[17:57] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) left irc: Read error: 113 (No route to host)
[18:29] <Laurenceb|wurk> cya all
[18:30] Laurenceb|wurk (i=83e34f19@gateway/web/ajax/mibbit.com/x-d291405573019da3) left irc: "http://www.mibbit.com ajax IRC Client"
[18:50] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[18:56] i_am_ed (n=ed@93-97-218-30.zone5.bethere.co.uk) left irc: Remote closed the connection
[19:04] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[19:27] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-87fa7af8b06cd725) joined #highaltitude.
[19:27] <Laurenceb> hello
[20:05] rjharrison_ (n=rharriso@80.176.172.227) joined #highaltitude.
[20:16] Xenion (n=robert@p579FC9CA.dip.t-dialin.net) joined #highaltitude.
[20:16] <Xenion> Guten Abend / Good evening :-)
[20:34] mc- (n=mfcastle@cpc3-glfd1-0-0-cust439.glfd.cable.ntl.com) left irc:
[20:38] edmoore|busy (n=edmoore@pomegranate.chu.cam.ac.uk) left irc:
[20:41] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[20:44] <Laurenceb> hi Steve
[20:45] <Laurenceb> I'm interested in getting 300 baud packet working... any ideas?
[20:46] <Laurenceb> is there any decent software for linux?
[20:46] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[21:03] <rjharrison_> RocketBoy u on hf yet
[21:03] <rjharrison_> 40m
[21:10] <RocketBoy> rjharrison_: nope - the TX doesn't seem to want to load up the random bit of wire I'm using on any of the HF bands
[21:10] <RocketBoy> I need to finish the ATU I'm making
[21:12] <rjharrison_> Ok let me know when you are done
[21:12] <RocketBoy> Laurenceb: nope I don't know of any Linux (or windows) source in the public domain for packet
[21:12] <rjharrison_> In a couple of days
[21:12] <Laurenceb> its annoying
[21:13] <Laurenceb> guess I'll try writing some code
[21:14] <RocketBoy> Laurenceb: HF packet (300 Baud) is exactly the same as VHF packet (1200 baud) - except the speed and that HF uses SSB and VHF uses FM
[21:14] <Laurenceb> yeah
[21:14] <Laurenceb> I really want to run that with frequency tracking
[21:15] <Laurenceb> then maybe AX25 packets similar to APRS, but with FEC
[21:15] <Laurenceb> probably reed solomon
[21:15] <Laurenceb> shouldnt be too hard to do, mostly c&p
[21:16] <Laurenceb> AX25 looks much better than RTTY for noise tolerance and sync overhead
[21:17] <Laurenceb> just an occasional stuffing bit
[21:18] <RocketBoy> On the down side most of the software seems to only output vaid packets - so the CRC seems to have to match
[21:18] <Laurenceb> yeah
[21:18] <RocketBoy> so packets with the odd bit of corruption don't come out
[21:18] <Laurenceb> I think a bit of reed solomon would help
[21:18] <Laurenceb> but it runs at byte level?
[21:18] <Laurenceb> so thats not as efficient?
[21:20] <RocketBoy> yeah theres lots that could be done - don't forget you need to detect run in and byte framing - so that needs to be part of the framing
[21:21] <Laurenceb> yeah thats covered by AX25
[21:22] <RocketBoy> I don't see any point in using AX25 to carry a RS code - it won't get through as the CRC wont give you a valid frame to RS decode
[21:22] <Laurenceb> 0x7E at the start and end, and a 16 bit checksum
[21:22] <Laurenceb> sure, I'll write the code from scratch
[21:23] <RocketBoy> humm its not AX25 then
[21:23] <Laurenceb> yeah
[21:23] <Laurenceb> AX25 based
[21:23] <RocketBoy> sort of AX25 without the AX25 then?
[21:23] <RocketBoy> lets call it LB25
[21:23] <Laurenceb> well it could work as AX25 if theres no errors
[21:24] <Laurenceb> i.e. there reed solomon parity data as part of the payload
[21:24] <RocketBoy> there is already a proposed standard for a turbo code alternative to AX25 somewhere
[21:25] <Laurenceb> interestingn
[21:25] <Laurenceb> how hard is turbo code encoding?
[21:25] <Laurenceb> - could it run on a micro?
[21:27] <RocketBoy> I had a look at it - its didin't seem that complicated - data seems arranged in a 2 dimensional matrix and then correction bytes sent for each row and column
[21:27] <RocketBoy> so yes looked miroable
[21:27] <Laurenceb> interesting
[21:27] <Laurenceb> I see
[21:27] <Laurenceb> oh I'll be ready to launch the mini rogallo soon
[21:27] <RocketBoy> but it didn't seem suited to shortish mesages (<200 bytes or so)
[21:28] <Laurenceb> ok
[21:28] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[21:31] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[22:03] <RocketBoy> FT817 owners: any way to get it to transmit a tone (for tune of antennas) while on USB/LSB?
[22:04] <jcoxon> oh i'm not sure
[22:04] <jcoxon> i'll look in the manual for you
[22:04] <RocketBoy> I have had a quick scan - cant find it
[22:05] <jcoxon> RocketBoy, do you have an antenna setup?
[22:05] <jcoxon> rob and I are playing on 40m right now
[22:07] <RocketBoy> What freq?
[22:07] <jcoxon> ummm -> 99
[22:22] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-87fa7af8b06cd725) left irc: "http://www.mibbit.com ajax IRC Client"
[22:34] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-058603f1cad35171) joined #highaltitude.
[22:35] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-058603f1cad35171) left #highaltitude.
[22:35] Laurenceb (i=83e3dd23@gateway/web/ajax/mibbit.com/x-058603f1cad35171) joined #highaltitude.
[23:01] josepharmbruster (n=josephar@45.144.119.70.cfl.res.rr.com) joined #highaltitude.
[23:03] <Laurenceb> anyone launching soon?
[23:09] <rjharrison_> I'm waiting on the weather
[23:10] rjharrison_ (n=rharriso@80.176.172.227) left irc:
[23:11] Xenion (n=robert@p579FC9CA.dip.t-dialin.net) left irc: "Verlassend"
[23:20] <Laurenceb> hmm this is what I'm thinking - 300bps 200Hz shift transmission, with 0x7E at either end of a packet and the AX25 bit stuffing technique
[23:21] <Laurenceb> then the data consists of 255,223 reed solomon
[23:21] <Laurenceb> not very optimal FEC but it'll be a lot better than RTTY
[23:26] <RocketBoy> define lot
[23:26] <Laurenceb> no sync pulses
[23:26] <Laurenceb> you can get 300bps 100% of the time
[23:26] <RocketBoy> at what range with what power
[23:27] <RocketBoy> better what is the coding gain over RTTY
[23:27] <Laurenceb> also you have virtually guarenteed data integrity if it gets through the decoder ok
[23:27] <Laurenceb> I meant as in % of time sending data
[23:27] <Laurenceb> there will be a coding gain, but its not huge
[23:28] <Laurenceb> the main advantage is no false starts
[23:28] <fergusnoble> Laurenceb: how do you frame it?
[23:28] <Laurenceb> same as AX25
[23:29] <Laurenceb> 0x7E at either end
[23:29] <Laurenceb> 0 is defined as modulator bit flip
[23:29] <Laurenceb> 1 is no modulator flip
[23:29] <Laurenceb> 5 consecutive 1s are padded with a 0
[23:29] <fergusnoble> why is that better than rtty framing?
[23:30] <Laurenceb> RTTY framing can get "thrown off"
[23:30] <Laurenceb> by some noise, and take some time to recover
[23:30] <Laurenceb> this is more robust to that problem
[23:30] <Laurenceb> also there less overhead from start/stop bits
[23:31] <fergusnoble> so if the 7E gets naffed then you lose the whole packet?
[23:31] <Laurenceb> well you could try and sniff out a packet
[23:31] <Laurenceb> or use the fact that you have 0x7E7E
[23:31] <Laurenceb> between each packet
[23:32] <fergusnoble> ok i see
[23:32] <Laurenceb> so you'd have to lose both
[23:33] <Laurenceb> you could go hardcore and have a reed solomon decoder rolling along the bitstream
[23:33] <fergusnoble> well, i dont see that it makes much difference, maybe only in that with lots of noise rtty will let some chars through but the AX25 thing will drop whole packets
[23:33] <Laurenceb> yeah, but your packets are full of nonsense
[23:34] <Laurenceb> reed solomon has the added advantage it can tell you if it worked
[23:34] <Laurenceb> you can be pretty sure your data is correct
[23:34] <fergusnoble> sure, but you could do RS over RTTY or any other lower level ecoding
[23:35] <Laurenceb> yeah
[23:35] <fergusnoble> it would be cool to try RS
[23:35] <fergusnoble> or RA codes
[23:36] <Laurenceb> theres code on the wiki
[23:36] <Laurenceb> its pretty cool to watch it in action
[23:36] <fergusnoble> i bet
[23:36] <RocketBoy> did U guys see the thing I put up on the wiki about shannon?
[23:36] <fergusnoble> did you write it? have you tried it on a flight?
[23:36] <fergusnoble> RocketBoy: yeah, the calculator is really cool too
[23:36] <Laurenceb> I wrote it, and its running on the aerosol project
[23:37] <fergusnoble> Laurenceb: awesome
[23:37] <Laurenceb> RocketBoy: yeah its really useful
[23:37] <RocketBoy> methinks that there is only 10dB (coding gain) to be had over what we already achived with RTTY
[23:38] <fergusnoble> oh thats interesting
[23:38] <Laurenceb> guess it depends on the decoder, but RTTY seems vulnerable to bits slipping
[23:38] <fergusnoble> does using a wider bandwidth like MFSK allow for more gain or is that still subject to that limit?
[23:39] <Laurenceb> fldigi seems to handle it quite well and put all the data transitions through a DLL
[23:40] <Laurenceb> but it still has the start/stop bit overhead, and has fewer transitions than AX25 style modulation
[23:40] <RocketBoy> well its an bandwidth/speed/coding scheme trade off - but shannons limit is the laws of physics - cant be improved on
[23:40] <Laurenceb> wider bandwidth giver lower signal/noise but higher theoretic bps
[23:40] <fergusnoble> Laurenceb: if you add a couple of bytes of 0x55 to the start of your rtty packets that will help the dll lock
[23:41] <Laurenceb> hmm neat plan
[23:41] <Laurenceb> do you still need the tune up pulse?
[23:41] <fergusnoble> as in a gap between packets?
[23:41] <fergusnoble> on badger the rtty goes continuously without gaps
[23:42] <Laurenceb> yes, with 00000000000000000011111111111111111111
[23:42] <Laurenceb> ok interesting
[23:42] <Laurenceb> but its 50 baud
[23:42] <fergusnoble> yeah
[23:42] <fergusnoble> the decoder shouldnt need a special pulse to get it going
[23:42] <Laurenceb> hmf guess its time for me to play with eliminating tuneup and sticking in some 0x55
[23:43] <Laurenceb> how many did you use?
[23:43] <fergusnoble> havnt tried the 0x55, just thought of it
[23:43] <Laurenceb> oh ok
[23:43] <Laurenceb> dont you find you get a little bit of corruption and about 30 characters are all screwed?
[23:44] <fergusnoble> oh when you first tune in? maybe
[23:44] <Laurenceb> no all the time
[23:44] <fergusnoble> nope
[23:44] <Laurenceb> as the dll is thrown off
[23:44] <Laurenceb> thats been my problem with rtty
[23:44] <RocketBoy> Its a little surprising you get a sync loss with rtty
[23:44] <fergusnoble> maybe that because we dont have gaps between packets
[23:45] <Laurenceb> maybe its this machine :-/
[23:45] <fergusnoble> so the the bits are all in phase, the dll never needs to relock
[23:45] <RocketBoy> the odd character loss yes - but sync is all about timing loss
[23:45] <Laurenceb> oh I managed to fine tune the sound sampling clock and its only 200ppm off by the looks of it
[23:46] <Laurenceb> so my idea it was the clock goes out of the window
[23:46] <Laurenceb> yeah RTTY only works if you set the sound card clock offset to -17000ppm
[23:46] <RocketBoy> I guess if the start or stop bit is lost then its gonna search for a new start
[23:47] <Laurenceb> yeah
[23:47] <RocketBoy> yuch
[23:47] <RocketBoy> -17000ppm = 1.7%
[23:47] <Laurenceb> I dont get it... its not the uC crystal as dominoex timing is fine
[23:47] <fergusnoble> how does soundcard clock error make so much difference?
[23:48] <Laurenceb> it adjusts the baud rate
[23:48] <RocketBoy> ?????
[23:48] <Laurenceb> effectively
[23:48] <fergusnoble> but the dll should be able to track it seeing as the difference is quite small right?
[23:48] <Laurenceb> fldigi uses the number of bytes (or u16 ..) read from the sound card to create a time basis
[23:49] <Laurenceb> yeah, but its cant track a 1.7% error
[23:49] <Laurenceb> you see the text go corrupted then ~30 characters later its ok and so on in bands
[23:49] <fergusnoble> i see
[23:50] <fergusnoble> have you tried any other decoders?
[23:50] <Laurenceb> no
[23:50] <RocketBoy> not seen that happen on TrueTTY
[23:50] <Laurenceb> my icom doesnt want to work with xp
[23:50] <fergusnoble> i mean, the badger rtty baud rate isnt that tightly controlled because its relying on the OS scheduler
[23:50] <Laurenceb> interesting
[23:51] <fergusnoble> i would have thought it could sometimes be out by a percent or so
[23:51] <RocketBoy> actually putting a bit more stop is helpful to sync
[23:51] <fergusnoble> im not really sure though
[23:51] <Laurenceb> http://wiki.ukhas.org.uk/_media/code:v2radio.zip?id=code%3Aradio&cache=cache
[23:51] <Laurenceb> thats what I'm running, F_CPU=12000000
[23:51] <RocketBoy> so as long as you can output a character OK then waiting between charcters should be fine
[23:53] <Laurenceb> maybe I just made a mistake somewhere....
[23:53] <fergusnoble> Laurenceb: have you tried seeing what happens to fldigi if you set it to an incorrect but close baud
[23:54] <fergusnoble> like if you tell it to expect 50.1 does that change anything?
[23:54] <fergusnoble> you could also see if the the frequency of going into and out of good decoding corresponds to the clock error
[23:54] <fergusnoble> work out what the beat frequency should be
[23:55] <Laurenceb> its 300 baud
[23:56] RocketBoy (n=Steve@217.47.75.27) left #highaltitude.
[23:56] <Laurenceb> idea is 12000000 crystal, timer over flow every 200 cycles, every 200 overflows a new bit is loaded
[23:56] <Laurenceb> -> 300
[23:57] <fergusnoble> cool
[23:57] <fergusnoble> why not set the timer to 40000?
[23:57] <Laurenceb> that meant the timer overflow register=199 right?
[23:57] <Laurenceb> pwm would be too slow
[23:58] <fergusnoble> ah ok, didnt realise you were using pwm
[23:58] <fergusnoble> Laurenceb: i guess so
[23:58] <Laurenceb> yeah... cant see anything wrong
[23:59] <Laurenceb> apart from... its using pulse shaping
[23:59] <fergusnoble> i always make off by 1 errors myself, im bad at knowing what is the right way
[23:59] <Laurenceb> maybe fldigi doesnt like that
[23:59] <fergusnoble> does it work without the pulse shaping?
[23:59] <Laurenceb> havent tried
[00:00] --- Tue Feb 17 2009