highaltitude.log.20150710

[00:01] Ian_ (4d651452@gateway/web/freenode/ip.77.101.20.82) left #highaltitude.
[00:01] Ian_ (4d651452@gateway/web/freenode/ip.77.101.20.82) joined #highaltitude.
[00:26] dustinm` (~dustinm@105.ip-167-114-152.net) left irc: Ping timeout: 248 seconds
[00:28] ke5gdb (614d354b@gateway/web/freenode/ip.97.77.53.75) left irc: Ping timeout: 246 seconds
[01:22] talsit_roam (uid30008@gateway/web/irccloud.com/x-uzfbaswlaqoypedn) left irc: Quit: Connection closed for inactivity
[01:37] KT5TK1 (~thomas@p5B37BC2C.dip0.t-ipconnect.de) joined #highaltitude.
[01:39] KT5TK (~thomas@p5B37B6C1.dip0.t-ipconnect.de) left irc: Ping timeout: 264 seconds
[02:04] sumie_afk (~sumie-dh@rt02.komunikacnisite.cz) left irc: Ping timeout: 264 seconds
[02:05] sumie_afk (~sumie-dh@rt02.komunikacnisite.cz) joined #highaltitude.
[02:38] pjm_ (~pjm@uhfsatcom.plus.com) joined #highaltitude.
[02:39] pjm (~pjm@uhfsatcom.plus.com) left irc: Ping timeout: 255 seconds
[03:41] dustinm` (~dustinm@105.ip-167-114-152.net) joined #highaltitude.
[03:49] day_ (~yashi@unaffiliated/day) joined #highaltitude.
[03:52] day (~yashi@unaffiliated/day) left irc: Ping timeout: 265 seconds
[03:52] Nick change: day_ -> day
[04:04] pjm_ (~pjm@uhfsatcom.plus.com) left irc: Ping timeout: 265 seconds
[04:17] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) left irc: Ping timeout: 256 seconds
[05:03] Lemml (~andreas@p5080F5EC.dip0.t-ipconnect.de) joined #highaltitude.
[05:34] Nick change: fl_0|afk -> fl_0
[05:37] malgar (~malgar@bo-18-150-236.service.infuturo.it) joined #highaltitude.
[06:10] Nick change: fl_0 -> fl_0|afk
[06:11] edmoore (~ed@82.6.148.64) joined #highaltitude.
[06:17] es5nhc (~tarmo@108-40-71-217.static.internet.emt.ee) joined #highaltitude.
[06:17] Nick change: fl_0|afk -> fl_0
[06:20] sumie-dh (~sumie-dh@rt02.komunikacnisite.cz) joined #highaltitude.
[06:34] goopypanther1 (~goopypant@goopypanther.org) left irc: Ping timeout: 276 seconds
[06:35] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) joined #highaltitude.
[06:38] LazyLeopard (~irc-clien@chocky.lazyleopard.org.uk) joined #highaltitude.
[06:42] goopypanther (~goopypant@goopypanther.org) joined #highaltitude.
[06:53] sumie-dh (~sumie-dh@rt02.komunikacnisite.cz) left irc: Ping timeout: 248 seconds
[07:02] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) left irc: Ping timeout: 264 seconds
[07:05] goopypanther (~goopypant@goopypanther.org) left irc: Ping timeout: 255 seconds
[07:10] edmoore (~ed@82.6.148.64) left irc: Quit: This computer has gone to sleep
[07:10] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) joined #highaltitude.
[07:18] goopypanther (~goopypant@goopypanther.org) joined #highaltitude.
[07:30] fab4space (~fab4space@AMontpellier-656-1-21-199.w92-133.abo.wanadoo.fr) joined #highaltitude.
[07:41] malgar (~malgar@bo-18-150-236.service.infuturo.it) left irc: Read error: Connection reset by peer
[07:44] goopypanther (~goopypant@goopypanther.org) left irc: Ping timeout: 264 seconds
[07:45] ibanezmatt13 (1f6989f5@gateway/web/freenode/ip.31.105.137.245) joined #highaltitude.
[07:45] sumie-dh_ (~sumie-dh@gw.mediafactory.cz) joined #highaltitude.
[07:50] ipdove (~ipdove@interclub.plus.com) joined #highaltitude.
[07:56] goopypanther (~goopypant@goopypanther.org) joined #highaltitude.
[08:05] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) left irc: Ping timeout: 264 seconds
[08:11] <ibanezmatt13> Morning all. For HAB, is it worth using interrupts for the UART/GPS as well as the radio?
[08:12] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) joined #highaltitude.
[08:13] <mfa298> the avr has interrupts when it gets data from the uart which you might want to use to at least put the data in the buffer
[08:13] <ibanezmatt13> Yeah I was looking at having an interrupt on the RX_complete flag
[08:14] <Vaizki> I use i2c for GPS and I think it's well worth it
[08:15] <ibanezmatt13> I've not really looked into i2c yet
[08:16] <Vaizki> i2c and ubx instead of serial and nmea.. I recommend it :)
[08:16] <ibanezmatt13> why do you prefer it over serial?
[08:16] <day> why do you think that i2c is better than usart for the gps?
[08:16] <Vaizki> with ubx you basically get binary data, read it into a buffer, cast it into a struct and you can directly access elements
[08:17] <mfa298> for uart, the easiest is probably to have the ISR fill a buffer with the data it receives which you can then check and parse in the main loop.
[08:17] <mfa298> you could also look at parsing the nmea data in the ISR as it comes in but that's more tricky and could make the ISR bloated
[08:17] <ibanezmatt13> mfa298 yeah, I was wondering if when it does start to interrupt at 9600 baud the timing of the radio interrupt might be affected?
[08:17] <daveake> For NMEA it's worth checking for the $ and LF in the ISR
[08:17] <Vaizki> well one reason is the 328p has only one usart which I leave for debugging.. other is that i2c allows you to work in a mode where the data is requested from the gps when needed (i.e. when transmission of previous sentence is complete)
[08:18] <daveake> So $ = clear buffer
[08:18] <daveake> LF = set flag for main loop to parse
[08:18] <ibanezmatt13> Right yes, at the moment I just loop around checking to see if there's any data coming in
[08:18] <Vaizki> and while flag is set don't touch the buffer, main loop clears flag when it's done
[08:19] <Vaizki> remember to set those flags as "volatile" :)
[08:20] <ibanezmatt13> I read something about if you don't set the ISR variables as volatile, it may be optimised out so you can't access it or something
[08:20] <ibanezmatt13> I didn't understand that point
[08:20] <Vaizki> yea the compiler optimizes for example your main loop
[08:20] <mfa298> using the ISR to recieve the data potentially means you can put the main loop to sleep until you've got something for it to do
[08:20] zsentinel (~zsentinel@unaffiliated/zsentinel) left irc: Ping timeout: 256 seconds
[08:20] <Vaizki> so let's say you check the value of the flag.. the compiler may have optimized it to keep it in a register
[08:21] <Vaizki> if you change it in the ISR it changes in memory but not in the register
[08:21] <Vaizki> so the main loop doesn't see the change
[08:21] <Vaizki> volatile tells the compiler that the variable may change at any time due to an external event (like ISR)
[08:21] <Vaizki> so it is not allowed to optimize out reads from memory etc
[08:22] <ibanezmatt13> ah I see
[08:22] <ibanezmatt13> quite important then
[08:22] <luteijn|pc1pcl> e.g. while ( FLAG ) sleep 1 ;
[08:22] <Vaizki> yea. in that case the compilr would load FLAG into a register and loop indefinitely
[08:23] <luteijn|pc1pcl> if not marked as volatile the compiler might just optimize to 'while ( TRUE ) sleep 1'. as it doesn't see anyhting that could ever change the flag
[08:23] zsentinel (~zsentinel@unaffiliated/zsentinel) joined #highaltitude.
[08:23] <ibanezmatt13> ah yeah
[08:23] <ibanezmatt13> makes sense
[08:23] <ibanezmatt13> reading about the circular buffer
[08:24] <ibanezmatt13> as a way of storing stuff coming in from uart
[08:25] <Vaizki> yes that's the normal way of doing comms buffers.. but in case of NMEA (and especially i2c) you know how long those sentences are going to be.. so not sure if it's worth it.
[08:25] <luteijn|pc1pcl> few ways of handeling stuff coming in. Either you have GPS spew the 'current' locatino continuosly, and when you actually are ready to use the position, you have the latest one there waiting for you. Lot of work potentially wasted if you get 2 readings per second but only send out one positon over radio per 20 seconds.
[08:26] <Vaizki> as daveake said, when you get a $, just set the rx pointer where you put bytes to the start of the buffer
[08:26] <Vaizki> and check that you don't receive more bytes than the length of the buffer. on LF stop filling th ebuffer and set the flag for the main loop to process it.
[08:26] <ibanezmatt13> yep
[08:26] <ibanezmatt13> good point luteijn|pc1pcl
[08:27] <luteijn|pc1pcl> if you do it the Vaizki/Daveake way, you need a bit less buffer, but might use a pretty stale position..
[08:27] <day> Vaizki: the gps send only on request works with usart as well
[08:27] <daveake> Something wrong if the main loop is that slow
[08:27] <Vaizki> ok good to know
[08:27] <luteijn|pc1pcl> if you do it the Vaizi,i2C way, you don't jsut do work on gps when you actually can use the output directly.
[08:28] <Vaizki> huh?
[08:28] <Vaizki> parsing error :)
[08:28] <day> but true, better to use something else than usart. that way the most compatible interface is free for other tasks
[08:29] <ibanezmatt13> hm ok. I think I'll get it working with the uart for now, then explore alternatives
[08:29] <ibanezmatt13> just planning on transitioning from .ino to .c really
[08:29] <fsphil> the .ino thing is silly. it's just c++
[08:29] <day> how do you work in general? do you build the board first, then start programming with the prototype? Or do you prototype first and then build the pcb?
[08:30] <ibanezmatt13> prototype first I'd say
[08:30] <Vaizki> I only have a breadboarded prototype so far myself, been engaged in other stuff :P
[08:30] <ibanezmatt13> I get something up on a breadboard first if I have some chips lying around, then once the code's ok, I'll look at doing it properly
[08:30] <Vaizki> oh and I do have a board laid out but not ordered yet :)
[08:31] <luteijn|pc1pcl> daveake: Scenario: at t=0 you use whatever position is in your buffer and clear the flag, so while you're sending out the position at 50 bps, the ISR fills it with the GPS poitoin of say t=1, and sets the flag again. at =20 your radio loop is done and you get the now slightly old postion from the buffer into the new sentence, clear the flag,and start working on sending that out
[08:31] <day> well ive never ordered a pcb, thinking it is too expensive. but a small dual sided board costs 10bucks for 3 pieces :P
[08:31] <luteijn|pc1pcl> of course you could not clear the flag until done radioing out and ready to build the next sentence.
[08:31] <Vaizki> ^-- that
[08:31] <Vaizki> the messages come in at 1Hz
[08:31] <daveake> Yes
[08:32] <daveake> Radio is just one customer for the GPS data
[08:32] <daveake> And will get a reading up to 1 second old
[08:32] <luteijn|pc1pcl> but then you might lose lock at t=8, and not have a positoin at all at t=20 (or the same one from t=0)
[08:32] <daveake> lost-lock ones won't get stored
[08:32] <daveake> The radio will always have the latest good data
[08:33] <Vaizki> yea I am wasting memory by having dual buffers for the radio to send out.. so radio always has a complete good sentence which it will keep sending indefinitely from the ISR unless the main loop points it to the other buffer
[08:34] <Vaizki> just in case I manage to make a bug in the main loop and it hangs...
[08:34] <Vaizki> of course you will see from the timestamp and seq number when it got stuck if that ever happens
[08:34] <luteijn|pc1pcl> which is what my approach would probably be too.
[08:35] <ibanezmatt13> that sounds like a good way to do it
[08:35] <Vaizki> ibanezmatt13, and it's easier if you don't use Arduino libs because those libs can be a bit memory bloaty
[08:35] <ibanezmatt13> yeah
[08:35] <Vaizki> especially if you envision putting in an SD card
[08:36] <ibanezmatt13> Yeah I had one on the last flight :)
[08:37] <ibanezmatt13> So, the GPS sends over the uart at 1Hz. If the radio interrupt fires while the RXC interrupt is firing very often for a short while, I know the running interrupt isn't affecting, but is it not likely to delay the radio enough to cock up the baud rate?
[08:38] <luteijn|pc1pcl> it will mess with the baud rate, but likely not enough to matter.
[08:39] <ibanezmatt13> right, and I can always stop it continuously sending stuff and just ask it to when I need, and then let the interrupt do its work
[08:40] <mfa298> if it seriously affects the 50baud tx you're doing too much in the ISR
[08:41] <mfa298> ISR's are generally supposed to be fairly quick to run
[08:41] <ibanezmatt13> yeah, and if I went for 300 baud say, it's even more likely to be a problem
[08:42] <daveake> yeah first rule of an ISR - don't do anything in it :)
[08:42] <Vaizki> if your ISRs are (like they should) just moving a few bytes and setting I/O pins it's not going to be a problem
[08:42] <luteijn|pc1pcl> might still not matter enough, depending on how much the RX interrupts mess with your timing mechanism used for the radio interrupts. etc.
[08:44] <ibanezmatt13> Right, I'll keep it short then. I've gotta look at how I want to store the data that comes in
[08:45] <luteijn|pc1pcl> if you do something like 'sent a timing interrupt every fricosecond so I can count off the time left to keep pin X high for this bit to be send out completely' the effect is likely to be different than if you do something like 'Ok, set pin X high, need to switch it off in X bogoseconds, let me know when these have elapsed'
[08:45] <ibanezmatt13> yeah it will
[08:46] <Vaizki> your uart RX ISR only needs to do a rxbuf[rx_head++] and then check if rx_head is going past the buffer size
[08:46] <Vaizki> so it's not going to take a lot of time
[08:46] <luteijn|pc1pcl> but looks like you are aware of the issues, so you can test your stuff appropriatly to see if things go wrong.
[08:46] <Vaizki> but again as daveake said, it's a good idea to add in the $ / LF detection to allow your main loop to basically ignore the buffer until ready
[08:48] <ibanezmatt13> yeah. Next I'm gonna have a think about where to declare the rxbuff and how I'm gonna be using pointers etc between the functions and ISR
[08:49] <luteijn|pc1pcl> Since this is basically an embedded project, I think I wouldn't bother with some of the 'proper' practices as used in 'normal' programming.
[08:50] <Vaizki> ibanezmatt13, not my code but google came up with http://www.avrfreaks.net/comment/316230#comment-316230
[08:50] <Vaizki> seems pretty compact for a starting point
[08:52] <ibanezmatt13> I think I'm just gonna have a think about it first and try some stuff. I'll have a look if I make little progess, but I managed to set up my own interrupt driven uart yesterday :D
[08:52] <luteijn|pc1pcl> so: global static buffers with enough room.
[08:52] <ibanezmatt13> ooh it's for a circular buffer too... must not look yet :P
[08:52] <Vaizki> sure. sometimes 10 lines of code will allow you to see the problem which you didn't notice in 10 pages of datasheet :)
[08:53] <Vaizki> I don't think you need a circular buffer tbh, just makes parsing harder. NMEA is a special case (defined start and end characters) so just abuse that.
[08:53] <ibanezmatt13> yeah definitely, I'm getting more used to scouring the datasheets now, looking at how to use the different registers and looking at the interrupt vector table etc
[08:54] <ibanezmatt13> ok yep
[08:54] <daveake> yeah don't do ciircular fot this
[08:54] <daveake> it'll do your head in
[08:54] <luteijn|pc1pcl> a double buffer or even a single one should be enough for incoming gps data.
[08:54] <Vaizki> that said, I am a big fan of UBX (as opposed to NMEA). saved me all the parsing pain.
[08:54] <ibanezmatt13> ok. Is declaring something in main() global?
[08:55] <Vaizki> no
[08:55] <luteijn|pc1pcl> nope local to main
[08:55] <ibanezmatt13> so has to be outside of the functions then
[08:55] <luteijn|pc1pcl> so put it above that.
[08:56] <luteijn|pc1pcl> set up some flag variables to act as semaphores so your differnt processes know when a shared variable can be written too safely or not.
[08:57] <Vaizki> oh and since you are doing multi-object projects now (multiple .c files compiled into .o files then linked together), you can restrict how globals are seen across the project
[08:57] <Vaizki> if you declare a global variable with "static", it's only seen inside that file/module
[08:57] <ibanezmatt13> oh yeah this is something I've been interested in. I've always only ever had to compile single .c files
[08:57] <Vaizki> if you don't, the linker will expose it to all modules
[08:58] <ibanezmatt13> I thought static was so you can declare a variable in a loop and it won't keep creating more instances of it
[08:58] <Vaizki> well not exactly
[08:58] <luteijn|pc1pcl> always confused about what static does there myself. I think itwas used here to make sure the initial value is 0 as a side effect.
[08:59] <Vaizki> in a local scope (anything not global), it basically means declaring a global but only accessible from that scope
[08:59] <Vaizki> so it will be the same variable between function calls and also in recursive calls
[09:00] <Vaizki> and if you initialize like: static int loop = 0; that initialization is not run every time the scope is entered, only once
[09:00] <Vaizki> just like globals again
[09:00] <ibanezmatt13> oh I see
[09:01] <Vaizki> in a GLOBAL variable, the static keyword is used to restrict scope to that module
[09:01] <Vaizki> so it's global to the planet foo.c, not global to the universe :)
[09:01] <ibanezmatt13> yes
[09:02] <Vaizki> the good thing is, modern compilers do spout warnings about a lot of these things
[09:02] <ibanezmatt13> if you needed it global to the universe then, you couldn't put static, which means you couldn't initialise the variable inside a function or loop?
[09:02] <Vaizki> DO read warnings. use -Wall if you can. fix the warnings even if they're harmless.
[09:03] <Vaizki> #pragma out warnings you are 100% sure are not needed and can't be "fixed" otherwise
[09:03] <Vaizki> ibanezmatt13, it just controls scope of that name
[09:04] <Vaizki> if you don't need the variable outside of the single .c file, just declare it static
[09:04] Herman_ (535426fa@gateway/web/freenode/ip.83.84.38.250) joined #highaltitude.
[09:04] <Vaizki> we're going in a bit deep here again :D
[09:04] <jonsowman> yeah otherwise you'll make yourself seriously sad when there are name clashes between files and weird things happen
[09:04] <ibanezmatt13> yeah, I'd better just get on with it now :)
[09:04] <jonsowman> trust me
[09:04] <Herman_> !flights
[09:04] <SpacenearUS> 03Herman_: Current flights: 030x07 - Pico Flight 10(8ca0), 03FERRER1 10(de19)
[09:04] <jonsowman> source: bitter experience
[09:05] DL7AD (d95cb146@gateway/web/freenode/ip.217.92.177.70) joined #highaltitude.
[09:06] <Vaizki> jonsowman, I think modern compilers should warn you at least. modern gcc may even error out?
[09:06] <luteijn|pc1pcl> everything using these globals should probably fit within one file anyway, or the idea that you can use globals safely because you have the entire environment ot yourself and understand everyhting tht is happening anyway is not valid.
[09:07] <Vaizki> because if you intend to do it, you should "extern" it from the other file
[09:07] <jonsowman> Vaizki: it didn't, I spent a while looking into this
[09:07] <jonsowman> even with -pedantic
[09:07] <Vaizki> damn
[09:07] <jonsowman> no warnings
[09:07] <Vaizki> ayeegh :O
[09:08] <jonsowman> lesson very much learned though hah
[09:08] <luteijn|pc1pcl> might also only become obvious when linking and even then seem valid, so you'd get runtime misery as jonsowman experienced.
[09:09] <jonsowman> yeah it'd be the linker that could catch it
[09:11] <Herman_> GM all
[09:11] <Herman_> does anyone know the frequency of F5KAV-11
[09:12] <mfa298> Herman_: the -11 would suggest it's APRS
[09:12] <Herman_> ye but i hrd nill here on 144.800
[09:12] fxmulder (~fxmulder@unaffiliated/fxmulder) left irc: Remote host closed the connection
[09:13] fxmulder (~fxmulder@unaffiliated/fxmulder) joined #highaltitude.
[09:13] <luteijn|pc1pcl> I think it is just F5KAV using the 11 to relay positions from (daily?) weaher probes via aprs network (probably even IP only, not even on the air)
[09:13] <luteijn|pc1pcl> so F5KAV would be the one to ask at which frequency he is receiving the probetelemetry, and what he uses to decode it and convert to aprs.
[09:14] <luteijn|pc1pcl> F5KAV is actually a club call I think https://github.com/jwrdegoede/u-boot-sunxi.git u-boot
[09:14] <luteijn|pc1pcl> bleh wrong link.
[09:14] <luteijn|pc1pcl> http://www.f5kav.org/
[09:15] <luteijn|pc1pcl> on their activities subpage they lis something about balloonhunting:
[09:15] <luteijn|pc1pcl> - Ballons Sondes - La chasse aux ballons sondes, les ballons sondes sont des ballons experimentaux du C.N.R.S bourrés de capteurs atmosphériques afin d'étudier notre environnement, notre mission consiste à suivre et récuperer le ballon lors de son "atterrissage" soit par radio-goniometrie ou avec le système A.P.R.S.
[09:15] <Vaizki> Habhub should not import those I think. Filtering is not catching it.
[09:16] <luteijn|pc1pcl> (pardon my french ;) )
[09:16] <Herman_> luteijn|pc1pcl: tnx info but my france is not ok hihihihihi
[09:17] <luteijn|pc1pcl> that just says that they hunt balloon sondes, using radiotriangulation or with APRS
[09:18] <Herman_> ok
[09:19] <luteijn|pc1pcl> you could try and beat them to the landing location based on the info relayed via APRS, and either just snatch the radiosonde away before them, or try and get them to talk to you about their activity, but maybe just mailing them if they wnat to share some info would work better ;)
[09:19] <ibanezmatt13> is LF just '\n' ?
[09:20] <luteijn|pc1pcl> ibanezmatt13: yes.
[09:20] <ibanezmatt13> ok thanks
[09:20] <luteijn|pc1pcl> (for certain values of yes and the context, ofcourse)
[09:20] <Vaizki> it moves the printer paper one line forward
[09:21] <luteijn|pc1pcl> might make sense to run gps data through hex/octal dumper to check the exact format.
[09:22] <Vaizki> I think he has a saelea
[09:22] <ibanezmatt13> yeah, I'll just grab it with the logic analyser
[09:23] <ibanezmatt13> bit stuck really. Need an interface to convert the logic levels down so I can use the uart with the PC too, can't really send stuff to it currently unless I get the GPS itself hooked up
[09:23] nv0o_david (~dwhite152@c-67-162-187-71.hsd1.mo.comcast.net) joined #highaltitude.
[09:24] edmoore (~ed@130.255.28.247) joined #highaltitude.
[09:24] <craag> ibanezmatt13: You could voltage divide the 5V Serial TX to go into a 3.3V UART input
[09:24] <ibanezmatt13> ah yeah that's a good idea
[09:25] <craag> And 3.3V is above the logic-high threshold for modern 5V logic, so the other way jsut works
[09:25] <daveake> 5V is so 1980
[09:25] <mfa298> or buy a 8MHz xtal (or just use the internal osc) and run on 3v3
[09:25] <craag> although I tend to put a 1K or so in series to make sure things don't go poof
[09:25] <luteijn|pc1pcl> or maybe the UART is already 5 volt safe/tolerant?
[09:26] <ibanezmatt13> I read that the uart needed a stable clock and didn't know if the int osc was good enough; if I had any 8Mhz external xtals I would have done
[09:26] ProSpectre (ProSpectre@95.91.93.163) joined #highaltitude.
[09:26] <craag> this is for a hab payload right?
[09:26] <mfa298> for intial parsing you only need the gps tx -> avr rx, (and could potentially connect avr tx -> PC rx)
[09:26] <daveake> use a xtal
[09:27] <ibanezmatt13> eventually yeah, just playing about really at the minute
[09:27] <daveake> -40C may make the baud rate sad
[09:27] <Vaizki> With internal osc at 8MHz and 3.3V .. I saa having done usart and i2c issues at higher rates. Recommend an xtal.
[09:27] <ibanezmatt13> yeah
[09:27] <Vaizki> Having some
[09:28] <edmoore> 3rd/4th the xtal
[09:28] <mfa298> I've been ok with 9600 and 19200 baud off the internal osc on a 324, There's a table somewhere that can help you choose, some baud rates are quite a way off at certain clock rates
[09:28] <edmoore> you can get temperature-compensated xtals too if you really need soemthing stable
[09:29] <mfa298> (xtal is wired up but not set fuses for it yet)
[09:29] <Vaizki> Fly an ocxo
[09:31] <edmoore> no don't do that
[09:31] <Vaizki> yea sorry joke :)
[09:32] <craag> or just a gpsdo
[09:32] <craag> as has been done ;)
[09:32] <edmoore> unless you know a tcxo isn;t good enough, a tcxo is good enough
[09:32] <craag> aye
[09:33] <ibanezmatt13> yep, starting having a go at an ISR for the UART RX http://pastie.org/10284019
[09:33] <ibanezmatt13> might be a load of rubbish, not finished :P
[09:34] <ibanezmatt13> might be worth having a flag to tell the main program when a new sentence has finished being stored
[09:36] <edmoore> that thought might link in the with circular buffer stuff i was telling you about
[09:36] <ibanezmatt13> yeah
[09:37] <edmoore> so as a rule (and this links in with cdev) it's a good idea to just handle an interrupt as quick as possible, then get out
[09:37] <edmoore> don't do program logic/parsing in the ISR
[09:38] <edmoore> sorry cdev = char device = what i actully call my little utility i use with avr asynchronous comms that is basically just a circular buffer
[09:38] Laurenceb_ (~Laurence@host86-167-154-25.range86-167.btcentralplus.com) joined #highaltitude.
[09:39] <ibanezmatt13> yes, but it might be worth doing a tiny bit of checking in there rather than just getting the byte from the register then putting it somewhere for the other bits of the program to see it?
[09:39] Herman_ (535426fa@gateway/web/freenode/ip.83.84.38.250) left irc: Quit: Page closed
[09:39] <edmoore> maybe, if you're really short onr esources
[09:39] <edmoore> i just lob it into a buffer and then have the main program parse the buffer at its leisure
[09:40] <ibanezmatt13> yeah I'll probably try a few different ways
[09:44] <Vaizki> the rxbuff could be a static unsigned char rxbuff[100];
[09:45] <Vaizki> and what the r++? I think you mean pos++
[09:45] <ibanezmatt13> yeah that should be a pos++ :P
[09:45] <ibanezmatt13> edmoore, if the ISR just puts the incoming byte somewhere else, and something happened in your main program that checks that location, surely you're at risk of overflowing in that location?
[09:46] <ibanezmatt13> I suppose a little check in the ISR wouldn't hurt actually
[09:46] <Vaizki> ibanezmatt13, and in the $ check, just set pos = 1 .. now you are relying on a \n to reset it to zero.
[09:46] <edmoore> yes you are ibanezmatt13
[09:46] <edmoore> but ISR's dont alter that
[09:46] <Vaizki> in case there are errors and your buffer overflows, it may not be zero at $
[09:46] <edmoore> please just look up circular buffers
[09:46] <edmoore> you're going to invent them yourself at this rate
[09:47] <ibanezmatt13> ok :P
[09:47] <Vaizki> we just told him not to use them :)
[09:47] <edmoore> they are the right kind of data structure for lobbing this thing into, and handling what happens when you overflow, and so on
[09:47] <edmoore> oh did you?
[09:47] <edmoore> why?
[09:47] Action: ibanezmatt13 confused
[09:47] garymortimer (9a49dfc7@gateway/web/freenode/ip.154.73.223.199) joined #highaltitude.
[09:48] <Vaizki> yea me and daveake.. because he knows the max length of his buffer and that he can just clear the buffer on a $
[09:48] <Vaizki> and parse on a \n
[09:48] <Vaizki> I mean max length of his NMEA sentence
[09:48] <edmoore> oh, sure
[09:49] <edmoore> so i guess for specifically nmea in this case, ok
[09:49] <edmoore> i just use circ buffs as in general they seem to be the right solution to the asynchronous io problem
[09:50] Guest90769 (~xfce@cpe-85-10-26-137.dynamic.amis.net) left irc: Ping timeout: 240 seconds
[09:51] <ibanezmatt13> so when they get full, you overwrite the first byte in the buffer and go back round overwriting, which saves you from overflow, but means you wanna start the sentence at the start of the buffer, and also you need to read it before the next lot comes in?
[09:52] <edmoore> yes
[09:52] <Vaizki> in a circular buffer the the next sentence just starts where the previous one ended and then it wraps to the start
[09:52] <Vaizki> so when reading the data out in the main loop you often have to splice it together from the end of the rx buffer and the start
[09:53] <ibanezmatt13> can you not just force it to start writing at the start of the buffer when it gets a $ ?
[09:53] <Vaizki> yes and that's what you're doing
[09:53] <ibanezmatt13> ah ok
[09:53] <Vaizki> that's not a circular buffer though :)
[09:53] <Vaizki> so put in a pos = 1 in your code where you get a $
[09:54] <Vaizki> now you have pos++ and are assuming that pos = 0 which it may not be
[09:54] <Vaizki> if you overflow the buffer (the \n gets garbled), your code will reset to pos = 0 but it may keep receiving characters
[09:55] <Vaizki> so pos may end up being for example 7 when you get a $
[09:55] <ibanezmatt13> yeah that's a bit rubbish really isn't it
[09:55] <Vaizki> yes :)
[09:57] <Vaizki> oh and one more bug.. sorry :)
[09:57] <Vaizki> your (pos >= 98) check can't be an else if
[09:57] <SpacenearUS> New position from 03DK3SB-7 after 03a day silence - 12http://tracker.habhub.org/#!qm=All&q=DK3SB-7
[09:58] malgar (~malgar@151.44.40.49) joined #highaltitude.
[09:59] <Vaizki> the check should be in the block where you stuff bytes into the buffer, now you are only checking it when incoming != 1
[10:00] <ibanezmatt13> yeah it won't ever get executed will it
[10:00] <Vaizki> you got it
[10:01] in3aqk (4f326c5d@gateway/web/freenode/ip.79.50.108.93) joined #highaltitude.
[10:01] <Vaizki> since you have a saleae, I also recommend you can use some extra GPIO output pins for debugging
[10:01] <Vaizki> like for example set a pin HIGH when incoming = 1 etc
[10:02] <Vaizki> that way you can see from the logic analyzer both the traffic and the internal state of the ISR
[10:02] <Vaizki> because what you DON'T want to do EVER is print out to a serial port from an ISR
[10:03] Laurenceb_ (~Laurence@host86-167-154-25.range86-167.btcentralplus.com) left irc: Ping timeout: 252 seconds
[10:03] <ibanezmatt13> right yeah
[10:08] <Vaizki> I now have a 4 channel scope and a saleae, it's amazing how much easier some things are to debug..
[10:09] <Vaizki> my vacation project is to fix the radar on my boat. also should take care of sterilization....
[10:09] <jonsowman> enjoying your ds1054z Vaizki?
[10:09] <edmoore> also you have a scope
[10:09] <edmoore> use that
[10:09] <edmoore> that's live
[10:09] <Vaizki> jonsowman, oh very much
[10:10] <jonsowman> me too
[10:10] <jonsowman> :D
[10:10] <edmoore> i'm loving my mdo3104 too
[10:10] <edmoore> thanks for asking
[10:10] <jonsowman> haha
[10:10] Action: edmoore looks smugly around
[10:10] <Vaizki> edmoore, showoff :D
[10:10] nv0o (~dwhite152@c-67-162-187-71.hsd1.mo.comcast.net) joined #highaltitude.
[10:10] <ibanezmatt13> already on it edmoore
[10:10] <edmoore> it is really bloody nice though
[10:10] <jonsowman> i'd be smug too if I had one
[10:10] <edmoore> awesome ibanezmatt13
[10:10] <edmoore> should have known
[10:10] <edmoore> sometimes i take it to club
[10:10] <edmoore> clubs
[10:11] <ibanezmatt13> not using it to decode though, just to see tx is doing something
[10:11] <edmoore> yeah that's fine
[10:11] in3aqk (4f326c5d@gateway/web/freenode/ip.79.50.108.93) left irc: Ping timeout: 246 seconds
[10:13] garymortimer (9a49dfc7@gateway/web/freenode/ip.154.73.223.199) left irc: Ping timeout: 246 seconds
[10:13] nv0o_david (~dwhite152@c-67-162-187-71.hsd1.mo.comcast.net) left irc: Ping timeout: 240 seconds
[10:14] <ibanezmatt13> so you have a pointer which points to the start of this circular buffer, and each time you get a byte, you get it from the reg and put it in the position of the next increment of the pointer
[10:14] <jonsowman> yep
[10:14] <edmoore> and another pointer for where you're read too
[10:14] <Vaizki> jonsowman, have you hacked your 1054z?
[10:15] <jonsowman> Vaizki: I've not actually, have you? (100MHz?)
[10:15] <edmoore> and you can do thinks like fire an interrupt if the write pointer tries to overtake the read pointer
[10:15] <Vaizki> nope I haven't, I still have a bit of trial time left on all the nice measurement funcs etc
[10:15] <edmoore> or you can just not let it lap it and say it has to wait for you to read
[10:15] <edmoore> that's a design decision
[10:16] <ibanezmatt13> I thought the read pointer is separate to the writing all together
[10:16] <ibanezmatt13> like, in the main program
[10:16] <jonsowman> the pointers are different
[10:16] <Vaizki> well the write ISR should know the read pointer to avoid overruns
[10:16] <jonsowman> but they interact in that you don't want the tail to overtake the head
[10:16] <jonsowman> tail=read, head=write
[10:16] <jonsowman> sorry, jargon
[10:16] <Vaizki> the snake eating its own tail ;)
[10:17] <jonsowman> yes, very bad. snake becomes disfunctional
[10:17] <jonsowman> *dys
[10:17] <ibanezmatt13> hm, so you mean you want to prevent it writing over what it's not already read?
[10:17] <ibanezmatt13> or the other way round
[10:17] <jonsowman> correct
[10:17] <ibanezmatt13> well the other way round is fine
[10:17] <edmoore> well
[10:17] <ibanezmatt13> ok
[10:17] <edmoore> i disagree
[10:17] <edmoore> depends on the application
[10:18] <edmoore> sometimes it's best to have the latest received stuff in the buffer
[10:18] <edmoore> sometimes it's more important to miss the more recent stuff in favour of processing the stuff still in the buffer
[10:18] <edmoore> it's application-specific
[10:18] <jonsowman> true
[10:18] <ibanezmatt13> I see
[10:18] <edmoore> probably in a hab you want the most recent gps position
[10:19] <edmoore> i mean, also in a hab, there's so little to do computing-wise that you shouldn't find yourself in a position where you can't keep up with the gps buffer anyway
[10:19] <edmoore> but in a more general sense, what to do on a head/tail collision is somewhat a function of the application
[10:19] <ibanezmatt13> right
[10:20] <ibanezmatt13> I'm gonna go make coffee, and probably draw out some buffers. I'm struggling to visualise it
[10:20] <jonsowman> wise
[10:20] <edmoore> whiteboards are best for this kind of thing
[10:22] <ibanezmatt13> hey edmoore, the contents of my whiteboard after the 5 year old brother tries to design aircraft http://gyazo.com/e3f1adb8de9107830c9aa20e7df34971
[10:22] <edmoore> start him young!
[10:23] <ibanezmatt13> top down view and everything
[10:23] <ibanezmatt13> and a couple of bytes when I was going through the painful process of learning how bitwise ops work
[10:24] DL7AD_ (d95cb146@gateway/web/freenode/ip.217.92.177.70) joined #highaltitude.
[10:25] DG0MG (~DG0MG@p54B48CE7.dip0.t-ipconnect.de) joined #highaltitude.
[10:27] DL7AD (d95cb146@gateway/web/freenode/ip.217.92.177.70) left irc: Ping timeout: 246 seconds
[10:31] <ibanezmatt13> so the main program has to be reading it while the interrupt is writing to it. You can't have the ISR finish writing to it and *then* read it, unless you temporarily disable interrupts with cli(), but that's defeating the whole object of a circular buffer
[10:32] Nick change: DL7AD_ -> DL7AD
[10:37] <Vaizki> I still feel going with circular buffers etc means adding a layer of complexity to your project that you don't need.. I agree fully with edmoore that it's the go-to method for general asynchronous comms but in this specialized case you are just adding pain on both ends of the pipeline (filling the buffer and reading it)
[10:38] <Vaizki> and no, don't cli() for anything except changing timer settings etc :)
[10:38] <ibanezmatt13> might have to learn it at some point though :)
[10:38] malclocke (~malc@60-234-172-149.bitstream.orcon.net.nz) left irc: Ping timeout: 256 seconds
[10:38] <ibanezmatt13> yeah that was a stupid suggestion, radio would stop
[10:43] <Vaizki> get something working for all areas of the project across the board, then optimize :)
[10:46] Guest90769 (~xfce@cpe-85-10-26-137.dynamic.amis.net) joined #highaltitude.
[10:52] in3aqk (4f326c5d@gateway/web/freenode/ip.79.50.108.93) joined #highaltitude.
[11:01] <luteijn|pc1pcl> I would use two buffers, and have GPS service routine fill one of them, and not mess with the other. The TX routine would use one of another pair of buffers containing a 'ready to send' sentence
[11:02] <luteijn|pc1pcl> and somethign else would be building a new 'ready to send' sentence up in the buffer not currently used by the TX routine, with information from the buffer that the GPS routine isn't using at the moment.
[11:04] <luteijn|pc1pcl> add a couple of semaphores to make it possible to switch buffers being written to and ones that 'safe for use by 3rd party' around.
[11:06] <ibanezmatt13> Yeah, I'm not quite getting the whole idea of buffers at the moment. Gonna take a break for a few h I think, often helps with new things like this
[11:30] ProSpectre (ProSpectre@95.91.93.163) left irc:
[12:05] Adam012 (b07ee212@gateway/web/freenode/ip.176.126.226.18) joined #highaltitude.
[12:06] <Adam012> Hi All!
[12:07] pjm (~pjm@uhfsatcom.plus.com) joined #highaltitude.
[12:08] <DL7AD> hi Adam012
[12:08] <Adam012> Just a heads up that we're launching our Sun Chaser probe at 2am tomorrow ;)
[12:09] <Adam012> Hopefully have some good footage coming out later in the day.
[12:09] <Adam012> We'll be live tweeting: https://twitter.com/horizonqmgs
[12:09] <UpuWork> I'll be live sleeping
[12:10] <daveake> Do you know what happened last time? Didn't one of the trackers stop working?
[12:11] <Adam012> @upu ;)
[12:11] <Adam012> The balloon got caught by a gust (coastal launches, just say no!) and dashed the payload box against a very solid fence post on takeoff.
[12:13] Ojo_2 (~pieter@c-24-30-12-2.hsd1.ga.comcast.net) joined #highaltitude.
[12:13] <UpuWork> launch in Winter
[12:14] Ojo (~pieter@c-24-30-12-2.hsd1.ga.comcast.net) left irc: Ping timeout: 248 seconds
[12:14] <Adam012> By a stroke of bad luck it knocked out one of the cameras (a sleepy team member had forgot to turn the other camera on) and repositioned the GoPro so its lens was partially obscured. The load above the flight computer shifted - turning its battery pack off. The Americans have a term for this apparently: a 'clu***r f**k'.
[12:14] <adamgreig> "charlie foxtrot" in polite company
[12:15] <Adam012> Winter? Been there, done that - a tool bag froze against the helium cannister it was leaned against as we were filling the balloon. Had to waste good hot coffee getting them apart.
[12:15] <craag> lol
[12:21] <Adam012> Thanks everyone. Will be posting photos and video to twitter at a more sensible time (midday/afternoon).
[12:22] <Adam012> Right, I'm driving so I best get to bed. Wish us luck!
[12:22] <SpeedEvil> Night
[12:22] <SpeedEvil> Goog luck
[12:22] <craag> good luck!
[12:22] Adam012 (b07ee212@gateway/web/freenode/ip.176.126.226.18) left #highaltitude.
[12:29] in3aqk (4f326c5d@gateway/web/freenode/ip.79.50.108.93) left irc: Quit: Page closed
[12:35] <daveake> Philae link is back up https://twitter.com/DLR_en/status/619483893280940032
[12:38] <UpuWork> trying to steal NH thunder
[13:04] <Geoff-G8DHE-Lap> I'll leave it running tuned in so hope the freuency is accurate ;-)
[13:10] Nick change: fl_0 -> fl_0|afk
[13:12] <x-f> !dial Philae
[13:12] <SpacenearUS> 03x-f: Can't find a flight doc matching your query
[13:13] <x-f> probably expired
[13:13] <DL7AD> x-f: on which frequency should it be?
[13:13] <craag> They'd have to owe habhub a pint for filing the flight doc after launch :P
[13:14] dl3yc (~yc@p4FCF7927.dip0.t-ipconnect.de) joined #highaltitude.
[13:14] <x-f> DL7AD, no idea :)
[13:16] <fsphil> rosetta's on 8421.7869 MHz, not sure about philae
[13:19] <Vaizki> :)
[13:19] <Vaizki> off to the island!
[13:22] goopypanther (~goopypant@goopypanther.org) left irc: Ping timeout: 246 seconds
[13:29] jamesfinlayson (4e949076@gateway/web/freenode/ip.78.148.144.118) joined #highaltitude.
[13:30] <jamesfinlayson> Hi, I work for a marketing company in London. I wondered if any would be interested, or could recommend anyone, that could help me, on a consultancy basis, with a project that involves a weather balloons/near space?
[13:31] <edmoore> yes there are a few people who will fly stuff up for cash
[13:31] <edmoore> if that's what you want
[13:32] <edmoore> if you honestly want something more on a consultancy basis, rather than just a straight launch service, have you any more details you can provide?
[13:32] BirdyNumNum (560e84c3@gateway/web/freenode/ip.86.14.132.195) left irc: Ping timeout: 246 seconds
[13:33] goopypanther (~goopypant@goopypanther.org) joined #highaltitude.
[13:34] <jamesfinlayson> it's a little more complicated and adventurous than a standard launch, but certainly a launch would be at the heart of it. I someone have my hands somewhat tied by an NDA as to what I can say publicly. I've previously been speaking to the guys at SentIntoSpace, but they're struggling due to the complexity
[13:34] <jamesfinlayson> any recommendations as to the best people to speak to would be gratefully received.
[13:36] Laurenceb (~laurence@vlsi1.eee.nottingham.ac.uk) left irc: Remote host closed the connection
[13:37] <edmoore> yes they're not as competant as people you'll find here (SiS)
[13:38] Laurenceb (~laurence@vlsi1.eee.nottingham.ac.uk) joined #highaltitude.
[13:38] <edmoore> rocketboy probably has the best track record of actually making fairly complicated launches work for comercial clients
[13:39] <edmoore> http://randomaerospace.com/Random_Aerospace/Welcome.html
[13:41] <jamesfinlayson> That's great - I'll get in touch with him. Thanks for the recommendation
[13:41] <mattbrejza> seems steve needs to get his page further up on google
[13:41] <mattbrejza> or perhaps hes happy as he is
[13:43] <edmoore> i don't think one lives for the opportunities to fly a pair of trousers into space
[13:43] <edmoore> so he might be happy as he is
[13:43] <daveake> hah no :)
[13:43] <daveake> he did some clothing once and said "never again" afterwards :)
[13:49] <UpuWork> Sendintospace don't even have a properly working tracker
[13:49] <UpuWork> radio tracker anyway
[13:49] <daveake> indeed
[13:51] <adamgreig> least of my issues
[13:51] <adamgreig> you should see the cord they supply
[13:51] <daveake> they took the word "rope" literally?
[13:53] <adamgreig> mmhm
[14:05] michal_f (~michal_f@84-10-62-166.static.chello.pl) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- \o/
[14:22] ibanezmatt13 (1f6989f5@gateway/web/freenode/ip.31.105.137.245) left irc: Quit: Page closed
[14:41] jamesfinlayson (4e949076@gateway/web/freenode/ip.78.148.144.118) left irc: Ping timeout: 246 seconds
[14:44] DL7AD (d95cb146@gateway/web/freenode/ip.217.92.177.70) left irc: Quit: Page closed
[14:44] ipdove (~ipdove@interclub.plus.com) left irc: Quit: Nettalk6 - www.ntalk.de
[14:45] edmoore (~ed@130.255.28.247) left irc: Read error: Connection reset by peer
[14:48] edmoore (~ed@130.255.28.247) joined #highaltitude.
[14:49] sumie-dh_ (~sumie-dh@gw.mediafactory.cz) left irc: Quit: = Huuurrrr durrrrr I'm gammalama
[14:51] ak4rp (~Thunderbi@152.66.80.23) joined #highaltitude.
[14:57] ibanezmatt13 (1f6989f5@gateway/web/freenode/ip.31.105.137.245) joined #highaltitude.
[14:58] <ibanezmatt13> when you use a timer, if the count register overflows before you get to checking it, does it automatically reset to 0, and hence leave you in a likely infinite loop?
[15:01] <adamgreig> it depends on the settings of the timer. but generally yes. that's why you tend to interrupt on the timer anyway
[15:02] <adamgreig> so when it reaches some value (or the top) it fires an interrupt and you deal with it
[15:03] <ibanezmatt13> yeah, thought so. Was sat here wondering why my LED wasn't working properly http://pastie.org/10284681
[15:03] <ibanezmatt13> took the timer code out and works fine
[15:03] <ibanezmatt13> gonna set an interrupt timer up instead
[15:04] <ibanezmatt13> actually i've already removed it in that, nvm :)
[15:07] zsentinel (~zsentinel@unaffiliated/zsentinel) left irc: Ping timeout: 240 seconds
[15:14] zsentinel (~zsentinel@unaffiliated/zsentinel) joined #highaltitude.
[15:26] ak4rp (~Thunderbi@152.66.80.23) left irc: Remote host closed the connection
[15:31] <ibanezmatt13> excellent. Got a chip sending a made up nmea sentence over uart at 1Hz using timer interrupt
[15:31] <ibanezmatt13> That can talk to my other chip which will run the hab code in development :P
[15:32] <craag> nice :)
[15:33] Lemml (~andreas@p5080F5EC.dip0.t-ipconnect.de) left irc: Read error: Connection reset by peer
[15:34] <ibanezmatt13> le pics: http://pasteboard.co/1RbnzVzB.png and http://pasteboard.co/1RblfV5B.png :)
[15:45] DG0MG (DG0MG@p54B48CE7.dip0.t-ipconnect.de) left #highaltitude.
[15:47] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[15:48] <F5MVO> Hello all
[15:49] <F5MVO> fsphil: hello, i have a problem when i run sonde_to_aprs.py under windows xp with python 3.7.10
[15:49] <F5MVO> fsphil: hello, i have a problem when i run sonde_to_aprs.py under windows xp with python 2.7.10
[15:51] <F5MVO> fsphil: from pykml import parser : importerror: no module named pykml ?
[15:52] <F5MVO> fsphil: have you an idéa ?
[16:05] dokument (~dokument@cpe-72-182-50-56.austin.res.rr.com) joined #highaltitude.
[16:05] <daveake> "no module named x" means you have to install "x"
[16:05] <daveake> pip install pykml
[16:11] hEINstein (5ab86208@gateway/web/freenode/ip.90.184.98.8) joined #highaltitude.
[16:15] <F5MVO> daveake: hello, i am under xp, how to install pykml ?
[16:15] Nick change: fl_0|afk -> fl_0
[16:22] <daveake> Install pip if you haven't already
[16:22] <daveake> Then use pip to install pykml
[16:24] trn (jhj@trnsz.com) left irc: Ping timeout: 240 seconds
[16:25] <F5MVO> daveake, yes i try
[16:26] Lunar_Lander (~kevin@p5488881F.dip0.t-ipconnect.de) joined #highaltitude.
[16:27] <Lunar_Lander> hello
[16:28] trn (jhj@trnsz.com) joined #highaltitude.
[16:43] edmoore (~ed@130.255.28.247) left irc: Quit: This computer has gone to sleep
[16:45] SebastianFlyte (~sebf@pool-173-79-110-127.washdc.fios.verizon.net) joined #highaltitude.
[17:16] Nick change: Guest83753 -> spe
[17:18] Nick change: fl_0 -> fl_0|afk
[17:18] Nick change: fl_0|afk -> fl_0
[17:24] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left irc: Quit: Page closed
[17:30] gb73d (~gb73d@88-110-56-242.dynamic.dsl.as9105.com) joined #highaltitude.
[17:36] sumie-dh (~sumie-dh@rt02.komunikacnisite.cz) joined #highaltitude.
[17:36] malgar (~malgar@151.44.40.49) left irc: Quit: Sto andando via
[17:41] bertrik (~quassel@rockbox/developer/bertrik) joined #highaltitude.
[17:42] edmoore (~ed@82.6.148.64) joined #highaltitude.
[17:47] <ibanezmatt13> is it ok to connect the rx/tx of two chips at 5v together with no resistors?
[17:47] <edmoore> yep
[17:47] <ibanezmatt13> cool
[17:48] <ibanezmatt13> about to have a partial break through
[17:48] Nick change: fl_0 -> fl_0|afk
[17:48] <edmoore> if it's a really really long trace it can be wise to put a small resistor (100R say) or inductor in series, next to the end that drives the trace
[17:49] <ibanezmatt13> breadboard with jumper wires
[17:49] <edmoore> the reason is that a really long length of trace can look a bit like a capacitor, which can really abuse a pin trying to drive a line, and if it tries to drive it too fast you can get reflections off the other end, and all sorts. *however* this isn't a thing for a gps and micro next to each other on a small pcb
[17:50] <edmoore> (so the resistor/inductor stops that initial really large inrush of current on the rising edge)
[17:50] <ibanezmatt13> ah interesting
[17:50] <edmoore> but don't worry about it for this, but if you ever get into more high speed digital communications on pcbs then this is the sort of thing you have to worry about
[17:51] <ibanezmatt13> yep, my code's probably about to obliterate the two chips anyway
[17:51] <ibanezmatt13> edmoore, did you see these earlier: http://pasteboard.co/1RblfV5B.png and http://pasteboard.co/1RbnzVzB.png ?
[17:52] <ibanezmatt13> it's my dummy gps running at 1Hz :)
[17:52] <edmoore> nice work
[17:52] <edmoore> i like the gga message
[17:52] <edmoore> very much inkeeping with the nmea spec ;)
[17:52] <edmoore> once you think you have it working alright, deliberately send some garbled messages
[17:52] <ibanezmatt13> yeah. SO I've got 2 328s hooked up to each other, one's sending that at 1Hz, the other I'm hoping is gonna echo it so I can see it on serial
[17:53] <edmoore> just to see if your code can cope with errors of it it falls over
[17:53] <edmoore> or if*
[17:53] <ibanezmatt13> yeah will do. I must say, at the moment I don't think I fully understand the things that can go wrong, but will do in time
[17:53] <ibanezmatt13> i.e. in the next 3 seconds
[17:54] Action: ibanezmatt13 goes back to the drawing board...
[17:54] <ibanezmatt13> -_-
[17:54] <edmoore> so when you have a thing that parses gga messages, abuse it
[17:54] <ibanezmatt13> oh yeah I will, I'm not up to that stage yet though!
[17:54] <edmoore> do things like miss out some fields (say latitude) or put a random alphabet character in the altitude or something
[17:55] <edmoore> sure sure
[17:55] fearnor (~alex@69.31.40.107) left irc: Ping timeout: 248 seconds
[17:55] pretec (~Matthias@port-92-195-69-163.dynamic.qsc.de) joined #highaltitude.
[17:56] ibanezmatt13_ (1f6989f5@gateway/web/freenode/ip.31.105.137.245) joined #highaltitude.
[17:57] <ibanezmatt13_> I'll say that again: I'm still unsure about reading the stuff coming in from the uart into the parsing function
[17:58] <ibanezmatt13_> I fancied getting the ring buffer thing up and running, but it's temporarily defeated me
[17:59] <mattbrejza> if youre parsing nmea you can get away without a ring buffer
[17:59] ibanezmatt13 (1f6989f5@gateway/web/freenode/ip.31.105.137.245) left irc: Ping timeout: 246 seconds
[17:59] <ibanezmatt13_> yeah, was just trying it as something separate
[17:59] <mattbrejza> when you recieve '$' set the buffer ptr to 0, and when you get '\n' raise a flag
[17:59] <mattbrejza> ive only been vaguely following
[18:00] LazyLeopard (~irc-clien@chocky.lazyleopard.org.uk) left irc: Quit: Now QRT
[18:00] <ibanezmatt13_> so the main loop can do nothing until it gets the flag, then it reads the contents of that buffer into somewhere else
[18:00] <ibanezmatt13_> and then the uart interrupt can just overwrite the original buffer
[18:01] <ibanezmatt13_> I'll need something in the ISR to stop it from overwriting if the main program hasn't finished reading
[18:01] fearnor (~alex@69.31.40.107) joined #highaltitude.
[18:02] <mattbrejza> or you just need a bigger buffer?
[18:03] <mattbrejza> generally if you do something to stop the isr writing in the buffer it means youre gonna lose data
[18:03] <ibanezmatt13_> yeah it will
[18:04] K9JKM (~chatzilla@c-73-45-120-241.hsd1.il.comcast.net) joined #highaltitude.
[18:05] K9JKM (chatzilla@c-73-45-120-241.hsd1.il.comcast.net) left #highaltitude.
[18:11] kpiman_ (56ae8957@gateway/web/freenode/ip.86.174.137.87) joined #highaltitude.
[18:12] <ibanezmatt13_> good news! One chip is now echoing out the example nmea sentence coming from the fake gps :)
[18:21] es5nhc (~tarmo@108-40-71-217.static.internet.emt.ee) left irc: Remote host closed the connection
[18:43] DL7AD (~quassel@p4FD438B4.dip0.t-ipconnect.de) joined #highaltitude.
[18:46] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) joined #highaltitude.
[18:47] pjm_ (~pjm@uhfsatcom.plus.com) joined #highaltitude.
[18:49] pjm (~pjm@uhfsatcom.plus.com) left irc: Ping timeout: 248 seconds
[18:59] <DL7AD> evning
[19:02] ak4rp (~Thunderbi@netacc-gpn-204-58-103.pool.telenor.hu) joined #highaltitude.
[19:09] <SpacenearUS> New vehicle on the map: 03VALLEY - 12http://tracker.habhub.org/#!qm=All&q=VALLEY
[19:11] DG0MG (~DG0MG@p4FEC17F9.dip0.t-ipconnect.de) joined #highaltitude.
[19:26] [1]chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) joined #highaltitude.
[19:28] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) left irc: Ping timeout: 256 seconds
[19:28] Nick change: [1]chrisstubbs -> chrisstubbs
[19:35] Laurenceb_ (~Laurence@host86-167-154-25.range86-167.btcentralplus.com) joined #highaltitude.
[19:37] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) left irc: Read error: Connection reset by peer
[19:42] ak4rp (~Thunderbi@netacc-gpn-204-58-103.pool.telenor.hu) left irc: Ping timeout: 246 seconds
[19:43] Mark_B (56b20522@gateway/web/freenode/ip.86.178.5.34) joined #highaltitude.
[19:44] <Mark_B> Evevning
[19:44] <chimpusmaximus> Evening
[19:44] <Mark_B> Yep, that's the oneEvening
[19:44] <Mark_B> Fingers aren't working ...
[19:45] <Mark_B> Does anyone mind if I do a quick functional check on the tracker?
[19:45] <Mark_B> I want to send a couple of sentences to check the tracker
[19:45] <daveake> go ahead
[19:45] <Mark_B> Top, thanks
[19:46] <chimpusmaximus> Mark_B: i guess you have a flight from Elsworth tomorrow as well?
[19:46] <daveake> best to try to avoid active flights but even then doubtful it'll worry anyone
[19:47] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) joined #highaltitude.
[19:48] chris_99 (~chris_99@unaffiliated/chris-99/x-3062929) joined #highaltitude.
[19:49] DG0MG1 (~DG0MG@p4FEC26FB.dip0.t-ipconnect.de) joined #highaltitude.
[19:50] <Mark_B> Hi Chimpusmaximus, yep, that's the plan
[19:51] <chimpusmaximus> Excellent, sounds like a fair few tomorrow including yours and mine.
[19:52] DG0MG (~DG0MG@p4FEC17F9.dip0.t-ipconnect.de) left irc: Ping timeout: 244 seconds
[19:52] <Mark_B> Hmmmmm, not sure why MM6 isn't showing. digi is uploading OK
[19:52] <Mark_B> logtail says - no config doc. But, I've just filled one out
[19:54] <daveake> got the payload id wrong?
[19:54] goopypanther (~goopypant@goopypanther.org) left irc: Ping timeout: 256 seconds
[19:55] <SpacenearUS> New vehicle on the map: 03MM6 - 12http://tracker.habhub.org/#!qm=All&q=MM6
[19:55] <Mark_B> Doh
[19:55] <Mark_B> I didn't change the callsign in the sentence editor - basics
[19:55] <Mark_B> There she is
[19:56] <daveake> btdt
[19:57] <Mark_B> Llol
[19:57] <Mark_B> I love the internet, I just had to look up btdt. Every day is a school day :)
[19:58] chimpusmaximus (~Chris@host86-178-84-59.range86-178.btcentralplus.com) left irc:
[19:58] <daveake> :)
[19:59] chimpusmaximus (~Chris@host86-178-84-59.range86-178.btcentralplus.com) joined #highaltitude.
[19:59] <Lunar_Lander> 100000 mcd LED http://s.gullipics.com/image/l/p/g/5yv6r9-luqe1t-x7nq/20150710134710.jpeg :)
[20:01] gb73d (~gb73d@88-110-56-242.dynamic.dsl.as9105.com) left irc:
[20:02] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) joined #highaltitude.
[20:03] <daveake> Is that your next tracker? :)
[20:04] <Lunar_Lander> no, a potential new experiment :)
[20:04] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) left irc: Client Quit
[20:04] <fsphil> nice bench
[20:04] <Lunar_Lander> thanks ;)
[20:04] <daveake> more bench visible than mine
[20:04] <Lunar_Lander> :)
[20:04] pjm (~pjm@uhfsatcom.plus.com) joined #highaltitude.
[20:05] <fsphil> more real than mine
[20:05] <Mark_B> Proper engineering bench - stuff everywhere
[20:05] <Lunar_Lander> :)
[20:05] <Mark_B> Guys, is it OK to get a flight doc approved here?
[20:06] <daveake> Try #habhub
[20:06] <Mark_B> Ack, thnx
[20:06] DG0MG1 (DG0MG@p4FEC26FB.dip0.t-ipconnect.de) left #highaltitude.
[20:06] <daveake> that's where the admins hang out
[20:07] pjm_ (~pjm@uhfsatcom.plus.com) left irc: Ping timeout: 264 seconds
[20:11] <Lunar_Lander> the LEDs are awesome :)
[20:15] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) left irc: Ping timeout: 256 seconds
[20:16] goopypanther (~goopypant@goopypanther.org) joined #highaltitude.
[20:17] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) joined #highaltitude.
[20:28] chimpusmaximus (~Chris@host86-178-84-59.range86-178.btcentralplus.com) left irc: Quit: Leaving
[20:33] ibanezmatt13_ (1f6989f5@gateway/web/freenode/ip.31.105.137.245) left irc: Quit: Page closed
[20:38] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) left irc: Ping timeout: 255 seconds
[20:40] <Laurenceb_> http://www.sciencedirect.com/science/article/pii/S0094576515002726
[20:41] <Laurenceb_> lulz
[20:41] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) joined #highaltitude.
[20:48] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) joined #highaltitude.
[20:49] dokument (~dokument@cpe-72-182-50-56.austin.res.rr.com) left irc: Quit: Leaving
[20:51] pjm_ (~pjm@uhfsatcom.plus.com) joined #highaltitude.
[20:52] pjm (~pjm@uhfsatcom.plus.com) left irc: Ping timeout: 244 seconds
[20:54] <fxmulder> The probe will enable the dream of an interstellar mission to be achieved within the next 20 years.
[20:54] <SpacenearUS> New vehicle on the map: 03MGSP_ONE_chase - 12http://tracker.habhub.org/#!qm=All&q=MGSP_ONE_chase
[20:54] devtt (4e9189a2@gateway/web/freenode/ip.78.145.137.162) joined #highaltitude.
[21:02] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) left irc: Read error: Connection reset by peer
[21:04] <chrisstubbs> Can someone approve on HH please?
[21:06] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) joined #highaltitude.
[21:12] edmoore (~ed@82.6.148.64) left irc: Quit: This computer has gone to sleep
[21:24] hEINstein (5ab86208@gateway/web/freenode/ip.90.184.98.8) left irc: Ping timeout: 246 seconds
[21:25] <Laurenceb_> PS-46 makes landfall
[21:27] Mark_B (56b20522@gateway/web/freenode/ip.86.178.5.34) left irc: Quit: Page closed
[21:28] ak4rp (~Thunderbi@BC240236.catv.pool.telekom.hu) left irc: Ping timeout: 256 seconds
[21:32] <stilldavid> I talked about weather balloons at a thing: https://www.youtube.com/watch?v=gBmWsMcdAa8
[21:37] <Laurenceb_> holy shit the queens husband
[21:37] <Laurenceb_> wtf hes called
[21:38] <Laurenceb_> i lolled
[21:39] <Laurenceb_> looks like PS-46 could cross the equator
[21:48] anerdev (~anerdev@net-93-149-97-110.cust.vodafonedsl.it) joined #highaltitude.
[21:49] Ojo_3 (~pieter@c-24-30-12-2.hsd1.ga.comcast.net) joined #highaltitude.
[21:51] Ojo_2 (~pieter@c-24-30-12-2.hsd1.ga.comcast.net) left irc: Ping timeout: 265 seconds
[21:55] chrisstubbs (~chrisstub@host86-190-252-20.range86-190.btcentralplus.com) left irc: Read error: Connection reset by peer
[21:57] SP3OSJ (563f462a@gateway/web/freenode/ip.86.63.70.42) joined #highaltitude.
[21:58] <SP3OSJ> habhub
[21:58] <SP3OSJ> #habhub
[22:04] LazyLeopard (~irc-clien@chocky.lazyleopard.org.uk) joined #highaltitude.
[22:18] drsnik (~drsnik@gate3.ima.cz) left irc: Read error: Connection reset by peer
[22:20] drsnik (~drsnik@gate3.ima.cz) joined #highaltitude.
[22:24] <SpacenearUS> New vehicle on the map: 03WA4LOQ-CHASE_chase - 12http://tracker.habhub.org/#!qm=All&q=WA4LOQ-CHASE_chase
[22:26] SP3OSJ (563f462a@gateway/web/freenode/ip.86.63.70.42) left irc: Quit: Page closed
[22:31] <SpacenearUS> New vehicle on the map: 03MTG004 - 12http://tracker.habhub.org/#!qm=All&q=MTG004
[22:33] pretec (~Matthias@port-92-195-69-163.dynamic.qsc.de) left irc: Quit: schwund
[22:35] <SpacenearUS> New vehicle on the map: 03SUNCH1 - 12http://tracker.habhub.org/#!qm=All&q=SUNCH1
[22:44] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) joined #highaltitude.
[22:47] F5MVO (52e6b25d@gateway/web/freenode/ip.82.230.178.93) left #highaltitude.
[22:51] Geoff-G8DHE_ (~Geoff-G8D@geoffg8dhe.plus.com) joined #highaltitude.
[22:52] J0rd4n- (~J0rd4n@195-154-108-115.rev.poneytelecom.eu) left irc: Ping timeout: 256 seconds
[22:52] richardeoin (~richard@cpc70799-aztw27-2-0-cust958.18-1.cable.virginm.net) left irc: Read error: Connection reset by peer
[22:52] J0rd4n- (~J0rd4n@195-154-108-115.rev.poneytelecom.eu) joined #highaltitude.
[22:54] mfa298_ (~mfa298@krikkit.yapd.net) left irc: Ping timeout: 256 seconds
[22:54] Geoff-G8DHE-Lap (~Geoff-G8D@geoffg8dhe.plus.com) left irc: Ping timeout: 276 seconds
[22:55] mfa298_ (~mfa298@krikkit.yapd.net) joined #highaltitude.
[22:56] Ian_ (4d651452@gateway/web/freenode/ip.77.101.20.82) left #highaltitude.
[22:56] Ian_ (4d651452@gateway/web/freenode/ip.77.101.20.82) joined #highaltitude.
[23:03] richardeoin (~richard@cpc70799-aztw27-2-0-cust958.18-1.cable.virginm.net) joined #highaltitude.
[23:04] LazyLeopard (~irc-clien@chocky.lazyleopard.org.uk) left irc: Quit: Now QRT
[23:06] Nick change: fl_0|afk -> fl_0
[23:07] Lunar_Lander (~kevin@p5488881F.dip0.t-ipconnect.de) left irc: Quit: Verlassend
[23:25] Nick change: fl_0 -> fl_0|afk
[23:26] Nick change: fl_0|afk -> fl_0
[23:37] Nick change: fl_0 -> fl_0|afk
[23:42] malgar (~malgar@151.68.138.173) joined #highaltitude.
[23:44] chris_99 (~chris_99@unaffiliated/chris-99/x-3062929) left irc: Remote host closed the connection
[00:00] --- Sat Jul 11 2015