highaltitude.log.20081209

[00:48] Jirotka (i=Jirotka@f048195167.adsl.alicedsl.de) left irc:
[01:15] jiffe88 (n=jiffe2@209.159.198.87) joined #highaltitude.
[02:45] akawaka (n=akawaka@external.treyarch.com) left irc: Read error: 110 (Connection timed out)
[02:46] natrium42 (n=alexei@CPE000625d867e2-CM0014045885be.cpe.net.cable.rogers.com) left irc:
[03:37] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[06:19] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) left irc: Read error: 110 (Connection timed out)
[06:32] akawaka (n=akawaka@66.215.97.198) joined #highaltitude.
[08:01] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[08:09] Simon-MPFH (n=simon@phantom.mpfh.co.uk) joined #highaltitude.
[08:27] akawaka (n=akawaka@66.215.97.198) left irc: Read error: 110 (Connection timed out)
[09:09] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[09:46] mib_e60y7p (i=1851b777@gateway/web/ajax/mibbit.com/x-3b8f6dbb80924e14) joined #highaltitude.
[09:46] mib_e60y7p (i=1851b777@gateway/web/ajax/mibbit.com/x-3b8f6dbb80924e14) left irc: Client Quit
[09:48] bluenarf (n=Miranda@apollo.paulsnet.org) joined #highaltitude.
[09:57] rjharrison_ (n=rharriso@gateway.hgf.com) joined #highaltitude.
[09:57] <rjharrison_> Hi james
[09:57] <rjharrison_> any rtty experts out there?
[09:58] <rjharrison_> I have baudaut code working beautifully
[09:58] <rjharrison_> Well working
[10:01] <bluenarf> ohai
[10:02] <rjharrison_> last
[10:02] <rjharrison_> !last
[10:06] <jcoxon> morning
[10:07] <jcoxon> grrrrrr
[10:07] <jcoxon> i've managed to repair my home button on my ipod touch
[10:07] <jcoxon> but at the loss of wifi
[10:13] Jirotka (i=Jirotka@f048190053.adsl.alicedsl.de) joined #highaltitude.
[10:20] bluenarf (n=Miranda@apollo.paulsnet.org) left irc: Remote closed the connection
[10:35] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[10:35] <rjharrison_> edmoore U have 5
[10:35] <edmoore> dodgy wifi connection but fire away
[10:36] <rjharrison_> jcoxon ARSE that is bad news in the ipod
[10:36] <rjharrison_> edmoore I have rtty working :) but only in baudaut code
[10:36] <edmoore> awesome :)
[10:36] <rjharrison_> Do you know how to send ascii assuming I'm nearly there
[10:36] <edmoore> changed your mind then?
[10:36] <edmoore> yes - although i'm not sure how helpful my answer will be
[10:37] <rjharrison_> Well I want to do a test of both fo speed and accuracy
[10:37] <edmoore> basically, I presume you have some lookup table for baudot
[10:37] <rjharrison_> So there is going to be a test launch soon possibly with your input of a new multimode beacon
[10:37] <rjharrison_> No I just send 1's and 0's in the correct order
[10:38] <rjharrison_> It only sends ICARUS at the moment. Hardcoded baudot ATM
[10:38] <edmoore> and how do you know what the correct order is?
[10:39] <rjharrison_> Well I send 1 sec of 1's followed by 0 <BAUDAUT CODE> then a 1, 0 <BAUDAUT CODE> then a 1 ...
[10:39] <rjharrison_> U can use two 1's as the stop ie a one for two time periods
[10:40] <rjharrison_> Does that make sense
[10:41] <rjharrison_> Now I'm not sure what I'm doing wrong I just replace the baudot code for ascii leaving the stop and start bits in place and set the mode to ascii8 but no joy
[10:41] <rjharrison_> Obv sending 8 instead of 5 bits
[10:42] <rjharrison_> or 10 instead of 7 I'm only sending one stop bit now as it seems to work. Though I have tried both.
[10:43] <edmoore> ok
[10:44] <edmoore> let me try and find you our code
[10:44] <edmoore> one sec
[10:44] <edmoore> can you pm me your email addy?
[10:47] <jcoxon> rjharrison_, indeed it is - but not having the home button was really annoying as you can't do anything
[10:47] <jcoxon> now i can jailbreak it and also but the linux demo on it
[10:47] <jcoxon> but not having wifi is a big loss
[10:47] <edmoore> sent
[10:47] <rjharrison_> Did that get damaged as part of the repair process
[10:48] <edmoore> jcoxon: have you bought an iphone?
[10:48] <jcoxon> edmoore, i've got an old 2nd hand faulty ipod touch
[10:48] <jcoxon> rjharrison_, i suspect so
[10:48] <jcoxon> its little in there
[10:49] <rjharrison_> I'll bet. You were brave just opening it
[10:49] <rjharrison_> What did you need to do to fix it?
[10:50] <jcoxon> basically the button contacts had slipped so when you pressed the button it didn't make a connection
[10:50] <jcoxon> had to take everything out, reposition the button plastic but
[10:50] <jcoxon> bit*
[10:50] <jcoxon> but at some point wifi must of got upset
[10:50] <edmoore> so next project - building a tracking antenna control box into a pelican case
[10:50] <edmoore> pan/tilt motor control
[10:50] <edmoore> small computer with network connection
[10:51] <edmoore> gps
[10:51] <jcoxon> :-)
[10:52] <rjharrison_> Right guys Had fun with rtty last night. If I want to get a smoother transtion shod I vary the voltage rather than just switch between the two?
[10:52] <rjharrison_> should
[10:53] <rjharrison_> Whould that be cleaner and I guess I would need a DAC to do it
[10:53] <jcoxon> rjharrison_, yeah, thats called pulse shaping
[10:53] <jcoxon> a DAC would do it very well
[10:53] <jcoxon> PWM could be made to do it as well
[10:54] <rjharrison_> Ok I think I understand rtty a whole lot more now having played with it
[10:54] <rjharrison_> I'll try to out a quick paper to gether for others to follow
[10:55] <rjharrison_> s/to/to put
[10:55] <jcoxon> okay
[10:55] <rjharrison_> Crap I can't type English :)
[10:56] <jcoxon> at least my ipod still functions as an ipod :-p
[10:56] <rjharrison_> I'll have a play with PWM and a DAC and see how good I can get the RTTY looking on truetty
[10:57] <rjharrison_> Should be a good winter project.
[10:57] <jcoxon> hehe
[10:57] <jcoxon> i want to launch, but just don't have time
[10:57] <rjharrison_> I'm hoping to have the basic beacon available soon rather than a badger. Based on atmega8
[10:58] <rjharrison_> This is going for budget and I may even get a few boards printed.
[10:58] <rjharrison_> Choice of morse or rtty. Might be good as a backup
[10:59] <rjharrison_> Trying to keep total cost at under 60 quid. Including TX GPS antenna and power
[11:02] <edmoore> pulse shaping is a worthy investment of time
[11:04] <rjharrison_> One last any ideas on the number of bits the DAC will need to be nice
[11:04] <rjharrison_> I guess more bives you a better resolution in voltage jumps
[11:04] <rjharrison_> gives
[11:05] <edmoore> probably 4 bit would be fine
[11:05] <edmoore> 4 bit with a lowpass filter
[11:05] <rjharrison_> Humm where did that filter come from?
[11:05] <rjharrison_> Is that an addition or part of the dac>
[11:05] <edmoore> my head
[11:05] <edmoore> so you have an output that looks like steps
[11:06] <rjharrison_> Yep
[11:06] <edmoore> a sine wave but made up of discrete steps
[11:06] <rjharrison_> Yep
[11:06] <rjharrison_> And can you buy a low pass filter
[11:06] <edmoore> each of the steps will still cause a tiny bit of harmonic ringing
[11:06] <edmoore> a lowpass filter is a capacitor and resistor
[11:06] <rjharrison_> Yep I think I have discoverd harmonics last night
[11:07] <rjharrison_> Looking at my shaky waterfall
[11:07] <edmoore> if you have a waterfall plot, the harmioics will manifest themselves as spreading on the pulse
[11:07] <gordonjcp> rjharrison_: what kind of signal are you trying to generate?
[11:07] <rjharrison_> rtty
[11:07] <edmoore> so instead of being an infinitely thin line, it will spread out a bit at the ends
[11:08] <gordonjcp> rjharrison_: I wouldn't bother too much about the waveform you generate then
[11:08] <edmoore> anyway, a low pass filter will knock out all thos little high freq components on each of the steps
[11:08] <rjharrison_> Oh ok I thought it was the jumpy bits on the screen. Not like two pointed tits more drunken mounds,
[11:08] <rjharrison_> If that makes technical sense
[11:09] <edmoore> that's a spectrum plot rather than a waterfall
[11:09] <edmoore> but yes, the tightness of the peaks is the same idea
[11:10] <rjharrison_> If they look neat and tidy I'm guessing that the signal will be better.
[11:11] <edmoore> yes - its easier to extract them from noise
[11:11] <rjharrison_> Could I tidy up the current situation with a low pass filter with out the dac
[11:11] <edmoore> you'd loose a bit too much energy I think
[11:11] <edmoore> it will absorb some energy of the pulses
[11:11] <edmoore> much better to do it 'properly' with a dac and then just smooth up the remaining edges
[11:12] <edmoore> with a LPF
[11:13] <rjharrison_> I did shove a 100nf cap in last night in series just befor the tx line but nothing came out. A random ideas. With a larger cap the signal began to fade as the cap charged. Blind electroic gamble there
[11:13] <rjharrison_> Will do DAC will be ordered from fanell
[11:13] <rjharrison_> Farnell
[11:13] <rjharrison_> Can stretch to 6 bits so i'll see if there is one there
[11:14] <edmoore> rjharrison_: re caps
[11:14] <rjharrison_> Yep
[11:14] <edmoore> resitance of a cap is 1/(j*2*pi*freq*C)
[11:14] <edmoore> so as the freq increases, the resistance decreses
[11:14] <rjharrison_> Ok
[11:14] <rjharrison_> I'll read up a bit on that
[11:15] <edmoore> so as your freq increases, the resistance across the cap will appear to descrease
[11:15] <edmoore> it's often called 'decoupling'
[11:15] <edmoore> because it removes the (0 hertz) DC component
[11:16] <edmoore> j is the imaginary number
[11:16] <rjharrison_> Ahh another familiar word that I had no idea what it ment
[11:16] <edmoore> so technically it's the impedance of the cap rather than the resistence of thye cap
[11:17] <rjharrison_> Ok cool. I'm drowning here in lack of knowledge. Is it quite simple to select a cap and res for the LPF
[11:18] <edmoore> yes
[11:18] <edmoore> so... there are various kinds of LPF
[11:18] <edmoore> you will come across words like 'bessel' and 'butterworth'
[11:18] <rjharrison_> Go for the very simple kind ?
[11:19] <edmoore> essentailly, an 'ideal' filter has a cutoff frequency of 'x' and lets through every up to 'x' unattenuated, and cuts off completely anything with a frequency greater than x
[11:19] <rjharrison_> Ok that makes sense
[11:19] <edmoore> in practice, that's impossible to achive with analog electronics
[11:20] <rjharrison_> So the best effort is ...
[11:20] <edmoore> http://en.wikipedia.org/wiki/Low-pass_filter
[11:20] <edmoore> beneath the graph
[11:20] <edmoore> a first order RC filter
[11:21] <edmoore> that graph shows you waht you more typically get - a sloping line of cutoff, instead of a knife edge
[11:21] <rjharrison_> I need that scope
[11:21] <edmoore> and filters are usually rated by their '3dB cutoff' - the frequency at which the input frequency is attenuated by half
[11:21] <rjharrison_> Col
[11:21] <rjharrison_> Cool
[11:21] <edmoore> 3dB = x2
[11:22] <rjharrison_> That 3db comes back to me from 2e0 course
[11:22] <edmoore> be aware though, there are much better ways of doing it that aren't that much more complex
[11:22] <rjharrison_> Ok and are they html'd
[11:23] <edmoore> http://en.wikipedia.org/wiki/Butterworth_filter
[11:23] <edmoore> take a look at the graph in the transfer function section
[11:23] <edmoore> you can see that the number of poles you add - the 'order' - makes your filter tend towards the 'ideal'
[11:23] <edmoore> ie a much tighter cut-off
[11:23] <edmoore> so the 5th order performs much better than the 1st order
[11:24] <edmoore> rads per sec is just fequency
[11:24] <edmoore> w = 2*pi*freq
[11:24] <rjharrison_> wow, so long as I can ignore the polynomial math I think I could do that
[11:24] <rjharrison_> May have top play a bit with the R and C values
[11:26] <rjharrison_> Edmore thanks for another lesson in electronic hopefully I will be the faithfull student and produce a result based on this :0
[11:26] <rjharrison_> :D even
[11:28] <edmoore> :)
[11:29] <edmoore> if you want a good and happy life, get yourself dspguide.com
[11:29] <edmoore> read the stuff on fourier transforms
[11:29] <edmoore> and then laplace transforms (they build on fourier)
[11:29] <edmoore> if you can actually make it thrugh that, you're into proper degree level maths
[11:29] <rjharrison_> Ok Will do
[11:29] <edmoore> *but* everything on the page will make sense
[11:29] <edmoore> transfer functions and the like
[11:30] <rjharrison_> Bolox to that I did one course with the math department in Leeds Uni and never again
[11:30] <rjharrison_> All on number theory
[11:30] <edmoore> what was it on?
[11:30] <edmoore> oh right, well that's about the least useful one you could have done :p
[11:30] <rjharrison_> Yep
[11:31] <rjharrison_> With loads of proofs on integers, fractions, imaginary numbers etc..
[11:32] <rjharrison_> i^2 = -1 is about all I remember
[11:33] <edmoore> well that's everywhere in electronics so that's ok
[11:34] <edmoore> normally they use j instead of i
[11:36] <rjharrison_> Ok i'll see how long I can avoid them for :) Best get on with some work.
[11:36] <edmoore> god luck
[11:58] <edmoore> ok, so the search begins for a downconverter for 868
[11:58] <edmoore> i think that's the happy solution to the problem
[12:28] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) left irc:
[12:28] mc- (n=mfcastle@cpc1-glfd1-0-0-cust487.glfd.cable.ntl.com) joined #highaltitude.
[12:30] <mc-> morning rjharrison_ , are you ordering from Farnell sometime? I wanted a bag of grommets, that's all.
[12:31] <jcoxon> hey mc-
[12:32] <mc-> hey jc, how's it going?
[12:34] <jcoxon> not bad thanks
[12:34] <jcoxon> just working on an essay
[12:36] <mc-> don't blame me if I'm distracting you.... I've got a solar balloon, it looks good.
[12:36] <mc-> it should be able to lift my superlight payload
[12:37] Laurenceb (i=zeusbot@lister.antycip.co.uk) joined #highaltitude.
[12:37] <Laurenceb> hi guys
[12:38] <jcoxon> mc-, haha - i'm easily distracted
[12:43] <Laurenceb> cya I'm off
[12:43] Laurenceb (i=zeusbot@lister.antycip.co.uk) left irc: "leaving"
[12:59] mc- (n=mfcastle@cpc1-glfd1-0-0-cust487.glfd.cable.ntl.com) left irc:
[13:03] Jirotka (i=Jirotka@f048190053.adsl.alicedsl.de) left irc: Read error: 113 (No route to host)
[13:05] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) joined #highaltitude.
[13:06] edmoore (n=edmoore@chu-gw.churchillcambridge.co.uk) left irc: Client Quit
[13:21] Jirotka (i=Jirotka@f048220230.adsl.alicedsl.de) joined #highaltitude.
[13:26] EI5GTB (n=Paul@apollo.paulsnet.org) left irc: Remote closed the connection
[15:09] <jcoxon> rjharrison_, oooo a new beta version of CwGet has been released
[15:11] jiffe98 (n=jiffe@209.159.198.87) joined #highaltitude.
[16:20] Bluenarf (n=Paul@apollo.paulsnet.org) joined #highaltitude.
[16:20] Nick change: Bluenarf -> EI5GTB
[17:12] akawaka (n=akawaka@66.215.97.198) joined #highaltitude.
[17:12] Jirotka (i=Jirotka@f048220230.adsl.alicedsl.de) left irc: Read error: 110 (Connection timed out)
[17:13] rjharrison_ (n=rharriso@gateway.hgf.com) left irc:
[17:15] edmoore (n=edmoore@88-212-167-121.rdns.as8401.net) joined #highaltitude.
[17:42] Hiena (n=Hiena@81.93.195.181.datatrans.hu) joined #highaltitude.
[17:48] <edmoore> hi jcoxon
[17:49] <jcoxon> hey edmoore
[17:51] <jcoxon> hows tricks
[17:59] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[18:14] akawaka (n=akawaka@66.215.97.198) left irc: Read error: 110 (Connection timed out)
[18:39] <Hiena> Hey, anybody want me to help in some network analisys?
[18:40] <Hiena> Open the following link and wait until the browser downloads the 1MB page, at the end it will show the average upload speed: http://www.toons.hu/hidden
[18:54] rjharrison (n=rharriso@80.176.172.227) joined #highaltitude.
[18:54] <rjharrison> Hi edmoore
[18:56] <rjharrison> Can I post a pic of trutty and get you to have a quick look at the waveform and see what you think?
[19:01] <rjharrison> http://www.robertharrison.org/images/icarus/rtty/truetty-icarus.jpg
[19:02] <rjharrison> edmoore just going to play jak and daxter with kids back in 30 mins
[19:04] edmoore_ (n=edmoore@88-212-167-121.rdns.as8401.net) joined #highaltitude.
[19:10] edmoore (n=edmoore@88-212-167-121.rdns.as8401.net) left irc: Connection timed out
[19:31] <jnd> Hiena: 3 to 4 times slower than packets going back from 128kb/s stream
[19:32] <jnd> thats the size ratio, packet ratio is only 1.5 times lower
[19:32] <edmoore_> the one thing uni teaches you...
[19:32] <edmoore_> is just how crap tv really is
[19:32] akawaka (n=akawaka@external.treyarch.com) joined #highaltitude.
[19:32] <edmoore_> I've just got home, and turned the tv on, and there's nothing but utter bollocks on today
[19:32] <jnd> edmoore_: I knew that before :p
[19:33] <Hiena> Jnd, it's okay. I set the MTU to 1/3th due the notorious lags and packet losses.
[19:33] <edmoore_> well, I don't have tv at uni so whilst i'm there it seems I forget how crap it is
[19:33] <jnd> Hiena: Total time elapsed:340second Average speed:3.01176470588kB/s
[19:33] <Hiena> Well, that is the problem...
[19:34] <edmoore_> 10nb/s resolution :)
[19:34] <jnd> interesting that iptraf showed me only 6 to 9kb/s of raw outgoing packets
[19:35] <jnd> oh its kb, not kB
[19:36] <jnd> now the stream answers only sends about 3.5kb/s
[19:36] <Hiena> My provider promised 128KB/s speed limit. The problem is it's in peaks not constant. There is ugly 3-10 second lags, and huge 30-50% packet losts.
[19:37] <Hiena> They says it could be due the CRC erros, and change my network card or cable. But it's a bull, because i already changed the card two times.
[19:38] <Hiena> The iptraf shows only 363 error packet from 2292784 sent packet.
[19:39] <Hiena> Now i'll change the cable, and see the results.
[19:39] <jnd> my provider often promises higher and higher speeds but if you read the "rules" you find its only under very limited conditions, like it even can happen you once reach it
[19:39] <Hiena> Actually if i have a low speed connection, it's not a problem, what annoys me the lags.
[19:39] <jnd> luckily the lower variants works fine
[19:40] <Hiena> I can't test a video feed codes with 3-7 sec drops.
[19:40] fergusnoble (n=fergusno@fn217.quns.cam.ac.uk) joined #highaltitude.
[19:40] <jnd> I have serious lags when browsing pages, not every time, maybe its dns, I don't know exactly
[19:41] <Hiena> Also the variable packet size ping thest showed, they drop ratio increase with the sent bytes. Over 1024 byte it has over 40% packet loss.
[19:42] <jnd> like 5s for google sometimes when you haven't visited it recently
[19:43] <jnd> maybe bad router, I set dns proxy there
[19:45] <rjharrison> Yo edmoore_
[19:45] <rjharrison> I was speaking wih your alterego earlier edmoore
[19:45] <jnd> Hiena: try ping my ip 84.42.157.200
[19:46] <rjharrison> edmore if you have a sec have a look at http://www.robertharrison.org/images/icarus/rtty/truetty-icarus.jpg
[19:47] <rjharrison> That is the wave form i'm generating with quite a large shift between the peeks
[19:47] <rjharrison> ping fergusnoble
[19:47] <fergusnoble> hello
[19:47] <rjharrison> Quick question on ascii rtty
[19:47] <fergusnoble> shoot
[19:48] <rjharrison> I have baudot working beautifully
[19:48] <fergusnoble> awesome
[19:48] <rjharrison> 0 <baudot code> 1 0 <baudot code> 1 0 <baudot code> 1 0 <baudot code> 1
[19:48] <rjharrison> Like that
[19:48] <jnd> Hiena: wrong data byte #12 should be 0xc but was 0xa, I see the bad packets from you
[19:49] <fergusnoble> rjharrison: what do you mean?
[19:49] <rjharrison> now I want to send ascii8 and I thought it would be 0 <ascii8 > 1 0 <ascii8 > 1 0 <ascii8 > 1 0 <ascii8 > 1 0 <ascii8 > 1 but this don't work
[19:49] <rjharrison> Any idres where I'm going wrong
[19:49] <rjharrison> befor I check you code
[19:49] <rjharrison> your
[19:49] <fergusnoble> are the 0s and 1s the start and stop bits?
[19:51] <rjharrison> Yep
[19:51] <rjharrison> sorry had to wipe a bum the joys of parenthood
[19:51] <rjharrison> I tried extending the stop bit to two time periods but no joy
[19:52] <fergusnoble> RTTY usually requires 1.5 stop bits
[19:53] <rjharrison> Your joking. I thought I could use 1 1.5 or 2
[19:53] <fergusnoble> ok, have to go for dinner, bbiab
[19:53] <rjharrison> Arse if that's it
[19:53] <gordonjcp> it's better to make the stop bit longer than you need
[19:53] <rjharrison> Thanks
[19:53] <gordonjcp> bear in mind that the stop bit is the line returning to idle
[19:53] <rjharrison> gordonjcp any hints does that look good to you?
[19:53] <fergusnoble> erm, im not sure, it depends on what your decoder is expecting and im not sure about truetty, havnt used it for a while
[19:53] <rjharrison> Yep
[19:54] <fergusnoble> i think it can be configured to do either, not sure
[19:54] <gordonjcp> fergusnoble: the stop bit time is the *minimum* time in idle
[19:54] <fergusnoble> but iirc 1.5 is standard for rtty
[19:54] <gordonjcp> it can be as long as you like
[19:54] <fergusnoble> gordonjcp: yep, sure as the line idles high
[19:54] <gordonjcp> otherwise how would you tell the difference between an "invalid" stop bit length and someone typing slowly
[19:55] <fergusnoble> so its odd it didnt work when you were using a stop bit of two
[19:55] <gordonjcp> rjharrison: that looks basically okay, but you *are* sending the bits in the right order?
[19:55] <fergusnoble> but could e a quirk in the decoder, i dont know, have a go with 1.5 and ill be back in a bit
[19:56] <rjharrison> Have a nice dinner
[19:56] <rjharrison> MSB first?
[19:57] <rjharrison> I assumed most sig bit first
[19:58] <gordonjcp> iirc it's lsb first
[19:58] <fergusnoble> i thought it was lsb first, let me check my code
[19:59] <fergusnoble> yup, im doing lsb first
[19:59] <fergusnoble> http://fergusnoble.co.uk/~fergusnoble/Radio.c
[20:02] <fergusnoble> the code is a bit verbose, doesnt really need a separate transition function, but was written like that so i can add pulse shaping later
[20:04] <jnd> 1000 packets transmitted, 986 received, 1% packet loss, time 1002541ms, rtt min/avg/max/mdev = 118.638/4030.529/1907530.998/85816.236 ms, 13 damaged packets of the last 400 received (not counted as lost)
[20:04] <fergusnoble> that code is for 7bit ascii btw
[20:04] <jnd> Hiena: for you ^
[20:05] <rjharrison> Ok that was where I was going wrong let me do the necessary and report back
[20:06] <jnd> guess it has some bug in counting avg/max/mdev
[20:06] <edmoore_> rjharrison: sorry back
[20:06] <jnd> Hiena: mostly around 170ms
[20:06] <rjharrison> fergusnoble you send you stuff though a dac any how so your pulse shape should be quite good already?
[20:07] <rjharrison> edmoore_ think fergus has sorted the asci problem I was sending MSB fist
[20:07] <rjharrison> should have been LSB
[20:07] <fergusnoble> i was hoping to get it to do root raised cosine edges on the pulses
[20:08] <edmoore_> so was I :p
[20:08] <edmoore_> rjharrison: indeed, badger has always been flown reversed iirc
[20:08] <edmoore_> though.... you would have had to set that on truetty to decode us on monday, no?
[20:08] <rjharrison> BTW can you see my truetty output I have spread the peaks but like I was saying to edmoore_ I would have hoped to have mor pert pointed tits than the ones I have
[20:08] <fergusnoble> edmoore_: different kind of reversed, we swap mark and space, not endianess
[20:09] <rjharrison> http://www.robertharrison.org/images/icarus/rtty/truetty-icarus.jpg
[20:09] <edmoore_> ah righty
[20:09] <Hiena> jnd thanx.
[20:09] <edmoore_> hmmm, you do have pretty spread peaks
[20:09] <fergusnoble> rjharrison: thats not too bad
[20:09] <edmoore_> or a big old noise floor
[20:09] <edmoore_> try it, I guess. they may just have an unhelpful scale
[20:10] <rjharrison> bit like an old whore :)
[20:10] <fergusnoble> rjharrison: maybe because of no pulse shaping
[20:10] <rjharrison> Yep
[20:10] <rjharrison> No dac just two resistors
[20:11] <rjharrison> A slightly higher one one pin. Flip between the pins
[20:11] <edmoore_> oh for sure that will solve the prob, the issue is how big a prob it is
[20:11] <edmoore_> badger seems happy enough without shaping - fergusnoble do you know what the scale is on that chap's rtty decoding software FT display?
[20:12] RocketBoy (n=Steve@217.47.75.27) joined #highaltitude.
[20:12] <rjharrison> I can change the shift to a more typical 170 hz by reducing the value of the second resistor
[20:12] <rjharrison> Ahh the very man :)
[20:13] <fergusnoble> really got to go for dinner now
[20:13] <fergusnoble> brb
[20:13] <rjharrison> ttfn and thanks
[20:13] <rjharrison> Hi RocketBoy
[20:13] <rjharrison> Finally got a dodgy rtty working
[20:13] <RocketBoy> spot on
[20:14] <RocketBoy> how dodgy are we talking?
[20:14] <rjharrison> alternating between two resistors for 0 and 1 at the moment. Bit noisy but I hope to pass it though a dac and a low pass filter after talking with ed
[20:14] <Hiena> Hmmm...
[20:15] <rjharrison> I have opened the shift a bit to 420hz
[20:15] <RocketBoy> yep - well even 0 - 1 will work at slower speeds
[20:16] <rjharrison> 200 baud seems ok on the ground
[20:16] <rjharrison> Not sure it would work at distance will keep it to 50 baud
[20:16] <RocketBoy> ok
[20:16] <edmoore_> 300 has worked fine for us in the past. it was shaped though
[20:16] <RocketBoy> yeah 200 a bit unusual
[20:17] <rjharrison> Out of interest this shaping lark means that I want to not jump from one point to another but step there I guess
[20:17] <RocketBoy> well ideally it would be a smooth transition
[20:18] <RocketBoy> but whatever the DAC and LPF can do
[20:18] <rjharrison> say 0 and 9 are the jumps then I want to do 012345678987654321023456789876543210
[20:18] <RocketBoy> the modules have a PF in them
[20:18] <RocketBoy> LPF
[20:18] <rjharrison> Ok cool so I could just get away with using a dac
[20:19] <rjharrison> though to be fair I'm buggered if I can find a cheap 4 bit one anywhere
[20:19] <RocketBoy> not really you want to follow a shape like a sine wave
[20:19] <rjharrison> ok I know what you mean
[20:19] <RocketBoy> or gausian shape
[20:19] <rjharrison> That was a saw shape
[20:19] <RocketBoy> yep
[20:20] <edmoore_> don't need a 4 bit dac
[20:20] <edmoore_> get an 8 bit and just use 16 states within it
[20:20] <RocketBoy> there is a lot of maths behind the best shape - but its all a bit laws of deminishing returens
[20:21] <RocketBoy> ideally the wave shape would match the channel filter
[20:21] <edmoore_> 0-16-32-48-64-76-92 etc ... 256
[20:21] <RocketBoy> but in most cases an approximation to a sine shape gets you about 90% of the improvement
[20:22] <rjharrison> Humm OK I assume you mean 16 jumps to make the sine wavw
[20:22] <edmoore_> root cosine gives a slightly tighter spectrum, according to this-ear algebra bashing i just worked through
[20:22] <RocketBoy> all I have ever used is a 4 bit DAC and that seems good enough for 300Km+
[20:22] <rjharrison> Where do you buy a 4 bit dac?
[20:23] <RocketBoy> didin't its part of the PIC
[20:23] <rjharrison> I seached high and low
[20:23] <rjharrison> Ahh
[20:23] <rjharrison> That would explain I could you PWM I guess if I knoew enough about it
[20:23] <rjharrison> knoew
[20:23] <rjharrison> knew
[20:23] <RocketBoy> actually its not really a DAC - its a programmable voltage reference
[20:24] <rjharrison> PWM is a wave if I'm not mistaken
[20:24] <edmoore_> but rjharrison... you can use a £20p 8 bit DAC. It's irrelevant
[20:24] <edmoore_> PWM + LPF = a voltage
[20:24] <RocketBoy> yeah PWN is a good way to go - downside is the rate you have to run it at to get a frequency well above the LPF
[20:24] <RocketBoy> PWM
[20:25] <RocketBoy> just pushes up power consumption
[20:25] <rjharrison> PWM is on bard the chip saves another 20quid + soldering
[20:25] <rjharrison> board
[20:25] <edmoore_> sorry, 20p
[20:25] <RocketBoy> yeah - onboard DAC is the way to go IMO
[20:25] <edmoore_> not £20
[20:25] <rjharrison> I'm going for the relly lowcost tracker here
[20:26] <edmoore_> £20 is crazy - you can get hundreds of megasample per sec DACs for that money
[20:26] <RocketBoy> its not the £ is the soldering and power consumption that gets me
[20:26] <rjharrison> ahh :) KNow your talking the cheapest one I could fine in a DIP setting ie not surface mount was about 7 quid
[20:26] <edmoore_> oh good lord
[20:26] <edmoore_> though i don't know much about DIP stuff
[20:26] <edmoore_> but that seems crazy talk
[20:27] <edmoore_> linear surely do something
[20:27] <rjharrison> I'll have a quick hunt.
[20:27] <RocketBoy> if you want some DACs I have about 20 of various types (all DIP)
[20:27] <RocketBoy> all AD
[20:27] <rjharrison> I must be doing something wrong I thought they would be under a quid
[20:27] <RocketBoy> you welcome to some FOC
[20:28] <rjharrison> I assume it's worth the effort involved
[20:29] <rjharrison> RocketBoy I appreciate the offer perhaps you could put on in on the next balloon order I make
[20:29] <RocketBoy> sure
[20:29] <rjharrison> BTW what is the balloon situation?
[20:29] <rjharrison> I could do with making a purchase
[20:30] <RocketBoy> I have a order that will be shipped from the US in about 1 week - pus I have a few of most sizes up to 1500 in stock
[20:30] <RocketBoy> do you still want the 3000?
[20:31] <rjharrison> Have you ordered any
[20:32] <edmoore_> am listening to this too
[20:32] <rjharrison> heh
[20:32] <RocketBoy> yep - they have them in stock and I asked them to put 2 aside for when the order is sent
[20:32] <rjharrison> hehe
[20:32] <rjharrison> aside or inside
[20:32] <rjharrison> :)
[20:33] <rjharrison> Remind me what the damamge is ~
[20:33] <RocketBoy> aside - so they have them reserved
[20:33] <RocketBoy> the damage at the mo is £250 as the £ is down so much
[20:33] <rjharrison> 250 quid wasn't it though the exchange rate won't help
[20:33] <rjharrison> hehe
[20:33] <rjharrison> You beat me
[20:34] <RocketBoy> yep its looking v sad
[20:35] <rjharrison> I have an open evelope I would like to send up soonish
[20:35] <rjharrison> 11.95
[20:35] <rjharrison> cost
[20:36] <rjharrison> 8meters long * 1m diameter
[20:36] <edmoore_> mrs jeffers?
[20:37] <edmoore_> whoops
[20:37] <rjharrison> Solar airship from hawkins
[20:38] <RocketBoy> so if rharrison/edmoore would let me know yes/no on the 3000s then I'll order(or not)
[20:39] <RocketBoy> as the case may be
[20:40] <edmoore_> almost ceetainly yes
[20:41] <edmoore_> but i'm not a one-man-buying-band so let me confirm with others
[20:41] <rjharrison> haha
[20:41] <RocketBoy> ok NP let me know soon
[20:42] <rjharrison> RocketBoy I'm going to say no this time around i think. I'm not convinced on the increase in height
[20:42] <rjharrison> Though
[20:42] <rjharrison> Humm
[20:42] <rjharrison> This is difficult
[20:43] <RocketBoy> I could just buy 1 as I'm almost certain one of you guys will buy it
[20:43] <rjharrison> If I order one surly cusf will have to too
[20:43] <edmoore_> we will probably go for the 2 if rjharrison doesn't want one of them
[20:43] <rjharrison> THen there will be a rush on it
[20:43] <edmoore_> we tend to buy in at least 2s
[20:44] <rjharrison> It's hard but I will buy two 1500's off you if that's ok. I'm sure I will buy a 3000 before the summers out
[20:45] <rjharrison> Just so I can beat edmoore_ et al on alt :)
[20:45] <RocketBoy> sure
[20:45] <edmoore_> :P
[20:45] <edmoore_> the race to the top is on
[20:45] <rjharrison> In fact I would put a 75 quid deposit against buying one none refundable
[20:46] <RocketBoy> spiffing
[20:46] <rjharrison> Would that be enought to have one orded in stock ready for the summer?
[20:46] <rjharrison> Summer starts in may
[20:46] <RocketBoy> we aught to to altitude records by balloon size - just like rocketry records
[20:46] <rjharrison> or march
[20:46] <rjharrison> Yep
[20:47] <rjharrison> Though I guess it will be the pics that count
[20:47] <rjharrison> Be interesting to see if another 5k makes much difference
[20:47] <edmoore_> agreed
[20:48] <rjharrison> I think I could get max alt very soon with the envelope or a tracker test. With a very low filled balloon
[20:48] <rjharrison> Just won't be landing onshore
[20:48] <RocketBoy> yeah I'll put it all into the brain box and order based on my gut feel
[20:49] <edmoore_> i think recovery should count for alt records
[20:49] <rjharrison> Ok well if you can send me an invoice for a 1200 1500 and a 75 pound deposit I'll make sure you get paid
[20:49] <edmoore_> otherwise we'd just release badger board on a 1.5 now with a 40:1 ascent rate and see it hit 40km, 600km out to sea
[20:49] <rjharrison> That would be interesting :)
[20:50] <edmoore_> we'll probs sacrifice badger board 1 on a zp out to sea
[20:50] <rjharrison> I'm going to do that too using that solar ship
[20:50] <RocketBoy> I'm sure you will get the animal rights people on you
[20:51] <rjharrison> haha
[20:51] <edmoore_> we'll keep schtum
[20:52] <RocketBoy> I think we need ferrit and stoat boards as well
[20:52] <rjharrison> I'm all for sending off a zp without a camera. I have the set up nearly ready. I'm going to send lassenskII as it's cheaper
[20:53] <edmoore_> we've got some zp's in the dungeon currently
[20:53] <edmoore_> they'll take 100km to 28km
[20:53] <edmoore_> 100kg*
[20:53] <rjharrison> I'm going to do rtty and cw tests on the zp
[20:53] <edmoore_> they're the *final solution* to the alt record challenge
[20:53] <RocketBoy> ooo edmoore is less than 100Kg
[20:54] <rjharrison> What have you got in the dungeon? they sound awsume
[20:55] <rjharrison> Well you have the advantage that your helium is free though I must say they must take a bit of filling
[20:55] <edmoore_> lots and lots of stuff
[20:55] <edmoore_> balloons, nuclear fusion reactor, soldering irons,
[20:55] <rjharrison> You would have to have lots and lots of material in one balloon alone
[20:56] <edmoore_> there is lots of material in them
[20:56] <edmoore_> for sure
[20:56] <rjharrison> RocketBoy you have my email I'll pay you when I get a request for cash if that's ok
[20:56] Nick change: edmoore_ -> edmoore
[20:56] <rjharrison> Paypal
[20:56] <RocketBoy> sure np - when they arrive
[20:57] <rjharrison> OK sure so that's 1200,1500 and 75 pound down on the 3000
[20:57] <rjharrison> + delivery
[20:58] <edmoore> have email the other chapses
[20:58] <rjharrison> 'ed
[20:59] <rjharrison> I need to launch but I'm so busy b4 xmas
[20:59] <edmoore> winds are a bit poo too
[21:00] <rjharrison> BTW are you 7bit ascii for spped?
[21:00] <rjharrison> speed
[21:02] <edmoore> uhuh
[21:02] <rjharrison> RTTY?
[21:03] <rjharrison> I though fergusnoble said that you used 7bit ascii
[21:03] <rjharrison> I may be wrong
[21:04] <edmoore> rtty doesn't have to be baudot
[21:04] <edmoore> unless it does
[21:04] <edmoore> i don't know which layer of the osi model those decisions sit at
[21:05] <RocketBoy> I don't think RTTY specifies the encoding
[21:05] <RocketBoy> its a general term
[21:06] <RocketBoy> Radio Telly-TYpe
[21:06] <RocketBoy> as in teleprinter
[21:07] <RocketBoy> Oops Radio TeleTYpe
[21:12] <edmoore> :)
[21:16] Hiena (n=Hiena@81.93.195.181.datatrans.hu) left irc: "-=Halt! Hammerzeit!=-"
[21:17] <fergusnoble> back
[21:17] <fergusnoble> rjharrison: get it working?
[21:21] <fergusnoble> edmoore: you home now?
[21:21] <edmoore> uhuh
[21:21] <fergusnoble> cool
[21:21] <fergusnoble> did iain get his card back?
[21:22] <edmoore> uhuh
[21:24] <fergusnoble> guys, i was thinking, do you think we should try and semi standardise our telemetry packets?
[21:25] <fergusnoble> so all our various decoding softwares and work with each others payloads
[21:26] <rjharrison> fergusnoble yep LSB rules OK
[21:27] <rjharrison> fergusnoble YES I'm bloody glad you put the comma in after badger on your tx
[21:27] <fergusnoble> yeah it was silly not to do that originally
[21:28] <fergusnoble> but maybe we could standardise the first few fields, so we all have say time, lat, lng and alt in the same places
[21:28] <edmoore> like most packets - just delimit 'other stuff' at the end of a packet
[21:28] <fergusnoble> yeah
[21:29] <rjharrison> I mentioned it to jcoxon the day before you launched and he said that there was little chance of you changing it and hey presto it was changed we had a little laugh about that
[21:29] <edmoore> gives you some flexibilty to let the protocol evolve
[21:29] <fergusnoble> hehe
[21:29] <rjharrison> yep perfect
[21:30] <fergusnoble> rjharrison: the reson was i changed the software to work with james's payload and i was in a rush before we launched and didnt have time to change it back :)
[21:30] <fergusnoble> so it was quicker to change the code on the badger to put a comma in
[21:30] <rjharrison> Do you want to give the spec? It will help with the distibuted listener james and I are working on
[21:30] <rjharrison> distributed
[21:30] <edmoore> i think APRS has done this since year dot, infact
[21:30] Simon-MPFH (n=simon@phantom.mpfh.co.uk) left irc: "Leaving"
[21:30] <fergusnoble> erm, well what fields do yo think everyone will want
[21:31] <edmoore> lat long alt utc time
[21:31] <edmoore> callsign
[21:31] <rjharrison> the obv + 3 temps; baro
[21:31] <edmoore> nah, jus
[21:31] <edmoore> whoops
[21:31] <edmoore> I'd just put temps and baro into the other bit
[21:31] <fergusnoble> what about the system ticks?
[21:31] <edmoore> that's not really important enough to go into the standard
[21:31] <rjharrison> If we know where there are they can be reported
[21:32] <edmoore> system ticks are more useful to us... unless the utc time crashes with a gps crash
[21:32] <edmoore> i agree you want some kind of unique message id
[21:32] <rjharrison> I would put them in a position and then opt to leave them out
[21:32] <fergusnoble> we transmit seconds since the payload was turned on
[21:32] <fergusnoble> and then seconds since the last gps time fix
[21:32] <fergusnoble> (which is less important)
[21:33] <edmoore> in the 'main' bit you just want as little as you can get away with to get the job done
[21:33] <fergusnoble> yeah
[21:33] <edmoore> lat long alt time
[21:33] <fergusnoble> do you and james both have a ticks field?
[21:33] <edmoore> everything non essential should go in the 'message' part of the packet rather than the header
[21:33] <fergusnoble> i think callsign,ticks,lat,lng,alt,time,other stuff would be good
[21:34] <edmoore> that requires a standard tick format
[21:34] <fergusnoble> well could just be in seconds
[21:34] <edmoore> but if that's just seconds since [a thing] then that's easy enough I guess
[21:35] <akawaka> why not just use the aprs format?
[21:35] <fergusnoble> akawaka: whats that?
[21:35] <edmoore> this is where i was getting when i mentioned it earlier - it is just the absolute basics then a big gap for other stuff
[21:35] <edmoore> fergusnoble: is the standard that they use in the US
[21:35] <akawaka> its used in europe too
[21:35] <akawaka> http://aprs.org/
[21:36] <edmoore> it's packet on one layer, but the data format is probably nickable
[21:36] <fergusnoble> i know what aprs is, i mean whats the packet format?
[21:36] <edmoore> it's less common here and nnoyingly we can't really make use of the network
[21:36] <edmoore> as we can braodcast with any power
[21:36] <rjharrison> I will have a ticks on the next launch
[21:36] <fergusnoble> ok
[21:37] <edmoore> we can put posterior error correcting codes in the 'blah' section too which is nice - gives us flexibility without breaking everything
[21:39] <fergusnoble> yeah, sure, i mean we can transmit other stuff which the decoder should just ignore if it doesnt see that callsign etc.
[21:40] <fergusnoble> maybe callsign,ticks,time,lat,lng,alt,other would make more sense
[21:40] <rjharrison> One other question on dac if I tx 1 1 1 then there will be no change its only on the change down to a 0 or up to a 1 where I want to shape the signal? Am I correct?
[21:40] <edmoore> should it perhaps look for some charcters before a callsign
[21:41] <edmoore> eg $$
[21:41] <rjharrison> That would be cool though one shoud be enough in the interest of CW and spped
[21:41] <rjharrison> spped
[21:41] <rjharrison> speed
[21:41] <rjharrison> :)
[21:41] <edmoore> so it doesn't have to know to look for 'badger' and take the next 5 entries for telem, but instead look for '$$' and take the next 6 entries for telem, which includes the name
[21:42] <edmoore> probability of false trigger is massively reduced with two
[21:42] <fergusnoble> rjharrison: yeah, you only need to shape on the transition between levels
[21:42] <fergusnoble> rjharrison: if you look at that code i posted you can see it just does nothing if the next bit is the same
[21:43] <akawaka> ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.zip
[21:45] <rjharrison> One last on tx'ing do you do the tx thrugh intruupts to allow other processing to take place whilst your tx'ing ?
[21:45] <edmoore> tnkernel wait states are the answer to that
[21:45] <fergusnoble> it uses the multitaking built into tnkernel
[21:46] <fergusnoble> it sets the dac and then the task sleeps for the length of that bit
[21:46] <fergusnoble> while its asleep other tasks can run
[21:46] <rjharrison> Ok I don't have that luxury would intrupts be the way to go?
[21:46] <fergusnoble> yeah i guess so
[21:46] <fergusnoble> you dont really want to do this by polling, you want it to be quite responsive
[21:47] <rjharrison> Oh for the high level environment you have at your disposal
[21:47] <fergusnoble> maybe set a timer interrupt to trigger every bit period
[21:47] <edmoore> the high level environment is just a neatening up of interrupts
[21:47] <fergusnoble> then use a 2 bit stop bit
[21:47] <edmoore> basically, we are just using interrupts
[21:47] <rjharrison> Yep
[21:47] <edmoore> but a powerful interrupt library
[21:47] <edmoore> that calls itself an OS
[21:48] <fergusnoble> edmoore: it does quite a lot more than that too but basically yes
[21:49] <rjharrison> Thats the plan to set a timer for the bit period though wouldn't that make the transition from 1 to 0 tricky. Though this has to happen clearly well before the interrupt is triggered again so probably not.
[21:49] <fergusnoble> oh if you are doing shaping then yes, you will have to be a bit more clever
[21:50] <fergusnoble> probably in that case you could make a timer interrupt and then when its called, load a value into the timer which is how long you want to wait before the next interrupt
[21:50] akawaka (n=akawaka@external.treyarch.com) left irc: Read error: 60 (Operation timed out)
[21:50] <rjharrison> how many steps to a shape? 16 Then the timer could be set to 16th bit period
[21:50] <fergusnoble> so you can vary the timing between interrupts
[21:50] <rjharrison> If that makes sense
[21:51] <fergusnoble> rjharrison: thats really up to you
[21:51] <fergusnoble> 16 sounds sensible though
[21:51] <fergusnoble> i guess its basically as many as possible without using up all your cpu time
[21:52] <rjharrison> Ie 16 steps between 1 and 0 rather than say stright there. I guess you need to tx the 1 or a 0 for a certain period too
[21:52] <fergusnoble> but any more than 16 is probably overkill
[21:52] <fergusnoble> yeah, so in the hold period you could change the timer period so it doesnt interrupt again until the next transition
[21:52] <fergusnoble> if that makes any sense
[21:53] <rjharrison> Yep it does
[21:53] <edmoore> the length of the transition can be the length of the bit period
[21:53] <fergusnoble> edmoore: then you really will be using a lot of cpu time
[21:54] <edmoore> because any time you 'loose' on the way up, you make up on the way back down on a transition
[21:54] <fergusnoble> thats basically MSK then i think?
[21:54] <edmoore> well, you'll be using the same cpu time
[21:54] <edmoore> in that you'll have the same no of interrupts to sort out
[21:54] <fergusnoble> edmoore: no, when the bit is at a constant value the cpu can go off and do other things
[21:55] <edmoore> it can do thins between bit DAC interrupts too
[21:55] <fergusnoble> unless you are suggesting to make the steps in the transition longer
[21:55] <edmoore> i'm fairly certain that's not at all MSK too
[21:55] <edmoore> yes, that's it
[21:55] <edmoore> so you have 16 states still
[21:56] <edmoore> but you take a bit period to transition through them
[21:56] <edmoore> so you still have 16 interrupts
[21:56] <edmoore> cpu still does the same amount of stuff, you jsut chance the timer lengths
[21:56] <edmoore> change*
[21:57] <rjharrison> Humm, I'm thinking an interupt every 1ms for transition. 10 steps for the transition bit rate every 10ms = 100 BAUD
[21:58] <edmoore> you should really pick a standard baud rate
[21:58] <fergusnoble> rjharrison: i think it might be more flexible in the long run to code it so you pick a baud rate and it adjusts the timer period to suit
[21:59] <edmoore> if we're going to the lengths of making every intercompatibile
[21:59] <fergusnoble> dont know though
[21:59] <edmoore> everyone*
[21:59] <fergusnoble> 50 and 300 are standards for RTTY
[21:59] <fergusnoble> and 45.45 is the old old standard
[21:59] <rjharrison> You do 50 for badger?
[21:59] <fergusnoble> yup
[22:00] <rjharrison> Fuck it I'll stick to 50
[22:00] <rjharrison> I can't get 75 to work for me :)
[22:00] <edmoore> what xtal?
[22:02] <fergusnoble> i will change the badger code to be non-reversed at some point
[22:02] <fergusnoble> maybe we should all change to 45.45 as thats the real standard for amateur stuff
[22:02] <fergusnoble> meh
[22:09] mc- (n=mfcastle@cpc1-glfd1-0-0-cust487.glfd.cable.ntl.com) joined #highaltitude.
[22:17] <mc-> rjharrison, I don't think you need to bother with a DAC, an RC filter will be good enough.
[22:18] <mc-> a RTTY decoder looks at the 2 frequencies, and compares the power at each frequency.
[22:18] <mc-> Slowly moving between a '1' and '0' could increase the chance of a mis-decode
[22:19] <edmoore> except that transitioning between them sinusoidally increases the power in each frequency
[22:19] <gordonjcp> erm
[22:19] <gordonjcp> wait, what?
[22:19] <gordonjcp> changing the *frequency* sinusoidally?
[22:19] <mc-> an RC would be a close approximation to a sine
[22:20] <edmoore> transitioning between two frequencies in fsk
[22:20] <fergusnoble> mc-: theoretically speaking you get a whole bunch of benefits from using root raised cosine
[22:20] <gordonjcp> edmoore: you mean slowly changing from one frequency to another, like applying portamento?
[22:20] <fergusnoble> e.g. better spectral efficiency
[22:20] <gordonjcp> there is absolutely *no bloody way* that would work for fsk
[22:21] <fergusnoble> and less transmitter power wasted on frequency components that arent part of your data
[22:21] <edmoore> not slowly, sinusoidally
[22:21] <mc-> yes, PSK31 uses raised cos, but only to keep the bandwidth small
[22:21] <edmoore> if you suddenly go from freq x to freq y, you get a whole load of harminics thrust out across the spectrum
[22:21] <mc-> not with a RC filter
[22:21] <fergusnoble> which are wasted transmitter power
[22:22] <mc-> I think the difference between a RC filter and a DAC could be within a 1-2db
[22:22] <gordonjcp> edmoore: I'm not sure what you mean, "sinusoidally"
[22:22] <gordonjcp> edmoore: if your fsk requires (for instance) 1200Hz and 2200Hz then you should never under any circumstances transmit any other tone
[22:23] <mc-> now I've rocked the boat, I'm off..
[22:23] <edmoore> helpful.
[22:23] <mc-> sorry
[22:23] <fergusnoble> gordonjcp: thats not correct, it you immediately change between 1200 and 2200 you will waste power on harmonics
[22:23] <fergusnoble> gordonjcp: you need some kind of transition
[22:24] mc- (n=mfcastle@cpc1-glfd1-0-0-cust487.glfd.cable.ntl.com) left irc:
[22:26] <edmoore> .... this is in terms of the baseband
[22:26] <fergusnoble> also by using raised cosine you get less ISI
[22:27] <fergusnoble> if you consider the spectrum of a top hat function, you get a sinc
[22:27] <rjharrison> fergusnoble can you listen to this for a second I'm not sure waht the ticking is possibly the harmonics
[22:27] <rjharrison> http://www.robertharrison.org/images/icarus/rtty/Icarus-rtty.wav
[22:27] <fergusnoble> which has lobes of considerable power where you other symbol should be
[22:27] <rjharrison> edmoore you may have some idea
[22:27] <gordonjcp> fergusnoble: that's odd, because that's how *every FSK modem in the known world of data comms* does it...
[22:28] <gordonjcp> fergusnoble: can you provide an example of an FSK signal that slides slowly between frequencies?
[22:28] <fergusnoble> rjharrison: i cant hear anything :(
[22:29] akawaka (n=akawaka@external.treyarch.com) joined #highaltitude.
[22:30] <gordonjcp> rjharrison: can you record it at a higher sample rate?
[22:31] <gordonjcp> I reckon what you're hearing there is aliasing
[22:31] <rjharrison> Weird I just played it an it sounded fine
[22:32] <edmoore> gordonjcp: as far as I was aware, we're talking about shaping the baseband to limit the bandwidth of the modulated signal...
[22:33] <gordonjcp> edmoore: oh hang on, I thought you were talking about sliding the frequency
[22:33] <fergusnoble> rjharrison: are those clicks still there when you detune the radio?
[22:33] <gordonjcp> edmoore: in any case, you'll probably waste far more electrical power trying to shape the audio signal to "perfection"
[22:33] <fergusnoble> gordonjcp: that is in effect what happens when you shape the baseband with fsk
[22:33] <gordonjcp> fergusnoble: not really, no
[22:34] <gordonjcp> fergusnoble: bear in mind that I have implemented fsk *and* software music synthesizers
[22:34] <fergusnoble> can you explain to me what happens then?
[22:34] <gordonjcp> I know a wee bit about keeping weird-ass harmonics in check
[22:34] <edmoore> proof by induction, not intimidation, gordonjcp
[22:34] <gordonjcp> fergusnoble: okay, first of what do you think is happening?
[22:34] <edmoore> one counts, one doesn't
[22:35] <gordonjcp> let's make sure we're even discussing the same thing here - I may have grossly misunderstood the discussion right back at the start
[22:36] <gordonjcp> if I'm generating a 1200Hz tone and then wish to switch to a 2200Hz tone, should it just jump straight to 2200Hz or should it "portamento" 1201,1202,1203--2198,2199,2200Hz?
[22:38] <fergusnoble> if your baseband has a smooth transition, a continuous function, then when fsk modulated the output will pass through all the frequencies in between 1200 and 2200
[22:38] <fergusnoble> however, it might transition much quicker than one cycle
[22:38] <fergusnoble> so im not saying it would look as if all thoes frequencies were present
[22:39] <gordonjcp> uhm
[22:39] <gordonjcp> so if it transitions faster than one cycle, why bother with it at all?
[22:39] <fergusnoble> its about not having a discontinuity in the phase roughly speaking i think
[22:39] <gordonjcp> bingo
[22:39] <gordonjcp> which is why you switch at a zero crossing
[22:40] <gordonjcp> don't bugger about with the frequencies, just keep track of the phase
[22:40] <fergusnoble> but even switching at zero crossing the derivative of the phase is discontinuous
[22:40] <fergusnoble> anyway, we cant do that, our fsk modulator is a black box
[22:40] <gordonjcp> it's probably worth noting that if you switch at a zero crossing, your ones and zeros will be a few fractions of a percent longer or shorter than they ought to be
[22:40] <gordonjcp> fergusnoble: in practical terms it makes no difference
[22:41] <fergusnoble> indeed, our radio works just fine and we are just transitioning straight
[22:41] <gordonjcp> any harmonics would be tiny tiny things and probably outside the passband of your TX anyway
[22:41] <fergusnoble> were not even trying to keep the phase continuous, the fks box does its own thing
[22:41] <fergusnoble> and that works fine
[22:42] <fergusnoble> however yo can hear strong clicks on the bit transitions when the radio is detuned
[22:42] <gordonjcp> fergusnoble: you get analogue afsk generators and they don't give a fig about phase
[22:42] <gordonjcp> fergusnoble: well yeah - but you'll hear that on *any* fsk signal
[22:42] <RocketBoy> humm missed most of this but if you are talking AFSK then its phase continious
[22:42] <fergusnoble> showing a power is going into out of band harmonics
[22:42] <gordonjcp> fergusnoble: which you're going to get unless you're only doing CW *anyway*
[22:43] <RocketBoy> ie if a bit finishes at 135deg of 1200Hz then the 2200Hz tone starts at 135deg
[22:43] <fergusnoble> gordonjcp: the point was it is possible to reduce a lot of this y shaping the aseband appropriately
[22:43] <gordonjcp> and in point of fact you'll get harmonics on your CW signal because none of your RF signal path is even within shouting distance of linear
[22:43] <gordonjcp> fergusnoble: but at what cost on the power budget?
[22:44] <fergusnoble> well, the uC is taking care of it, it will use the same power if its in the idle task or in the radio task
[22:44] <gordonjcp> RocketBoy: that's the other way to do it
[22:44] <fergusnoble> (although really it should be put to sleep in the idle task)
[22:44] <gordonjcp> fergusnoble: but you've got all this extra DAC bollocks to play with, and far more CPU cycles to worry about it
[22:45] <edmoore> that's not at all true
[22:45] <fergusnoble> gordonjcp: i dont know about rjharrison but our radio is run off the dac anyway
[22:45] <gordonjcp> fergusnoble: I suppose you may actually have a dac in the controller anyway in which case you may as well use it
[22:45] <edmoore> we've a built in DAC and 16 times the interrupts on the radio - which if you look at the cpu load makes the difference between about 3% load and 3.5% load
[22:46] <RocketBoy> for 1200/2200 AFSK (bell 202) that is the only way to do it properly - its defined as phase continous
[22:46] <RocketBoy> in fact all AFSK is done that way as far as I know
[22:46] <gordonjcp> RocketBoy: how on earth a *real* Bell 202 modem is in any way phase continuous is beyond me, though
[22:47] <gordonjcp> they are, to put it mildly, pretty crude
[22:47] <fergusnoble> gordonjcp: also, power transmitted out of band is only one consideration, you also really want to reduce ISI which is helped by baseband pulse shaping
[22:47] <RocketBoy> whay you mean a VCO
[22:47] <RocketBoy> a VCO is by definition phase continious
[22:47] <gordonjcp> RocketBoy: not that you'd be able to tell, with all that phase noise
[22:48] <RocketBoy> at the RX end maybe
[22:48] <gordonjcp> RocketBoy: have you ever worked on a Bell 202? They're *awful*
[22:49] <gordonjcp> modern chips do a far better job, but the original was a drifty noisy mess
[22:49] <RocketBoy> nope the slowest modem I ever used was 600 baud
[22:49] <RocketBoy> that was about the time I was introduced to data comms - about 1982
[22:49] <gordonjcp> RocketBoy: we had them as recently as 1994, for admittedly obsolete bits of specialised kit
[22:50] <gordonjcp> RocketBoy: the wheels of the oil industry turn incredibly slowly, once they find something that works
[22:50] <gordonjcp> every so often I get an Amstrad PCW disk drive in to unfuck
[22:51] <gordonjcp> they just will not die, not entirely
[22:51] <fergusnoble> anyway, its all a bit academic, im sure the performance increase isnt that great, we are absolutely nowhere near utilising the theoretical channel bandwidth
[22:51] <gordonjcp> well yeah
[22:51] <fergusnoble> so probably dont need such fancy tricks to try and squeese more data through
[22:52] <gordonjcp> fergusnoble: so just to recap, the DAC output is controlling the TX frequency and you're getting your FSK using an SSB receiver?
[22:52] <fergusnoble> yup
[22:52] <gordonjcp> or you're generating AFSK and striving for as sinusoidal a modulator as possible?
[22:52] <gordonjcp> ok
[22:52] <gordonjcp> well
[22:52] <gordonjcp> sod it, add more bits and get as many steps as you can, then program it to play a tune
[22:53] <gordonjcp> if a thing's worth doing, it's worth overdoing
[22:53] <fergusnoble> yeah, was planning to get it to play flight of the valkyries :)
[22:53] <fergusnoble> at some point
[22:54] <gordonjcp> lol
[22:54] <fergusnoble> also, our fsk transmitter has like 25khz maximum deviation, so could get more benefit from moving to MFSK probably
[22:55] borism_ (n=boris@195-50-200-149-dsl.krw.estpak.ee) joined #highaltitude.
[22:55] <RocketBoy> yeah in general terms the more complex the modulation scheme - the more bandwidth you can squeeze of the same channel bandwidth and S/N
[22:56] <RocketBoy> its wether its worth the effort
[22:58] <edmoore> there's probably more effort/return in coding
[22:58] <edmoore> right now
[23:01] <RocketBoy> I guess it depends what you want to put over the channel - if you have an application that requires a specific bitrate and you have a fixed bandwith and S/N and you can find a modulation scheme that will get you there its worth it
[23:01] <RocketBoy> otherwise stick to a simple modulation scheme and reduce the bitrate
[23:01] <RocketBoy> IMO
[23:02] borism (n=boris@195-50-204-196-dsl.krw.estpak.ee) left irc: Read error: 145 (Connection timed out)
[23:02] <RocketBoy> I dout if the ultimate improvement between modulation schemes is more than about 4x
[23:03] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) joined #highaltitude.
[23:04] <jcoxon> evening all
[23:04] <RocketBoy> doubt
[23:05] <fergusnoble> jcoxon: hello
[23:05] <fergusnoble> jcoxon: we were discussing maybe standardising some of our telem formats so we can make our decoding programs more interoperable
[23:06] <fergusnoble> though we could go for something like callsign,time,lat,lng,alt, and then anything else thats specific to the payload
[23:06] <jcoxon> ooo yeah
[23:07] <jcoxon> i think a standard for the first few fields and then mission specific for the rest
[23:08] <fergusnoble> yeah
[23:08] <jcoxon> then the decoder can easily grab whats important
[23:08] <fergusnoble> maybe callsign,ticks,time,lat,lng,alt
[23:08] <jcoxon> yeah that sounds best
[23:08] <fergusnoble> where ticks are just seconds since powerup or something
[23:08] <jcoxon> i've written a client in python to upload to the server
[23:08] <jcoxon> would be good to intergrate some sort of version into your code
[23:08] <jcoxon> its just a matter of POST to a server via html
[23:09] <fergusnoble> yeah, sounds good
[23:09] <RocketBoy> it would be nice to standadize on lat/long format (decimal degrees rather that degrees and minutes is my preference)
[23:09] <jcoxon> then we can really do distributed listeinging
[23:09] <RocketBoy> than
[23:09] <jcoxon> i agree with decimal
[23:09] <jcoxon> much easier to work with
[23:10] <RocketBoy> yeah
[23:10] <jcoxon> especially in the field
[23:10] <fergusnoble> yup, decimal would get my vote
[23:11] <jcoxon> ooo looking the logs i like the idea of something like a $$ at teh beginning of the string
[23:11] <fergusnoble> the distributed traker thing could then just store all the other stuff it gets after the standard part just as text for processing later if needed
[23:11] <jcoxon> therefore we don't need to define the callsign when searching
[23:11] <jcoxon> yeah at the mo it goes into a sql server
[23:12] <fergusnoble> yeah a $$ could be good
[23:12] <RocketBoy> what would ticks be in ? just a count of undefined period - or in seconds?
[23:12] <jcoxon> hmmm maybe cycles
[23:12] <fergusnoble> the only trouble i see with that is if either of those chars gets mangled you loose the whole packet
[23:12] <fergusnoble> RocketBoy: was thinking seconds
[23:13] <jcoxon> for example in my case we need to know which cycle of rtty we are at before the sstv transmission
[23:13] <fergusnoble> that could go into the other data at the end maybe?
[23:13] <jcoxon> yeah
[23:13] <jcoxon> okay seconds
[23:13] <jcoxon> thats fine with me - nice and easy
[23:14] <edmoore> RocketBoy: yes to 2 3kgs
[23:14] <fergusnoble> also some kind of checksum would be good
[23:14] <edmoore> 2 x 3kg*
[23:14] <RocketBoy> I guess if you have time in HH:MM:SS (GMT?) then with a streight ticks count you can work out the period
[23:14] <edmoore> fergusnoble: was thinking we could checksum into the 'blah' - it reduces the technical entry requirement to super newbies
[23:14] <fergusnoble> yeah we should standardise the time to be colon delimited hh:mm:ss GMT
[23:15] <jcoxon> yup, i like colons for hh:mm:ss
[23:15] <fergusnoble> also, maybe drop the 'M' from the end of you altitude reading jcoxon?
[23:15] <jcoxon> and the checksum is optional right a the end
[23:15] <jcoxon> fergusnoble, yup
[23:15] <edmoore> so the blah can have checksums and error correction data aswell, or anything else slightly more advanced that what has served us pretty reliabley so far - dumb text
[23:15] <fergusnoble> yeah, sounds sensible
[23:16] <edmoore> don't want to be explaining CRC to jatkins, really
[23:16] <fergusnoble> so we are going for a $$ to start the packet?
[23:16] <jcoxon> its it a suitable character?
[23:16] <edmoore> i chose that at complete random - whatever
[23:16] <edmoore> just *something*
[23:16] <edmoore> maybe 'BLN'
[23:16] <fergusnoble> BLN?
[23:16] <edmoore> or 'HAB'
[23:17] <edmoore> balloon
[23:17] <edmoore> or >>
[23:17] <edmoore> i dunno
[23:17] <jcoxon> i quiite like HAB
[23:17] <jcoxon> HAB Badger, HAB Pegasus, HAB Icarus
[23:18] <fergusnoble> are there any characters that are good for this kind of thing?
[23:18] <fergusnoble> like U as it is a square wave?
[23:18] <edmoore> something more rare might be good
[23:19] <gordonjcp> fergusnoble: /usr/share/dict/words
[23:19] <edmoore> because when we build 'altrahab' that will throw the system
[23:19] <gordonjcp> apply a suitable regex and find a good word that suits your acronym
[23:19] <fergusnoble> a few Us would make sure the clock reconstruction locked in
[23:21] <edmoore> ryryry is the rtty standard isn't it?
[23:21] <gordonjcp> yeah
[23:22] <gordonjcp> you see that a *lot* on HF ;-)
[23:22] <jcoxon> we don't want any standards
[23:22] <jcoxon> as it might get mistaken
[23:22] <fergusnoble> RY is good as its 0xA 0x6 in baudot
[23:23] <fergusnoble> i.e. a square wave which switches direction in the middle
[23:23] <fergusnoble> but we are using ascii
[23:23] <jcoxon> okay i've got to go
[23:23] <jcoxon> but i'll be on tomorrow
[23:23] <fergusnoble> ok, cool
[23:23] <fergusnoble> see you later
[23:23] <jcoxon> would be cool if someone wrote it up or something, on the wiki?
[23:24] <jcoxon> right byeeee
[23:24] jcoxon (n=jcoxon@host86-158-31-172.range86-158.btcentralplus.com) left irc: "Leaving"
[23:25] <fergusnoble> actually what i said is wrong
[23:26] <fergusnoble> but 0xA6 is some kind of useful magic number
[23:26] <fergusnoble> they use it in the partition table for identification
[23:30] <RocketBoy> Part of the problem with serial ascii is that since if you send characters back to back (no gaps between the stop and the next start) then if the start is missed then several caharcetrs get corrupted
[23:31] <RocketBoy> there might be particular starting data patterns where this is less likly
[23:39] <RocketBoy> night all
[23:39] RocketBoy (n=Steve@217.47.75.27) left irc: "Leaving"
[23:57] edmoore (n=edmoore@88-212-167-121.rdns.as8401.net) left irc:
[00:00] --- Wed Dec 10 2008