--- Day changed Mon Aug 05 2013
00:00 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+10:33 -!- Callum_ [
[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
+11:19 < Callum> hallo
+11:29 < sam_moore> Hi
+11:30 < sam_moore> I've spoken to Omid from the electronics team, they are in charge of the "microcontroller"
+11:31 < sam_moore> Apparently they think a raspberry pi is a good choice
+11:31 < sam_moore> I told him we thought we might need a lower level device to do the ADC/DAC in particular
+11:32 < sam_moore> But they seem to think a raspberry pi by itself will work
+11:33 < sam_moore> I'm kind of not sure who's responsible for this part, since we have "server hardware" and they have "microcontroller" and the raspberry pi is sort of both
+11:33 < sam_moore> But if we agree we want a raspberry pi it probably won't be an issue
+11:33 < sam_moore> Also apparently the unit coordinators recommended the raspberry pi as well
+11:34 < Callum> Yea he did
+11:34 < james__> Well we are using the raspberry pi as a server
+11:34 < james__> And we can bootstrap microcontrollers onto it
+11:34 < james__> So i guess we are in charge of the pi
+11:35 < james__> And the are in charge of the hardware around it
+11:35 < james__> *they
+11:35 < sam_moore> Seems logical
+11:36 < sam_moore> I don't know if you get email notifications; I did a block diagram using the ideas from our first meeting
+11:36 < sam_moore> I kind of added some thoughts of my own
+11:38 < sam_moore> Hopefully it makes sense
+11:41 < sam_moore> If either of you gets time, would you like to start typing some of the progress report?
+11:51 < james__> Do we have to submit a progress report? Because the guide to mechatronics project work that was on lms said we had to do some things for week 1 but not that
+11:52 < sam_moore> I'm pretty sure we do
+11:52 < sam_moore> Hang on
+11:53 < sam_moore> All teams are expected to report next monday (see the report format in the unit outline/overview).
+11:53 < sam_moore> All teams must review their sub-system and provide high level detail of what is required.
+11:54 < sam_moore> All team must take an integrated approach. (I assume this means we have to start talking to other teams ASAP)
+11:54 < sam_moore> I think the block diagram is a good start for the high level detail
+11:54 < sam_moore> Then make some notes about how we're collaborating using git
+11:55 < james__> git and irc
+11:55 < sam_moore> We should decide whether Rowan or I will be the meeting convener
+11:56 < james__> I think you
+11:56 < james__> Just because you actually know what is going on
+11:56 < sam_moore> Yes, I'm happy to do it and I think I can do a good job
+11:56 < sam_moore> I just don't want to try and take over the group or something
+11:56 < sam_moore> I have a good idea of what's going on, but we'll still need everyone to contribute
+11:57 < sam_moore> I'm not a particular expert in any area, I just sort of know enough to have a general idea of how to approach things
+11:57 < james__> Its important that the person who represents us has a firm knowledge base of whats possible and what we plan to do. Ultimately you are the person who best fills those requirements
+11:58 < sam_moore> Ok, thanks, if everyone agrees we'll tell Rowan that when we meet
+11:58 < sam_moore> And he can still talk to his friends for us, in fact the more of us that can communicate with the other teams the better
+11:59 < james__> True
+12:00 < james__> there isn't anything that says he can't talk to others
+12:00 < sam_moore> Omid said his team was going to rotate the meeting convener, maybe we could try that later on once everyone has a better idea of what we're doing
+12:00 < sam_moore> Anyway, I should do some other work, see you at 2pm
+12:01 < james__> Yeah might be worth it. Gives everyone a taster
+12:01 < james__> okay see you then
+20:38 < sam_moore> I'm going to try using the GitHub issues and milestones thing
+20:39 < sam_moore> It might help with keeping track of what we need to do and what we've done
+20:50 < sam_moore> I think we had some difficulty setting specific goals for this week
+20:50 < sam_moore> I can try and put together some longer term goals as a start, if that's helpful
+20:51 < sam_moore> Hmm
+20:52 < sam_moore> We weren't given a lot of requirements that the guy was asking us about
+21:06 < sam_moore> So the most important task seems to be "determine those requirements"
+21:07 < sam_moore> Well, we talked about it in the meeting, but I'm going to make GitHub issues for each of the areas so we have a good record
+21:32 < Callum__> Sam are you talking to yourself or am i not just seeing the other messages?
+21:35 < sam_moore> Yeah, just ranting
+21:36 < sam_moore> Well if you read the messages, then I was talking to you :P
+21:37 < Callum__> haha just they seemed like they were structured like you were responding to someone
+21:39 < sam_moore> I guess that's how I'm used to using IRC, people tend to say stuff broadly directed at anyone even though they won't get an immediate reply
+21:39 < sam_moore> Or even if they don't need a reply
+21:45 < Callum__> Fair enough
+--- Day changed Tue Aug 06 2013
+15:12 < Callum__> Is the only image processing that needs doing detecting the edge of the can? (and doing measuring how it changes with time etc)
+15:39 < Callum__> hey
+15:39 < james__> what up
+15:39 < sam_moore> Hi
+15:39 < Callum__> Is the only image processing that needs doing detecting the edge of the can? (and doing measuring how it changes with time etc)
+15:40 < sam_moore> Callum__: I think so
+15:40 < james__> As far as i understand it yes
+15:40 < Callum__> plus just booted up ubuntu on laptop. havent touched it since i did C programming a year ago xD
+15:40 < sam_moore> It would also be nice to just have unprocessed images streamed to the GUI
+15:40 < Callum__> yea what i was thinking
+15:41 < Callum__> firstly, i can look into only processing a portion of the image, so we could get away with a larger resolution
+15:41 < sam_moore> With the server side interface, I'm starting to think I'll ditch the apache2 webserver + CGI and integrate a minimal webserver + the lower level stuff into the same program
+15:41 < Callum__> and openCV has a couple of algorithms to detect edges
+15:41 < Callum__> so will likely look into one or 2 of those
+15:41 < sam_moore> Just thinking about all the layers that are involved with the CGI approach... it probably won't turn out easier to code, and it will definitely be slower
+15:42 < sam_moore> Plus, if we really care about performance, the apache2 webserver has a lot of features we don't care about
+15:42 < james__> As long as i can access the raw files etc i should be able to display it via a gui
+15:42 < sam_moore> The main one being it's designed to cope with multiple users well, and we want to configure it to only allow ONE user
+15:43 < sam_moore> Yes, that sounds good
+15:44 < Callum__> responding to who? me or james?
+15:44 < sam_moore> Um... both now
+15:44 < Callum__> haah
+15:45 < sam_moore> Anyway, I've realised that our software will place an upper limit on the quality of the sensors
+15:45 < james__> true
+15:45 < sam_moore> Since we weren't given a requirement on quality, we should aim to get it as high as feasible
+15:45 < sam_moore> But sensors group needs to have some idea of the upper limit that our software will place on quality
+15:45 < Callum__> yea.
+15:46 < james__> Start simple and ramp it up until the hardware breaks?
+15:46 < sam_moore> No point streaming 1000 images a second if the JavaScript GUI can't send requests that fast.
+15:46 < sam_moore> Yep.
+15:46 < sam_moore> I know you're supposed to do task break downs and all that time management stuff, but the fact is we need to experiment with actual code to work out the best implementation
+15:47 < james__> yeah. break it down into code and test code?
+15:48 < sam_moore> Maybe?
+15:49 < sam_moore> Well, we've got a high level idea of the software
+15:49 < sam_moore> The first tasks should be "decide on the best software implementation of each level"
+15:49 < sam_moore> To do that we need to test some minimalistic implementations
+15:50 < Callum__> yea
+15:50 < sam_moore> So, to set a goal for week 2, can it be "Decide on software implementation at each point in the block diagram"
+15:51 < sam_moore> And "Determine upper limit on data transfer rate through software systems"
+15:51 < sam_moore> The second one might take a bit longer.
+15:52 < Callum__> githubs down for maintenance. hahah
+15:52 < sam_moore> That happened like 2 seconds after I submitted a comment on the CGI stuff
+15:53 < sam_moore> For a while it was showing me a Unicorn (?)
+15:53 < Callum__> yea i got that before
+15:53 < Callum__> when trying to access on my laptop
+15:53 < sam_moore> Well... we have the git.ucc server
+15:54 < sam_moore> But I was starting to like the Issues and Comments and all those actual features
+15:54 < Callum__> hmm. doubt it will be down for long. will have to see
+16:10 < Callum__> back up
+18:35 < Rowan> test test
+18:35 < Rowan> ??
+18:43 < Callum__> Hey
+18:56 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/ZDMvew
+18:56 -github:#mctxuwa_softdev- MCTX3420/master 64b0cd9 Sam Moore: Investigate software for interfacing with hardware via HTTP requests...
+18:56 -github:#mctxuwa_softdev- MCTX3420/master 5afaa23 Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420
+18:57 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/1nMEMA
+18:57 -github:#mctxuwa_softdev- MCTX3420/master 9579cea Sam Moore: Makefile for webserver test...
+--- Day changed Wed Aug 07 2013
+00:24 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/5DEPzw
+00:24 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
+00:52 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/r6aFJw
+00:52 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
+01:00 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/eZPWcQ
+01:00 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
+10:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+20:43 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
+20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
+20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
+20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
+20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
+20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
+20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
+20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
+20:46 < sam_moore> Whoops, I was trying to make it less spammy and ended up making it spam us
+20:53 < Callum__> haha nice work
+20:58 < sam_moore> I have a minimal web server in C done
+20:58 < sam_moore> It was surprisingly easy actually
+21:05 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/Tui0FA
+21:05 -github:#mctxuwa_softdev- MCTX3420/master c1321a7 Sam Moore: Test webserver with minimalist JavaScript...
+21:05 -github:#mctxuwa_softdev- MCTX3420/master 1b2939d Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420...
+21:07 < sam_moore> Hooray, more spam
+21:07 < sam_moore> Maybe I should just turn that off.
+21:35 < Callum__> Maybe, its kinda goods to know when people commit things though, restricted to one line would be good
+--- Day changed Thu Aug 08 2013
+08:59 -!- Callum_ [
[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
+--- Day changed Sun Aug 11 2013
+14:09 < Callum__> actually so much work to do already.
+14:47 < sam_moore> Yep
+15:15 < Callum__> well iv spent some time thinking over this, finally get around to writing it down. so iv probably spent close to 4 hours or so thinking about it (while doing other things) but really only spent an hour and a half according to diary
+15:25 < sam_moore> We can always flesh out people's reports with graphs and stuff
+15:27 < Callum__> well we doing 1 per person or group?
+15:29 < sam_moore> 1 per person is the safest way to go I think
+15:29 < sam_moore> We can always summarise them
+15:30 < Callum__> well, tbh i think we should do 1 per person and summarise, but not necessarily go for a full page. thing is not sure how they expect us to do 1 page for 5 people AND be detailed
+15:30 < sam_moore> Yep
+15:31 < Callum__> so they might end up making it 1 per person anyway.
+15:31 < Callum__> not very well thought out either way
+15:31 < sam_moore> Let's just submit a multiple page report, with a bit from each person and a summary. If some people have less than a page that's fine.
+15:32 < Callum__> Yea, agreed thats the best way to go about it. Unless they complain about it being too long
+15:32 < sam_moore> That's why we include a summary :P
+15:33 < sam_moore> Although, it might be difficult to make the summary actually summarise things, since everyone's already using pretty concise summaries
+15:33 < sam_moore> Oh well, writing more stuff is safer to start with.
+15:34 < Callum__> hmm. its kind of a pain though, write it all down in your book...oh look now i need to rewrite most of it for a report..
+15:34 < sam_moore> Ah crap, I forgot about the book
+15:34 < Callum__> haha
+15:34 < sam_moore> Yeah... write it all down in the git commit messages, write it all down in the report, write it all down in the diary...
+15:35 < sam_moore> I suppose in the "Real World" you have to do stuff like this
+15:35 < Callum__> yea true
+18:16 < Callum__> Not sure when il get round to writing what i'v done but il do it tonight some time. We finalising it tomorrow and printing it off then?
+18:27 < sam_moore> Yes, I'd like to have it done before the meeting, or at least do it first thing in the meeting
+18:27 < sam_moore> Then there are some things I need to ask everyone about to progress with my part of the code
+18:27 < sam_moore> Since I'm sort of doing the bit in the middle that gets all the other bits to talk to each other
+18:28 < sam_moore> I think it would be good to keep all the raspberry pi code in a single process, running in seperate threads
+18:29 < sam_moore> But to do that we'd need everyone to use the same language
+18:30 < sam_moore> Also we need to start thinking about the structure of the system in a bit more detail
+18:31 < sam_moore> Like: We can't just transfer data straight to a GUI, because the user will want to use the GUI to start the experiment, then go away and come back later to view results (and possibly save them on their own machine)
+18:32 < sam_moore> Also if we do transfer everything straight to the GUI we'd be limited by the speed of the GUI, and JavaScript requests are slow
+18:34 < Callum__> yea
+18:34 < sam_moore> Pretty easy to just dump stuff to a data file, but we probably also want the ability to do it in realtime
+18:35 < sam_moore> Anyway, good luck, see you tomorrow
+18:36 < Callum__> Alright, cya tomorrow them
+--- Day changed Mon Aug 12 2013
+--- Log closed Tue Aug 13 07:49:14 2013
+--- Log opened Tue Aug 13 07:55:27 2013
+07:55 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+07:55 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
+10:01 < Callum> So apparently we have a new member..
+10:12 < sam_moor1> Yep, Jeremy Tan, apparently he's doing CS as well?
+10:13 < sam_moor1> So, with the two sources of confusion we have so far...
+10:13 < sam_moor1> 1. The Camera - Adrian thinks we need one, Sensors team doesn't, everyone needs to recheck calculations
+10:14 < sam_moor1> The "Can" team wanted to use some kind of tiny can with a relatively thick wall, Adrian recommended a Coke Can, Oliver used Rockstar Cans last year and recommended them
+10:14 < Callum> well, they may be right in saying we may not be able to do any proper processing on it
+10:14 < Callum> but we will need one to relay whats actually HAPPENING in the system
+10:14 < Callum> surely the sensors team see that..
+10:15 < sam_moor1> I guess, I told them in their meeting it would probably be useful
+10:15 < sam_moor1> Anyway...
+10:15 < sam_moor1> We all got in trouble for not communicating between teams well enough
+10:15 < sam_moor1> So now the 9am session is for teams to communicate (at least one member is meant to go)
+10:15 < Callum> how many people went to the lecture?
+10:15 < sam_moor1> About 6
+10:16 < Callum> haha
+10:16 < sam_moor1> I think only one team didn't have a representative, electronics?
+10:16 < Callum> hmm. thats not too bad then.
+10:16 < Callum> but still, not really our fault communication was poor. we attempted to set up meetings and to convene with others.
+10:17 < Callum> The only other thing we could have done is actually told people, right we're meeting at this time. come or dont (then you'd have like 1 or 2 people at most)
+10:17 < sam_moor1> Yeah, I really think this project needed some kind of direction at the start
+10:17 < sam_moor1> I think that's what we're going to have to do
+10:18 < sam_moor1> We're going to have to be more assertive; we think we need Arduinos, electronics team doesn't seem to know, we should just say "Right, we're using some Arduinos"
+10:18 < sam_moor1> At least that's the vibe I got from Adrian
+10:18 < sam_moor1> Also what happened to my name
+10:18 < Callum> hmm ok. it would help if we had the team convener meeting to do that
+10:18 -!- You're now known as sam_moore
+10:19 < Callum> and no idea
+10:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+10:20 < sam_moore> Also, so far we've neglected physical details a bit
+10:20 < sam_moore> Lastly, we need to start ordering things as soon as possible
+10:21 < sam_moore> Oh, and we (as in, all teams) are supposed to have a schedule of tasks agreed upon
+10:21 < sam_moore> Right, I need to have lunch
+10:21 < sam_moore> *breakfast
+10:22 < sam_moore> Then I guess I can panic some more
+10:23 < Callum> haha. we'v only had 2 weeks to work on this really. We can pull it back.
+10:24 < sam_moore> The scary part is where they do a very similar project every year and no one ever succeeds :S
+10:25 < sam_moore> They seem to think simply throwing the entire class at it (instead of one team of 6) will make it work this time
+10:25 < sam_moore> Oh well, they can't just fail the entire class
+10:25 < sam_moore> It would be nice to actually succeed though
+10:30 < Callum> Yea, well even if it doesnt work a lot of the marking will come from the shit like the diary
+10:30 < Callum> but yes, it would be nice to see a can go boom
+11:57 < Callum> alright so am i still doing the taking images thing and storing it? Coz we pretty much need the camera. what we do with the images though dno
+11:58 < sam_moore> Just take the images and save them to a file for a start I guess
+12:00 < Callum> alright.
+12:13 < Callum> I might reinstall linux on my laptop, stick with ubuntu or go debian?
+12:51 < sam_moore> I'd recommend debian
+12:51 < sam_moore> It's not that much harder to use, but it's closer to raspian
+13:06 < Callum> alright. any port better to use?
+13:15 < sam_moore> Oh, stick with "stable"
+13:15 < sam_moore> ie: Wheezy
+13:16 < sam_moore> No matter what you do, do NOT get "Sid"
+13:18 < Callum> nah i meant the architecture
+13:20 < jtanx> yallo
+13:20 < Callum> hey
+13:21 < sam_moore> Hi
+13:23 < jtanx> i should say that right now I cant access g19 because I haven't gone through the safety induction yet
+13:23 < sam_moore> Callum: The architecture shouldn't matter too much
+13:24 < Callum> we can let you in. As long as you don't do anything stupid it will be fine
+13:24 < Callum> alright
+13:25 < sam_moore> We can just compile code on the RPi itself, or if that's too slow (I doubt it) there will be cross compilers
+13:25 < Callum> true
+13:25 < sam_moore> It's just nice to be able to run test software in debian
+13:25 < jtanx> so do you have access to an/the RPi and the other microcontrollers, or is that tba
+13:26 < sam_moore> We have access to "an" (not "the") RPi
+13:26 < Callum> rowan has an arduino too
+13:26 < sam_moore> Ah, that's good
+13:26 < Callum> atleast i think he said he did
+13:27 < Callum> just dont know the exact hardware we're using and won't get access to it for a few weeks atleast (hopefully not too long. need to make sure other teams are doing everything on time)
+13:27 < Callum> speaking of which we should write up a time schedule for our team and make sure a project one gets written up
+13:27 < sam_moore> Adrian said to allow for 6 weeks ordering time
+13:28 < sam_moore> Yeah, the entire class needs to agree on a schedule
+13:28 < Callum> hmm. true i guess, by the time adrian gets the bill of materials, clears it and the stuff gets ordered in
+13:28 < Callum> but at the current rate shit wont be chosen in time
+13:29 < jtanx> i'm surprised that not much has been done in three weeks
+13:29 < sam_moore> The problem is there are too many people working on this
+13:29 < Callum> its been less than 3 weeks though
+13:30 < sam_moore> Right. Let's make a schedule then.
+13:30 < sam_moore> Just a second
+13:30 < Callum> we only got the teams on like wed first week
+13:30 < jtanx> ok
+13:31 < Callum> And having 5-6 people per team across 6 teams without a project manager...makes sense
+13:31 < sam_moore> Haha
+13:31 < sam_moore> Ok, so I have an excel document
+13:31 < sam_moore> Anyone here actually made a schedule for a project?
+13:32 < jtanx> nope
+13:32 < sam_moore> Welp
+13:32 < jtanx> ms project was suggested in cits3200
+13:32 < jtanx> nice gantt chart and everything
+13:32 < sam_moore> Does it allow collaborative editing?
+13:33 < sam_moore> Also, is there an open source version :P
+13:33 < sam_moore> Ok, I've shared a google spreadsheet
+13:34 < jtanx> not likely haha although there was something called ms project server which might allow collaboraitve stuff
+13:34 < jtanx> you can get this all off msdnaa
+13:34 < jtanx> but since noone's used it before it might be better to stick with excel
+13:34 < sam_moore> Ok, let's just try and think what we need to get other teams to do, and what we need to do for other teams
+13:35 < Callum> HAHAH
+13:35 < sam_moore> Well
+13:35 < Callum> Hello everyone,
+13:35 < Callum> It appears that the lab signup sheets for GENG4402, the MECH/MCTX/Oil and Gas students have dissapeared from the desk at the stairwell.
+13:35 < Callum> Can you please check if you have it and return it as soon as possible? Many students still need to sign up. I will then scan and put online once complete so that you can check when your lab is.
+13:35 < Callum> PLEASE RETURN THE SHEETS.
+13:35 < Callum> Thank you
+13:35 < Callum> thats hilarious
+13:35 < jtanx> ~~
+13:36 < sam_moore> Oh dear
+13:36 < sam_moore> It strikes me that something like a Makefile, except a bit more GUI, would be good for this
+13:37 < jtanx> wait
+13:37 < jtanx> you lost me there - what are you referring to
+13:37 < Callum> ^
+13:37 < sam_moore> To compile C projects that involve several files, you use something called "make"
+13:37 < sam_moore> You write a Makefile for it
+13:37 < jtanx> yah
+13:38 < sam_moore> The Makefile has a list of targets and what they depend on
+13:38 < sam_moore> And how to make them once their dependency exists
+13:38 < jtanx> ok
+13:38 < sam_moore> Then you run "make" and it reads the make file and magically compiles everything in the right order
+13:38 < Callum> yea we get what make is
+13:39 < sam_moore> Ok, I was referring to the list of tasks
+13:39 < sam_moore> That depend on each other
+13:39 < jtanx> ook
+13:39 < jtanx> well
+13:39 < sam_moore> It was a bad joke
+13:39 < sam_moore> I am not seriously suggesting we use make to plan the project
+13:40 < Callum> hahahah
+13:40 < Callum> now that i would like to see :p
+13:40 < jtanx> um just with git
+13:40 < jtanx> i've never done pull requests before
+13:40 < sam_moore> Neither had we until last week :P
+13:41 < sam_moore> Basically you make your own fork of the repositoy, and there is a pull request button that lets you ask to have the changes merged back into the upstream repository
+13:42 < jtanx> ahh
+13:42 < jtanx> ok
+13:51 < jtanx> well that was pretty straight forward - I understand it now
+15:06 < sam_moore> I made a #mctxuwa channel for group representatives
+15:06 < sam_moore> I don't know if people will use it, but at least it's an attempt at something
+15:47 < Callum> tbh it makes more sense for us all to use one
+15:47 < Callum> unless the one for everyone is actually used often enough to justify us having our own
+16:11 < sam_moore> Yeah, there's nothing stopping people that aren't group representatives from joining it
+16:11 < sam_moore> It will certainly make it easier if there are more people talking to other teams directly than just the representative
+16:11 < sam_moore> We might still want our own for discussing the details of code
+16:12 < sam_moore> Speaking of which, I'm currently tidying up the test webserver code I wrote
+16:17 < sam_moore> Does: FunctionName, variable_name, Structure, Extern_FunctionName, g_global_variable seem suitable
+16:19 < sam_moore> Well, unless anyone objects before I've satisfied my obsessive compulsive urges, that's what it will be
+16:19 < sam_moore> Until then, it'll probably take a while, and find-replace is fast
+16:20 < sam_moore> Other than that, the style of comments/documentation in the test webserver is what I'll keep using
+16:22 < sam_moore> If someone wants to actually write code... it would be good to have a watchdog program that uses exec to start the main program and detects SIGCHLD when it crashes
+16:22 < sam_moore> Then we can put some kind of emergency "Turn all the things off!" in that
+16:57 < jtanx> what about something like this? http://stackoverflow.com/questions/696839/how-do-i-write-a-bash-script-to-restart-a-process-if-it-dies
+16:58 < sam_moore> Oh cool, that looks good
+17:03 < sam_moore> I'll be back later tonight, bye
+17:21 < jtanx> umm
+17:21 < jtanx> wow okay you're actually writing a webserver from the ground up?
+17:22 < jtanx> what if you just had software that got the results and then wrote that to a html/php file
+17:22 < jtanx> then you can just run nginx and serve it up
+17:45 < jtanx> or what about if you ran an sql server, so you update the database from your program
+17:46 < jtanx> then you can either use php to interface with the database
+17:46 < jtanx> or you could make some sort of api and serve the data in json format
+17:50 < jtanx> sqlite
+19:12 < jtanx> you could do something like this: http://pastebin.com/mEdbu4jR
+19:13 < jtanx> where instead of outputting html, you could make it output json, which is then interpreted by your actual webpage
+20:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Wed Aug 14 2013
+09:13 < jtanx> I've done a version using fastcgi, which was surprisingly quite easy to set up
+09:13 < jtanx> see here: https://github.com/jtanx/MCTX3420/tree/master/testing/fastcgi-approach
+10:41 < sam_moore> That looks interesting, I'd prefer that to the PHP/database solution
+10:42 < sam_moore> My concern is: You have to query the web server to start the process, even though it keeps running
+10:42 < sam_moore> Also, I know "write a custom HTTP server" sounds scary, but it does actually work
+10:43 < jtanx> nah
+10:43 < jtanx> fastcgi
+10:43 < jtanx> the process is started once and always runs
+10:43 < jtanx> so you have a request loop
+10:44 < jtanx> wait
+10:44 < jtanx> how do you envision it working?
+10:45 < sam_moore> Oh, right, I see how the fastcgi approach would work, it's basically the same idea; you have something responding to HTTP queries in one thread, something dealing with sensors/actuators in seperate threads
+10:45 < jtanx> yeah
+10:46 < jtanx> except that you don't have to worry about maintaining your own webserver
+10:46 < sam_moore> Cool
+10:46 < sam_moore> I do think that the HTTP server isn't that hard, and it's mostly working
+10:46 < sam_moore> But we can probably switch to fastcgi
+10:48 < sam_moore> I mean, we still have to parse a query string right?
+10:48 < jtanx> well yes
+10:48 < jtanx> if your request was
+10:48 < jtanx> http://blah/cgi/?key=value&anotherkey=value2
+10:48 < jtanx> you'd get back key=value&anotherkey=value2
+10:48 < jtanx> as query string
+10:50 < jtanx> try it out here: http://124.169.120.181:8080/cgi
+10:51 < jtanx> (hopefully that forwards ok)
+10:51 < sam_moore> Yep, that's cool
+10:51 < sam_moore> The HTTP server I wrote basically does that
+10:51 < sam_moore> But if it really bothers you, I'm fine with switching to fastcgi :P
+10:52 < jtanx> well whatever works
+10:52 < jtanx> but I thought it might be more maintainable if you used something that already exists :P
+10:52 < sam_moore> Yeah, but thinking about it, what maintainence does the HTTP server require?
+10:53 < sam_moore> Oh well, it's a good idea
+10:53 < jtanx> for this situation not much
+10:57 < sam_moore> We can pretty easily start with a structure that would allow us to switch, but I'd lean towards keeping the custom HTTP server
+10:58 < sam_moore> Have you done multithreading in C before?
+10:58 < jtanx> in windows yes
+10:58 < jtanx> on linux not really
+10:58 < sam_moore> Ah, I've only done it on linux
+10:58 < jtanx> i did a bit in operating systems
+10:59 < jtanx> but kinda forgot
+10:59 < sam_moore> It shouldn't be too hard for our purposes
+11:00 < jtanx> that thing with running a custom webserver is that if anyone wants to reuse this in the future, i doubt they'd really like the idea of that
+11:01 < jtanx> say they had some new fangled thing that requires php
+11:01 < jtanx> which isn't going to work
+11:01 < jtanx> but with a standard webserver like apache or nginx, it's really easy to just install an extra addon
+11:02 < sam_moore> I suppose... what would they need the new fangled php thing for?
+11:03 < jtanx> well that's the thing - for now I don't know, but it could be required
+11:03 < sam_moore> Yeah, good point
+11:03 < sam_moore> Ok, another reason to use an existing web server, is we might require some advanced features if we want to be serious about the safety stuff
+11:04 < sam_moore> For example, it would be a fair amount of work to add SSL to make the custom thing do https
+11:04 < jtanx> oh yeah
+11:04 < jtanx> that too
+11:04 < sam_moore> Also we might want some authentication on it
+11:04 < jtanx> nginx/apache are highly customisable
+11:05 < sam_moore> I've never used nginx, what are it'
+11:05 < sam_moore> s advantages over apache2?
+11:05 < jtanx> nginx
+11:05 < jtanx> yup
+11:05 < jtanx> its really good
+11:05 < sam_moore> Haha
+11:05 < jtanx> a lot of sites use it because it's fast
+11:05 < sam_moore> Fast is good
+11:05 < jtanx> faster than apache
+11:05 < sam_moore> Sold
+11:05 < sam_moore> Well, we only need one user as well
+11:05 < sam_moore> In fact, we deliberately do not want to have multiple clients able to use the thing at the same time
+11:05 < jtanx> haha true
+11:07 < sam_moore> Ok, so I think you've convinced me to use fastcgi
+11:07 < sam_moore> Most of the custom HTTP server was reused code, so I didn't waste too much time on it
+11:07 < jtanx> haha ok
+11:07 < jtanx> have you written one before?
+11:09 < sam_moore> Not specifically a HTTP server, but I've written a project for posix systems with a fair bit of networking
+11:09 < sam_moore> git.ucc.asn.au/?p=matches/swarm.git
+11:10 < jtanx> nice
+11:10 < sam_moore> It allows you to run a shell, eg: bash accross multiple machines at once
+11:11 < sam_moore> Not as useful as I thought it might be, but it was fun
+11:12 < jtanx> heh
+11:12 < jtanx> what did you end up using it for?
+11:13 < sam_moore> I was setting up a programming competition where you have AIs play against each other
+11:13 < sam_moore> I wanted to make a round robin
+11:13 < sam_moore> So I had a bash script setup to do that, but then I got impatient, because it would have to run the games in order
+11:14 < jtanx> oO
+11:14 < sam_moore> Well it turned out no one entered the competition, so I probably didn't need to go overboard
+11:14 < sam_moore> But maybe I can use it for something else
+11:15 < sam_moore> For the threading I'm thinking of using pthreads
+11:16 < sam_moore> The alternative is OpenMP, but it's more suited to numerical computation, rather than having seperate things talking to each other
+11:16 < jtanx> okay
+11:17 < sam_moore> My goal for this week was to have the framework started, so we just have some really basic threads running and then we can start implementing them
+11:17 < jtanx> yeah that would be good
+11:18 < sam_moore> If you want to do some work with the fastcgi part so that we'll be able to parse the query strings, that would probably be a good start
+11:18 < sam_moore> We don't have the exact details of pretty much anything yet
+11:18 < sam_moore> Maybe talk to James/Rowan about how the GUI is going to query the server
+11:19 < sam_moore> Also, did you see my suggested naming convention?
+11:19 < jtanx> no
+11:20 < sam_moore> I don't really mind, although I'd prefer not to have hungarian notation
+11:20 < sam_moore> As long as it'
+11:20 < sam_moore> s consistent
+11:21 < sam_moore> But the suggestion was: FunctionName, variable_name (local or member), Structure, ENUMVALUE, Extern_FunctionName, g_global
+11:21 < jtanx> okay I'll try to keep to that
+11:22 < sam_moore> Cool, I should probably go do something else
+12:33 < jtanx> i gotta go
+12:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+16:56 < jtanx_> a beagleboard
+16:56 < jtanx_> hmm
+16:58 -!- jtanx_ is now known as jtanx
+17:03 < jtanx> is it the beaglebone black?
+17:03 < jtanx> sounds interesting
+17:04 < sam_moore> They didn't specify
+17:04 < sam_moore> Oh right, I accidentally cut out his message
+17:04 < sam_moore> tl;dr "Beagle Board"
+17:04 < jtanx> the beagle board is around $125 though
+17:04 < sam_moore> Probably the Beaglebone black
+17:04 < sam_moore> Oh really
+17:04 < sam_moore> Heh
+17:04 < jtanx> yeah
+17:05 < jtanx> the beaglebone black is $45
+17:05 < jtanx> but just looking the A/D converter on the black has a max voltage of 1.8v
+17:05 < sam_moore> That's probably what they meant, since they said it is "not much more expensive"
+17:05 < sam_moore> That should be fine; the sensors team says things are in mV
+17:05 < jtanx> okay
+17:05 < jtanx> that's good
+17:05 < sam_moore> Really though... electronics should be asking the sensors team stuff like this
+17:06 < jtanx> heh yeah
+17:06 < sam_moore> They should probably have asked us if it was feasable for software
+17:06 < sam_moore> Maybe they had someone who knew it would be, but still
+17:06 < sam_moore> It looks like it is anyway, so crisis averted
+17:07 < jtanx> just with the sensors, I think that the diferences need to be amplified so it covers the full range of the A/D converter
+17:07 < sam_moore> Yes, the sensors guy knows that
+17:07 < jtanx> yeah so if its only 1.8v there's less range than 0-5v
+17:08 < jtanx> is that compensated enough by having a 12 bit a/d converter vs a 10 bit (i think arduino is 10 bit) converter
+17:10 < sam_moore> I think so; you get ~4x more resolution from the 12 bit ADC and lose ~3x from the lower range
+17:10 < sam_moore> Also there's no set requirement yet on what the resolution should be
+17:11 < jtanx> true
+17:11 < jtanx> well in any case the bb black sounds quite nice
+17:11 < sam_moore> Yep, it'll probably be good to use
+17:14 < sam_moore> I'm much happier now that we actually have regular verbal communication with the other teams
+18:23 < sam_moore> I'm looking into getting doxygen working for this
+18:59 < jtanx> for the documentation?
+18:59 < jtanx> seems good, but never used it before myself
+19:01 < jtanx> looks a lot like javadoc
+21:26 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Thu Aug 15 2013
+08:21 < jtanx> hey
+08:22 < jtanx> just a suggestion for the logging functions, but you can use macros
+08:22 < jtanx> to get the function name (and even file name)
+08:22 < jtanx> v
+08:22 < jtanx> http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
+08:23 < jtanx> so you can do stuff like #define Log(level, fmt, ...) LogReal(level, __func__, fmt, __VA_ARGS__)
+08:25 < jtanx> it should be c99 conformant
+09:15 < jtanx> I created a pull request anyway
+09:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+13:39 < sam_moore> Yeah, I probably should have looked at that
+13:46 < jtanx> back to the rpi+arduino
+13:47 < jtanx> didn't they know about the beagle board black, or can that not be used for some reason?
+13:48 < jtanx> beagle bone* black
+14:20 < sam_moore> I don't know what model they were looking at exactly
+14:20 < sam_moore> I told them the Beagle Bone was about $50, I haven't had much time to research it myself
+14:20 < sam_moore> I didn't know about the Beagle Board/Bone, which was why I suggeste the RPi + Arduino
+14:20 < sam_moore> They originally were just considering an Arduino
+14:21 < sam_moore> Which would not have been fun for the remote interfacing stuff
+14:21 < sam_moore> Well we could do it, but we wouldn't be able to have a nice web browser controlled GUI, probably some dedicated networked server/client with a GUI program installed on the client machine
+14:22 < sam_moore> Also image processing would have been interesting
+14:23 < sam_moore> Next time there's a combined groups meeting, hopefully we can talk to them more
+14:24 < jtanx> yeah
+14:24 < jtanx> there's quite a few
+14:24 < jtanx> there's a beagleboard which is ~150
+14:24 < jtanx> beaglebone which is ~90
+14:24 < jtanx> beaglebone black which is ~50
+14:24 < sam_moore> Right
+14:24 < sam_moore> So they were probably looking at the beaglebone for $90
+14:24 < jtanx> yeah probably
+14:24 < jtanx> it's weird because the black version has better specs, from what i can see
+14:25 < sam_moore> But still, even for $150, if it saves us 10 hours of writing code to interface the RPi with Arduinos, it will be worth it
+14:25 < jtanx> yeah exactly
+14:25 < sam_moore> Arduinos themselves cost a bit
+14:25 < jtanx> well
+14:25 < jtanx> you can get equivalents off ebay
+14:25 < jtanx> like an uno is $10
+14:26 < sam_moore> The only issue with the beaglebone to avoid having to use arduinos as well, is whether it has enough ADC by itself
+14:26 < jtanx> yeah
+14:26 < jtanx> well how many sensors are needed
+14:26 < sam_moore> If it doesn't, you might have to add an Arduino or two anyway
+14:26 < jtanx> you could just add on an adc chip
+14:26 < sam_moore> Yes, or something like that
+14:27 < jtanx> the beaglebone has like a bazillion gpio ports
+14:31 < sam_moore> Well without getting into the specific details, it sounds like we should recommend they use that
+14:32 < sam_moore> Apparently the sensors team will have a list ready by monday, which will be good
+14:33 < jtanx> that'd be good
+14:35 < jtanx> when are combined group meetings? just the 9am slot?
+14:36 < sam_moore> 9am Tuesday is the "official" time picked by Adrian, 2pm Wednesday is the time that we agreed between the teams
+14:36 < sam_moore> I'm going to go to both, if more people want to come from the team that's also good
+14:37 < sam_moore> Realistically not everyone is going to come, so I'll have to send emails a lot
+14:38 < jtanx> ok
+14:39 < sam_moore> What account do you need to be invited to the dropbox?
+14:39 < sam_moore> I think Alex invited everyone using their student email
+14:40 < sam_moore> Oh right, you wouldn't have been in the list that he used if you enrolled late
+14:40 < jtanx> yeah, through student email would be good
+14:41 < jtanx> last year's experiment ran with an arduino diecimila which only had 5 analogue inputs
+14:41 < jtanx> any reason why we need more?
+14:41 < jtanx> sorry that's 6
+14:42 < sam_moore> I think the estimate was: 4-6 strain gauges, 1 temperature sensor, 1 microphone, 2 pressure gauges, 1 (maybe 2) USB webcam
+14:43 < jtanx> ok
+14:44 < jtanx> At that rate you would definitely need something with more analogue inputs
+14:45 < sam_moore> We also might need a DAC for one of the pneumatics team's devices
+14:46 < sam_moore> But you can't get that on a microcontroller, there'd have to be a seperate module
+14:46 < jtanx> yep
+14:48 < jtanx> it'd be no point interfacing an arduino to the rpi/beaglebone if all you want is more analog inputs
+14:49 < sam_moore> If you can get modules for ADC that can talk to a rpi/beaglebone, then yes
+14:49 < jtanx> yeah
+14:49 < jtanx> I don't think they're too hard to wire up
+14:50 < sam_moore> I think the electronics team should be considering all this, but I don't know since we haven't verbally spoken
+14:50 < sam_moore> Well not at length anyway
+14:51 < sam_moore> Just when I happen to bump into Omid
+14:51 < jtanx> hmm
+14:54 < sam_moore> This project is probably going to be a good lesson in "Why you need a project manager"
+14:55 < jtanx> so true
+14:59 < jtanx> with the web interface, what sort of update times are we looking at?
+15:00 < sam_moore> My tests with apache2 and the custom HTTP server showed it took about 50us for jQuery to get an AJAX request
+15:01 < sam_moore> There was only one data point returned each time though, we can probably optimise it a bit by returning multiple data points with a request
+15:01 < jtanx> yeah
+15:07 < jtanx> I wonder what sort of performance impact running one (or two) cameras would have on the rpi/beaglebone
+15:44 < jtanx> urgh
+15:45 < jtanx> I was wondering why my nginx config wasn't working
+15:45 < jtanx> until I realised that gedit was creating a backup copy of the config file
+15:45 < jtanx> so nginx was reading both the original and backup
+17:28 < sam_moore> That's wierd, you'd think it would only read one config file
+17:34 < jtanx> well it was in a config directory
+17:36 < sam_moore> Oh, ok
+18:49 < jtanx> so the current idea i have with the web thing is
+18:49 < jtanx> you can query it like http://domain/api/module?key=value&key=value2
+18:50 < jtanx> and then you could return something in json format or whatever is most suitable for the ajax query
+19:46 < jtanx> you can test it at http://mctx.us.to:8080/apoi
+19:46 < jtanx> woops, http://mctx.us.to:8080/api
+19:46 < jtanx> the only 'module' which will give a response of '200 OK' is sensors
+19:47 < jtanx> which currently spits back any arguments you pass to it
+19:47 < jtanx> eg http://mctx.us.to:8080/api/sensors?k=v
+19:50 < jtanx> hopefully it doesn't break
+20:44 < sam_moore> I'll take a look
+20:45 < sam_moore> Looks good
+20:45 < sam_moore> I'm writing a dummy thread for a sensor now
+21:04 < jtanx> the code behind it (in the cgi module) is a bit clunky right now though
+21:04 < jtanx> is there a meeting tomorrow?
+21:05 < sam_moore> I don't think so, sorry
+21:06 < jtanx> ok that's alright
+21:06 < sam_moore> Things aren't urgent (yet)
+21:07 < jtanx> heh
+21:12 < sam_moore> For the progress report: I'd like everyone to write a page individually, then we can summarize those in the group report
+21:12 < sam_moore> Well you don't have to write a whole page, and if you miss a week or so it's not a big problem
+21:16 < jtanx> ok
+21:17 < jtanx> i'll try to remember that
+21:18 < jtanx> do you think we need to keep track of how long we spend on this project
+21:18 < jtanx> for that 'cost estimate'
+21:28 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:23 < sam_moore> For the cost estimate: Yes, we are supposed to have a technical diary (hand written)
+22:23 < sam_moore> Including all notes and times worked on the project
+22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Fri Aug 16 2013
+09:48 < jtanx> I was wondering what sort of model you have for reading/storing sensor values and controlling actuators
+10:02 < sam_moore> At the moment each sensor has a thread that continuously polls the sensor and dumps data to a binary file
+10:03 < sam_moore> For reading there is a thread that fills a buffer from the file when it gets a request
+10:04 < sam_moore> It might be better to change to a single thread for sensors/actuators though
+10:04 < jtanx> yeah, I was about to say if it was necessary to have one for each
+10:05 < sam_moore> Probably not, if you had varying polling speeds it would be useful, because you could poll the fast sensors seperately from the slow ones
+10:05 < jtanx> how do you wish to pass the data to the fcgi module?
+10:06 < jtanx> right now
+10:06 < jtanx> i've kinda set it so
+10:06 < jtanx> there's this thing called a ModuleHandler
+10:07 < jtanx> so you can pass it some data (tba what this is), and it also receives the query string from the use
+10:09 < sam_moore> Well, the ModuleHandler gets called whenever the right HTTP request is made right?
+10:10 < sam_moore> So, that function retrieves the data it needs to respond to the request
+10:10 < jtanx> well rightnow the typedef is
+10:10 < jtanx> typedef void (*ModuleHandler) (Data *data, char *params);
+10:10 < jtanx> so it's up to you to write a module handler (eg SensorsHandler)
+10:11 < sam_moore> Ok, data's a bit of an ambigous name, so is that something passed to the ModuleHandler when the FastCGI gets a request?
+10:11 < jtanx> well the data thing was a placeholder for whatever sensors/actuators data there was
+10:11 < sam_moore> Is it meant to be sensor data, or is it a value that the user has passed through HTTP
+10:11 < jtanx> the query string is part of params
+10:11 < sam_moore> Ok, right, that makes more sense
+10:12 < sam_moore> My view had the ModuleHandler getting the appropriate data itself
+10:12 < jtanx> Ok
+10:12 < sam_moore> Given the params
+10:13 < jtanx> I'm just not really used to using global variables
+10:13 < sam_moore> The global sensors array?
+10:13 < jtanx> yeah
+10:13 < jtanx> i take it that's where you access data from?
+10:14 < sam_moore> Yes
+10:14 < jtanx> oh yeah one more thing, when you get a request, should it only return the latest data?
+10:20 < sam_moore> We should probably think some more about this as a whole group
+10:20 < sam_moore> So, you have a sensor that can (probably) poll a lot faster than you get requests via jQuery
+10:21 < sam_moore> You can write it so that you only actually query the sensor when you get a request, but then you're wasting the chance to get data that could be useful
+10:22 < sam_moore> Or you can have it so that the sensor is continuously polling (What my code is simulating at the moment)
+10:22 < sam_moore> With the continuosuly polling sensor; when you get a request, you can either return the most recent block of data you got
+10:23 < sam_moore> Or you can have it so that the data will be sent in sequential order (which is what my code currently does)
+10:23 < jtanx> hmm
+10:23 < sam_moore> I'm pretty sure continously polling is better than querying each time you get a request, since after all this is an experiment and you want the data
+10:23 < jtanx> yeah
+10:24 < jtanx> I agree with you there
+10:24 < jtanx> so you're saying, continuously poll and log the results
+10:24 < jtanx> and when a request comes in, send back all the data up to the point when the last request came in
+10:25 < sam_moore> Well that's what the server program I wrote simulates at the moment.
+10:25 < sam_moore> However it might be more sensible for the request to just get the most recent data.
+10:25 < jtanx> hmm
+10:25 < sam_moore> Ah, yeah that's probably better actually
+10:25 < jtanx> then you're logging more points than youdisplay
+10:26 < sam_moore> Yes, but you can always add a function to pull all the data points and save to a csv or something like that.
+10:26 < sam_moore> In fact I think we'd want to do that.
+10:27 < jtanx> yeah ok
+10:27 < jtanx> that sounds not too bad
+10:27 < jtanx> but if that's the case
+10:27 < sam_moore> If you actually use this for an experiment, you're not going to want to have to do all your analysis in a JavaScript GUI
+10:27 < jtanx> true
+10:27 < sam_moore> The GUI is for getting live information on the state of the system more than for data analysis
+10:27 < jtanx> but if that's the case you might want to allow direct access to the latest dataset
+10:28 < jtanx> instead of having to read from the file
+10:28 < jtanx> if that's possible
+10:28 < jtanx> then you can directly record the results in csv format
+10:28 < sam_moore> Yes, I thought about that; you can have a buffer of points accessed by the request thread easily enough
+10:29 < sam_moore> There are some difficulties though with managing the buffer
+10:30 < sam_moore> Wait, maybe it's easier than I though
+10:30 < sam_moore> Yeah, the reason I started saving stuff to a binary file was because I was thinking of the requests having to get the data in sequence
+10:32 < sam_moore> I have some other stuff to do today unfortunately
+10:33 < sam_moore> I have a feeling it won't be trivial to just access the most recent dataset, I'll have to think about it
+10:34 < sam_moore> However, currently it should be easy to change so that the request gets data from the end of the binary file, rather than keeping track of its position
+10:34 < sam_moore> The function QuerySensor is what I was thinking the SensorHandler would do to get data; it just fills a buffer and prints it at the moment
+10:35 < sam_moore> Binary file access is pretty fast, we could even just keep the binary file and change the data to csv when it goes to the client
+10:36 < jtanx> ok, I'll keep that in mind
+11:11 < sam_moore> Oh, you can replace the Data* pointer with a Sensor* pointer and then not have to use the global variable directly, that's probably best
+11:13 < jtanx> well it might not only be sensor data
+11:13 < jtanx> it could be actuator stuff or anything else
+11:13 < sam_moore> I suppose
+11:14 < jtanx> maybe I should change the typedef to void*
+11:14 < jtanx> then you can cast it to whatever
+11:14 < sam_moore> Yeah, that will work
+11:15 < sam_moore> Actuator stuff is going to be a bit of a seperate (hopefully easier) problem
+11:15 < sam_moore> In that case you can just wait for a query before doing anything
+11:15 < sam_moore> Anyway, I've distracted myself again, this is just too interesting :S
+11:15 < jtanx> hahaha
+11:16 < jtanx> anycase for the actuator you would have a separate handler function
+11:16 < sam_moore> Yes
+11:16 < jtanx> eg ActuatorHandler
+11:20 < jtanx> fcgi is pretty whack
+11:20 < jtanx> it replaces printf
+11:21 < jtanx> so when you printf (or fwrite for binary?), that gets sent to the client
+12:03 < jtanx> hey
+12:04 < jtanx> what if we stored stuff in an sqlite library
+12:04 < jtanx> sorry database
+12:04 < jtanx> on second thoughts nah
+15:02 -!- jtanx_ is now known as jtanx
+18:59 -!- jtanx_ is now known as jtanx
+21:28 < sam_moore> So, I did a bit of testing with sqlite vs a binary file
+21:28 < sam_moore> sqlite takes about 1000x as long for saving data
+21:28 < sam_moore> I haven't tested reading it back yet
+21:28 < sam_moore> But more worrying
+21:28 < sam_moore> I get a segmentation fault using sqlite
+21:29 < sam_moore> And it's in the sqlite library somewhere; not my test code
+21:29 < sam_moore> Running sqlite in valgrind shows a bunch of complaints about uninitialised values
+21:29 < sam_moore> So... I'd recommend we just use a binary file
+21:30 < sam_moore> A database is good for storing more complex data, but when you just need to store data recorded in a sequence, it's probably unnecessary
+21:36 < jtanx> yeah sqlite not so good for file performance
+21:36 < jtanx> because every insert it has to confirm the write to disk
+21:36 < jtanx> the segfault
+21:36 < jtanx> may actually be because you didn't initialse the mutex
+21:36 < jtanx> es
+21:36 < jtanx> i tried compiling it on mingw and it segfaults on the mutex unlock
+21:37 < sam_moore> Re: fcgi replacing printf - It probably calls dup2 to change stdout from the terminal to a domain socket or fifo that nginx listens to
+21:37 < jtanx> nah
+21:38 < jtanx> fcgi_stdio just has a bunch of defines
+21:38 < sam_moore> Oh really, that's wierd
+21:38 < jtanx> so printf becomes FCGI_printf
+21:38 < jtanx> so fcgi_stdio must be the first include in the fcgi module
+21:38 < sam_moore> I would have thought it was simpler to just change stdout than replace the whole printf function
+21:38 < sam_moore> But whatever, we're not implementing fcgi :P
+21:38 < jtanx> haha
+21:39 < sam_moore> Oh, the mutex needs initialising, yeah
+21:39 < sam_moore> But the test I did was just a serial program, no mutex
+21:39 < jtanx> ah
+21:39 < jtanx> well
+21:39 < sam_moore> We'll be using gcc to compile on the beaglebone/rpi
+21:40 < sam_moore> I think some implementations of pthreads need an initialiser but others don't, I'll have to check
+21:40 < sam_moore> But pthread_mutex_init doesn't show up in man pages on debian
+21:40 < jtanx> yeah it's not on ubuntu either
+21:41 < jtanx> have you ever worked with clang
+21:42 < sam_moore> No
+21:42 < jtanx> neither but it seems pretty cool
+21:45 < jtanx> when you compile it gives better diagnostic output when something goes wrong
+21:46 < jtanx> it's a drop in replacement for gcc
+21:47 < sam_moore> Interesting
+21:57 < jtanx> if you kept the file handles for the sensor data always open
+21:58 < jtanx> and immediately wrote to them when a data point is polled
+21:58 < jtanx> is there much performance difference to buffering first?
+22:05 < sam_moore> Yeah, it's probably better to keep the file handles always open
+22:05 < sam_moore> The operating system will use some kind of buffer for the file anyway
+22:06 < sam_moore> I've got some basic programs, maybe I'll make some performance graphs tomorrow
+22:07 < sam_moore> On the other hand, I need to do some of the meta stuff (list of tasks that need to be completed, etc) before Monday
+22:08 < sam_moore> I should look into a #define or something to initialise the mutexes if they need to be
+22:09 < sam_moore> Anyway, I need to sleep
+22:11 < sam_moore> I wonder how James and Callum are going, they haven't been in the channel for a while
+22:12 < jtanx> yeah, it's pretty quiet
+22:17 < sam_moore> If we can get a second meeting in the week, preferably a longer one that would be good
+22:18 < sam_moore> Particularly if we can start working on code at the same time
+22:18 < sam_moore> But we'll see
+22:18 < sam_moore> Everyone has other stuff to do after all
+22:18 < sam_moore> I'm spending way too much time on this unit compared to my others
+22:18 < sam_moore> Then again this unit will probably require the most work
+22:19 < sam_moore> Anyway, bye
+22:23 < jtanx> bye
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sat Aug 17 2013
+22:25 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sun Aug 18 2013
+21:53 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:37 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
+--- Day changed Mon Aug 19 2013
+11:43 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+13:34 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+20:07 < jtanx> just so you know, I'm changing the JSON functions
+21:04 < sam_moore> Ok, I already pushed some stuff to github
+21:05 < sam_moore> But we can get it to merge
+21:05 < sam_moore> I ended up just using printf to make part of the JSON in the SensorHandler anyway
+21:06 < jtanx> depending on where SensorHandler is
+21:06 < jtanx> that may or may not work
+21:06 < jtanx> inside of fastcgi.c it willwork
+21:06 < jtanx> outside it won't
+21:07 < jtanx> oh ok
+21:07 < jtanx> I see
+21:07 < jtanx> so that's fine
+21:08 < jtanx> it might be best not to use a do while loop
+21:08 < jtanx> because if no arguments are passed
+21:08 < sam_moore> Ah, right
+21:08 < jtanx> then the keypair function will return null
+21:09 < jtanx> while ((params = FCGI_KeyPair(params, &key, &value)))
+21:09 < jtanx> will work fine
+21:10 < sam_moore> The KeyPair function looks like it can return an empty string though, in which case I was getting the sensor_id parsed twice when I was testing it
+21:10 < jtanx> what was your input string?
+21:11 < sam_moore> "http://localhost/api/sensors?id=0"
+21:11 < jtanx> looks fine from this end
+21:11 < jtanx> http://mctx.us.to:8080/api/sensors?id=0
+21:11 < jtanx> it might be because of your do while loop
+21:12 < jtanx> yeah it will be because of that
+21:12 < sam_moore> The do while loop causes problems when there is an empty string
+21:13 < sam_moore> ie: No parameters are passed
+21:13 < jtanx> ok let's just put it this way; FCGI_KeyPair was designed to use a while loop
+21:13 < sam_moore> Ok, sure
+21:13 < sam_moore> I had some problems with just a while loop, but I'll try again
+21:13 < jtanx> yeah about that JSON stuff
+21:13 < jtanx> I'm still trying to think of a good way to do that
+21:13 < jtanx> especially with the array stuff
+21:19 < sam_moore> I'm not sure what I did before, but a while loop seems ok now
+21:19 < jtanx> heh
+21:21 < sam_moore> Ok, I have to go now
+21:21 < sam_moore> I might not be able to do much tomorrow, we'll see
+21:22 < jtanx> ok yep
+21:35 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+23:14 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:35 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Aug 20 2013
+15:06 < Callum> hey same
+15:06 < Callum> sam*
+15:20 < jtanx> :>
+15:22 < Callum> he literally set himself to away as soon as i said that
+15:45 < jtanx> urgh this json stuff is doing my head in
+15:57 < sam_moore> Callum: I've been set to away since last night
+15:57 < Callum> o.O not according to my client
+15:58 < sam_moore> Anyway, we are definitely using the Beaglebone, Electronics has ordered one, they seemed to think they'd have to program it but I corrected them
+15:58 < Callum> ...why would they have to program it? wtf did they think we were doing?
+15:59 < sam_moore> They probably thought all we had to do was the GUI and not any of the other software? I don't know. But the guy seemed relieved anyway.
+15:59 < Callum> and was gonna ask if you remembered anything about the pi meson decay question for physics (how do you get the anti-neutrinos momentum, or do you assume it to be 0 as well? but then it doesnt really make sense with conservation of momentum)
+16:00 < sam_moore> Woah, I don't remember the assignments in that much detail
+16:00 < Callum> was hoping you would :p
+16:00 < sam_moore> No, I just have vague memories of algebra
+16:01 < sam_moore> And looking through notes
+16:01 < Callum> hmm. i cant seem to find anything in the notes
+16:01 < Callum> because he says to assume the rest mass of the anti-neutrino is 0
+16:02 < Callum> and i don't really remember much in regards to energies and 0 rest mass ;/
+16:02 < jtanx> I talked to someone who did computer vision before
+16:02 < jtanx> and he's really doubtful that you can get accurate readings off a webcam
+16:02 < sam_moore> Callum: I don't think you can assume the momentum is zero, other than that, I don't have much to offer
+16:02 < Callum> the question also says to have it in terms of m(pi) m(e) and c
+16:03 < Callum> and yea thats what i thought. it doesnt make sense to do that. just cant remember how to do it D;
+16:03 < Callum> @jeremy yea well, its a pain but possible
+16:04 < Callum> really comes down to how good your camera is/sampling rate/how quickly you can process it.
+16:04 < sam_moore> How about you do some experimenting with a webcam and see what you can do with it?
+16:04 < Callum> but you can get some pretty good webcams nowadays (but then again the better it is the longer it takes to process)
+16:04 < jtanx> personally, I don't think it will work
+16:04 < sam_moore> It looks like we might just end up streaming images diretly to a website
+16:04 < Callum> i don't have any
+16:04 < Callum> yea well even if thats all we do we still need the camera
+16:05 < Callum> spose i could use my laptop one but i doubt that would be very good
+16:05 < Callum> could run it through the canny algorithm and see what it produces
+16:06 < sam_moore> Sounds like an idea
+16:07 < sam_moore> A good idea specifically
+16:07 < jtanx> about the sensorhandler
+16:07 < sam_moore> Yes?
+16:07 < jtanx> do you envision leaving it in fastcgi.c permanently
+16:07 < jtanx> or for that matter any other handlers
+16:07 < sam_moore> I was kind of thinking there would be a "handlers.h" and "handlers.c"
+16:08 < sam_moore> Just to make things more organised
+16:08 < jtanx> yeah
+16:08 < jtanx> I'm trying to export enough of the functionality
+16:08 < jtanx> to do that
+16:08 < jtanx> but the json thing is annoying
+16:08 < jtanx> especially when you need to spit out arrays
+16:09 < jtanx> unless you have something like FCGI_Printf
+16:09 < jtanx> and it's up to you to format it correctly
+16:09 < Callum> bloody physics lecture video is laggy. gonna have to download it and hope for the best. fuck echo
+16:10 < jtanx> compared to lectopia you get 2x filesize with no visible benefit in quality
+16:10 < Callum> they're both shit.
+16:10 < sam_moore> You could have seperate "BuildJSON_Key" and "BuildJSON_Value" functions, with a "BuildJSON_ValueArray" maybe
+16:10 < Callum> haha
+16:11 < sam_moore> FCGI_Printf is Ok though, it's not too much formating
+16:11 < jtanx> the problem with the buildjson_* stuff
+16:11 < jtanx> is it gets very verbose
+16:12 < jtanx> and you can probably come up witha situation that breaks it too
+16:12 < jtanx> and don't get me started on value types
+16:12 < sam_moore> Haha
+16:14 < sam_moore> We can always just send plain text and make James turn it into JSON :P
+16:14 < jtanx> ahaha
+16:14 < jtanx> yeah that could work
+16:15 < jtanx> mm
+16:15 < jtanx> this is where java is good
+16:15 < jtanx> or any other higher level language
+16:21 < jtanx> ok so it's a bit of both, but how about: FCGI_JSONKey(key) and FCGI_JSONValue(format, ...)
+16:22 < sam_moore> That looks good
+16:25 < jtanx> I'm also adding long/double types for the BuildJSON function, just for convenience
+16:25 < jtanx> any preference to naming conventions?
+16:26 < jtanx> FCGI_BuildJSONLong
+16:27 < sam_moore> Seems OK
+16:28 < sam_moore> I need to go do some ENSC1001 stuff (hooray)
+16:29 < jtanx> yuck
+16:30 < Callum> hhaha
+16:30 < Callum> have fun :p
+16:30 < Callum> although i cant really talk. about a days worth of physics and a days worth of ensc3016 shit i should get through, on top of mctx and geng4402 stuff. yay for being behind already
+16:38 < Callum> well iv got an answer for the first part (second part should be the same process). just hope its right :s
+16:46 < jtanx> ok, time to merge this into the server code
+19:47 < jtanx> hmm interesting - it crashes if compiled with clang but not with gcc
+19:49 < jtanx> probably just a bug in clang 3.2
+20:08 < jtanx> ok, just submitted a pull request to update the fastcgi stuff
+20:08 < jtanx> for now I moved Sensor_Handler to sensor.c
+20:09 < jtanx> the status codes have all changed
+20:09 < jtanx> If you absolutely cannot process anything given the input arguments, you call FCGI_RejectJSON
+20:10 < jtanx> If you fail for some other reason (e.g unauthorized access), you use FCGI_BeginJSON with the appropriate status code
+20:10 < jtanx> With RejectJSON, it sends a HTTP 400 code so any query through AJAX/jQuery will fail with no extra info
+20:11 < jtanx> With BeginJSON, the HTTP code is always 200 OK, so you are able to transmit extra info if it failed for another reason
+20:12 < jtanx> BeginJSON will automatically add the module handler name + the status code
+21:47 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Wed Aug 21 2013
+11:57 < jtanx> hmm
+11:57 < jtanx> I just had a play with the sensor stuff
+11:57 < jtanx> and I trialled a 'double buffer' scheme
+11:57 < jtanx> instead of the binary file idea
+11:57 < jtanx> seems to work okay, and it guarantees that a point won't be returned to the user if they have already received it
+12:35 < jtanx> urgh
+12:35 < jtanx> just worked through some stupid bug
+12:37 < jtanx> I think it's because make didn't recompile something because it thought it hadn't changed
+12:38 < jtanx> probably the header files
+12:50 < jtanx> you can see the double buffer method in this branch: https://github.com/jtanx/MCTX3420/tree/doublebuffer
+12:58 < jtanx> one issue though is that writing out csv instead of binary file takes up a lot more space
+14:49 < james__> Hey
+14:50 -!- james__ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Thu Aug 22 2013
+13:20 < callum> hey
+15:07 < callum> sam you still at uni?
+15:22 < callum> or jeremy if you remember what he used to compile the file. i'v managed to get it to recognise the header files but now its complaining about not being able to find the libraries.
+15:34 < jtanx> um
+15:34 < jtanx> I can't remember
+15:34 < jtanx> didn't you use pkg config to find out
+15:36 < jtanx> try this http://opencv.willowgarage.com/wiki/CompileOpenCVUsingLinux
+22:08 < sam_moore> gcc -o opencv opencv.c -I/usr/include/opencv -lopencv_core -lopencv_highgui -lopencv_imgproc
+22:08 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+22:08 < sam_moore> Oh... there's no one here
+22:08 < sam_moore> Well, if you read the IRC logs when they're commited to git, you'll see it. Good luck.
+--- Day changed Fri Aug 23 2013
+07:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+08:59 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+10:12 -!- jtanx [
[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
+12:30 < jtanx_> um
+12:30 < jtanx_> do you know how you connected the relay board to the sensor board
+12:30 < jtanx_> for the soldering lab
+12:45 < jtanx_> and what sort of wire did you use?
+12:58 < jtanx_> brb
+12:58 -!- jtanx_ [
[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
+--- Log opened Sat Aug 24 17:07:53 2013
+17:07 -!- ServerMode/#mctxuwa_softdev [+nt] by irc.eversible.com
+17:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+17:07 -!- Irssi: Join to #mctxuwa_softdev was synced in 1 secs
+17:08 -!- You're now known as sam_moore
+--- Day changed Mon Aug 26 2013
+11:12 <@sam_moore> Thought I might have the wrong server
+17:18 <@sam_moore> I do have the wrong server!
+17:19 -!- sam_moore [
[email protected]] has left #mctxuwa_softdev [I have the wrong server!]
+--- Log closed Mon Aug 26 17:19:05 2013
+--- Log opened Mon Aug 26 17:19:34 2013
+17:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+17:19 -!- Irssi: Join to #mctxuwa_softdev was synced in 5 secs
+17:19 < sam_moore> !motd
+17:20 < sam_moore> '!motd'
+17:20 < sam_moore> MctxBot: You're broken
+17:20 < sam_moore> Oh wait, never mind
+18:08 < jtanx> :P
+18:09 < jtanx> you can change the message if you want
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Aug 27 2013
+07:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+19:11 < jtanx> lol
+19:11 < jtanx> the camera that we were using for the soldering lab inserted a bunch of wavy lines/static into the video
+19:12 < sam_moore> It's an effect
+19:14 < jtanx> nah
+19:14 < jtanx> the camera was actually broken
+19:15 < sam_moore> (I figured that)
+19:15 < sam_moore> You could pretend it's supposed to be an 80s style video?
+19:15 < jtanx> yeah that could work
+19:16 < jtanx> have you done it yet?
+19:18 < sam_moore> No :S
+19:20 < jtanx> well
+19:21 < jtanx> according to the manual, you need to connect a wire from R5 on the sensor board to the relay board
+19:21 < jtanx> problem was we already chopped off the lead on R5
+19:22 < jtanx> another group connected the wire to the LEd though
+19:22 < jtanx> seemed to work
+20:02 < jtanx> so are we using clock_gettime?
+20:08 < sam_moore> I think so, we can use CLOCK_MONOTONIC_RAW if we are paranoid about the system time getting changed
+20:08 < sam_moore> Or we can just use CLOCK_REALTIME if we aren't
+20:09 < jtanx> I thought CLOCK_MONOTONIC was supposed to be best, because the RAW version wasn't compensated for temp/other stuff
+20:10 < jtanx> http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic
+20:10 < jtanx> about the FCGI loop blocking
+20:10 < jtanx> you can switch to FCGX_ methods
+20:10 < jtanx> I think
+20:11 < jtanx> but is it really necessary
+20:20 < jtanx> about the valgrind comment in sensors.c
+20:20 < jtanx> this is probably it: http://stackoverflow.com/questions/5844242/valgrind-yells-about-an-uninitialised-bytes
+20:23 < sam_moore> It's probably not necessary to stop the FCGI loop blocking, don't worry about it
+20:25 < sam_moore> Yeah, I didn't initialise the buffers anywhere
+20:25 < jtanx> actually I can't reproduce that message
+20:25 < sam_moore> Hmm
+20:26 < jtanx> about the sensor times
+20:27 < jtanx> what about if you all reference it relative to some point
+20:27 < jtanx> eg
+20:27 < sam_moore> The epoch :P
+20:27 < jtanx> lol
+20:27 < jtanx> I mean
+20:28 < jtanx> when you get sensor data, you store the difference in time between the start of recording and now
+20:28 < sam_moore> Sure, that makes more sense
+20:29 < sam_moore> Just give the client the start of recording time and they can convert it to a time of day / day in the calendar themselves
+20:30 < jtanx> yeah
+20:30 < jtanx> you could have a specific request to return the starting time
+20:30 < jtanx> then it's implicit for all requests
+20:30 < jtanx> btw I submitted a pull request for the nginx configs
+20:32 < sam_moore> Ok
+20:32 < sam_moore> I've added you to collaborators so you can merge them yourself if you need to
+20:33 < jtanx> ok
+20:35 < jtanx> huh
+20:35 < jtanx> http://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
+20:41 < sam_moore> Nice
+20:42 < sam_moore> "Currently you can not access Ethernet" Not so nice
+20:42 < sam_moore> Although this is dated 2011
+--- Day changed Wed Aug 28 2013
+10:39 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+16:31 < jtanx> huh
+16:31 < jtanx> firefox's javascript debugger is pretty cool
+16:31 < sam_moore> Firebug? Yeah
+16:35 < jtanx> nah the inbuilt one
+16:35 < jtanx> firebug's good for inspecting html though
+16:35 < jtanx> haven't used firebugs js debugger yet
+16:35 < sam_moore> Oh, I didn't know they had an inbuilt one
+16:36 < jtanx> Ctrl+Shift+K
+16:36 < sam_moore> Of course I normally use Iceweasel, which is currently built as firefox 10.0.2 with a different name
+16:36 < jtanx> well that's about 10 releases behind
+16:36 < sam_moore> That looks pretty similar to firebug anyway
+16:55 < jtanx> inline conditionals in javascript are whack
+16:55 < sam_moore> I haven't done much javascript, but a lot of it does seem whack
+16:56 < sam_moore> jtanx: What are you working on in JavaScript?
+16:56 < jtanx> unit tests
+16:57 < sam_moore> Cool
+17:01 -!- Callum_ is now known as Callum
+17:18 < jtanx> javascript in general is annoying me though
+17:25 < Callum> when exactly is this soldering lab due? fucking thing.
+17:27 < jtanx> next friday
+17:27 < Callum> it says week 5 on lms
+17:27 < jtanx> sept 6
+17:27 < Callum> where's it say this?
+17:27 < jtanx> yeah he made an announcement
+17:27 < jtanx> that it's wrong
+17:27 < jtanx> somewhere
+17:28 < Callum> sigh. this unit..i swear
+17:28 < Callum> if it really is next week then i'd be so relieved
+17:28 < Callum> wow
+17:28 < Callum> he made an announcement today..
+17:28 < Callum> wait yesterday
+17:29 < jtanx> still got that central plant fbd to do
+17:29 < Callum> why hasnt LMS emailed me a notification? (/end spam)
+17:29 < Callum> yea i know
+17:29 < Callum> which i think i have it pretty much done
+17:29 < Callum> not 100% sure on it though
+17:29 < Callum> and whether to add pumps and shit into it
+17:29 < jtanx> what did you have on it?
+17:30 < Callum> HA as i say that i check my phone and i have the message about the announcement
+17:30 < jtanx> and what did you call the chiller things?
+17:30 < Callum> pretty much just the 4 chillers, a line showing it can go back (they're literally called chillers ahha(
+17:31 < Callum> then i had another part to show the chillers (evaporation/condensor/compressor and cooling tower is connected to condenser)
+17:31 < jtanx> ook
+17:31 < Callum> however
+17:32 < Callum> im not sure about the input/output of the chiller
+17:32 < Callum> because stuff online shows it to be the evaporator
+17:32 < Callum> but isnt it water being pumped?
+17:32 < jtanx> I think there were pumps on the output
+17:33 < jtanx> were there three outputs?
+17:33 < Callum> also not sure if i should/wherte to add the tank (yea ofc theres pumps but not sure to put them in to the diagram, pretty much everything is pumped)
+17:33 < Callum> outputs where?
+17:33 < jtanx> North/Sout/East distribution things
+17:33 < jtanx> iirc
+17:33 < jtanx> yeah not sure whether to add tank or not
+17:34 < Callum> oh that, i didnt bother with that
+17:34 < Callum> just how did the chiller connect with the rest of the plant?
+17:34 < Callum> was the evaporator the input/output?
+17:34 < Callum> because the chiller feeds out to the water tower and the tower feeds back into the chiller (i think)
+17:36 < Callum> also what was the thing called? that allowed water to flow back and forth bypassing the chillers. back something?
+17:36 < Callum> really they should have told us before we went in we had to do this. some lazy fucks like me dont read the outline so i didnt take notes..or try to commit stuff to memory :po
+17:39 < jtanx> the bypass?
+17:39 < jtanx> I haven't gone into detail
+17:39 < jtanx> so I just have chiller
+17:39 < jtanx> and cooling tower
+17:39 < jtanx> maybe I should
+17:40 < Callum> remember how tehre was 4 chillers, and they would only run what was needed.
+17:40 < jtanx> yeah
+17:40 < jtanx> how many cooling towers?
+17:40 < Callum> and if they had more than they needed there was a pipe to flow back, or if they had some chilled water from the tanks or w.e it bypassed chillers
+17:40 < Callum> i dont know, but im not sure how to show it all
+17:40 < Callum> im sure what iv got is somewhat decent
+17:41 < jtanx> I used visio and I ended up spending so much time trying to get the lines rihgt
+17:41 < jtanx> probably would have been faster to hand draw it
+17:41 < jtanx> still not finished too
+17:41 < Callum> haha im fiarly sure i read somewhere it was hand drawn :p
+17:41 < jtanx> meh I suck at drawing
+17:42 < Callum> maybe not. "This is to be drawn and annotated on single A4 page"
+17:42 < Callum> i dont think they'll be picky
+17:42 < jtanx> and there's lines everywhere
+17:42 < Callum> really? how do you have lines everywhere?
+17:42 < jtanx> ok so chiller
+17:42 < Callum> it's a fairly simple system. unless i'v done it wrong :s
+17:43 < jtanx> has warm chilled water (1), chilled coolant (2), hot coolant (3), chilled chilled water(4), control line (5), (maybe) sensor back to controller (6)
+17:43 < jtanx> that's ~5 lines in/out of one box?
+17:44 < Callum> hmm. havent included coolant or control/sensor
+17:44 < Callum> maybe i should :S
+17:44 < jtanx> and an operator
+17:44 < jtanx> to the controller
+17:45 < Callum> thing is it asked for a high level FBD though
+17:45 < Callum> which means not very detailed
+17:45 < Callum> or maybe it didnt?
+17:45 < jtanx> yeah, so do you need to show condensor/evaporator
+17:45 < jtanx> I just have a chiller box
+17:46 < jtanx> anyway... afk ~10 mins
+17:46 < Callum> the condensor/evaporater is part of the chiller isnt it?
+17:46 < Callum> ok
+18:10 < Callum> anyone finished reading chapter 4 of the notes?
+18:11 < jtanx> what's that
+18:11 < Callum> sensors
+18:12 < Callum> so dull :l
+18:12 < Callum> and pretty much no chance to remember enough of it. quiz tomorrow is going to be fun..
+18:12 < jtanx> oh
+18:13 < jtanx> shit
+18:13 < jtanx> have to study for that
+18:13 < Callum> rofl
+18:14 < jtanx> :/
+18:15 < Callum> gonna just have to wing most of them again like last time most likely.
+18:15 < jtanx> probably
+18:15 < jtanx> Well, the unit testing thing works http://mctx.us.to:8080/unit-tests/
+18:15 < jtanx> now what unit tests should there be
+18:18 < Callum> not sure.
+18:25 < Callum> brilliant! the notes show a false colour image built from a black and white image...while printed in black and white.
+18:34 < jtanx> :P
+19:50 < jtanx> um
+19:50 < jtanx> did we get around to doing the sparkplus thing
+19:54 < jtanx> we need to do it before the end of the week
+19:54 < Callum> umm.
+19:54 < Callum> actually justin already set up the group
+19:54 < Callum> so you need to hurry up and join before we have to recreate the group :P
+19:54 < jtanx> nah it expired
+19:54 < Callum> wait already?
+19:54 < Callum> zzz
+19:55 < jtanx> 5 hr deadline
+19:55 < Callum> and adrian said it was 24Hr, whats with this 5 hour shit
+19:55 < jtanx> so... we need to try again
+19:55 < jtanx> when everyone's available
+--- Day changed Thu Aug 29 2013
+09:16 < jtanx> firefox blocks ajax calls if you try to run the file locally :/
+09:45 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+14:25 < james__> Hey Jeremy. Is there a way to find my login hash key if i am already logged into the api?
+14:28 < jtanx> um
+14:28 < jtanx> right now you should store it
+14:29 < jtanx> just declare a global variable and set it to the hash
+14:30 < jtanx> or if you have made a class
+14:30 < jtanx> just make it an element
+14:31 < james__> I'm still logged in from ages ago and i can't logout so i can get a different key that works
+14:31 < jtanx> that
+14:31 < jtanx> ok
+14:31 < james__> Possibly a bug that needs fixing?
+14:31 < jtanx> so the way it works right now is there's a 3 minute timeout on the key
+14:31 < jtanx> no
+14:31 < jtanx> there's actually two layers
+14:32 < jtanx> the password that you enter first (mctxadmin) is what's called HTTP basic authentication
+14:32 < jtanx> this lets you gain access to /api/login
+14:32 < james__> Well i tried loging in again and its saying i am already logged in
+14:32 < jtanx> when you reach /api/login you get the access key
+14:32 < jtanx> there's a three minute timeout on the key
+14:32 < jtanx> if you wish to invalidate the key
+14:33 < jtanx> you call
+14:33 < jtanx> /api/login?end
+14:34 < jtanx> you can force getting a key by also calling /api/login?force
+14:34 < james__> right. well it worked this time
+14:34 < james__> Thats weird
+14:34 < jtanx> so the only thing that the key prevents is stopping accidental concurrent use
+14:34 < james__> Fair enough
+14:35 < jtanx> Calling /api/login?force will force a new key to be generated and the old one to be invalidated
+14:35 < james__> Okay
+14:35 < jtanx> btw as I was working on unit testing
+14:35 < jtanx> I did a function to retrieve the json data
+14:36 < jtanx> http://mctx.us.to:8080/unit-tests/unit-tests.js
+14:37 < james__> I will have a look. I have some buttons working and stuff. Working on putting them in a seperate script file for easier editing etc
+14:37 < james__> They don't seem to be playing nice at the moment
+14:37 < jtanx> ok
+14:38 < jtanx> how come it takes so much effort to get some buttons working
+14:39 < james__> Getting the css to mesh with the js
+14:40 < james__> I have buttons fine
+14:40 < james__> And they work
+14:40 < jtanx> maybe you should get the functionality to work first
+14:40 < jtanx> with the ajax queries
+14:40 < jtanx> before worrying about styling them
+14:40 < james__> I have the functionality pretty much working
+14:41 < jtanx> so the querying works?
+14:41 < james__> But i want the styling to work before we scale it up
+14:41 < james__> That way its less hassle to fix it later
+14:41 < jtanx> could you post it to git?
+14:41 < jtanx> it'd be cool to have a look
+14:45 < james__> The way i am thinking about having it set out is having a central index.html which just imports all the js. The js will contain all the functionlity seperated in to similar functions. Ie. all the buttons in one script
+14:46 < jtanx> right
+14:46 < james__> That should allow for ease of scaling and editing
+14:46 < james__> Also changing id's and stuff
+15:46 -!- james__ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+21:09 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+23:18 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Fri Aug 30 2013
+17:06 < jtanx> say you want to perform a command
+17:06 < jtanx> eg move an actuator
+17:07 < jtanx> and suppose checks have to be made against other sensors to ensure that this command is good to go
+17:07 < jtanx> how are those checks going to be made?
+18:10 < sam_moore> The Actuator Handler will call some sanity check against the most recent sensor data
+18:11 < sam_moore> If they aren't, it will respond with some appropriate JSON or HTTP status code
+18:11 < sam_moore> eg: "Try again later when the pressure is in the right range", or "Don't do that you silly person"
+18:15 < jtanx> ._.
+18:21 < jtanx> I wonder if there's a way to pull from your git repository without creating the 'merge branch master from...' commits
+18:22 < sam_moore> I don't think so
+18:22 < jtanx> I tried playing with rebasing but it doesn't work out so well
+18:40 < jtanx> ok so I've committed some stuff to my repository that changes the handling of controls/actuators/login
+18:41 < jtanx> I'm not sure if it's the best way to do it
+18:41 < jtanx> though
+18:41 < jtanx> What I did was get rid of /api/login
+18:41 < jtanx> and instead have /api/control
+18:41 < jtanx> All of the control code (eg actuators but may be other controls? Start/stop the whole thing?) has been moved to controls.c
+18:42 < jtanx> You still need to supply username and password to access /api/control
+18:42 < jtanx> and what was previously called the 'authorization key' is now the control key (ie who has control)
+19:00 < sam_moore> Ok, I'll take a look at it later
+19:01 < sam_moore> Don't worry about the merge messages, it's not a big deal
+19:06 < jtanx> ok thanks
+20:27 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:03 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sat Aug 31 2013
+15:30 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+20:48 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sun Sep 01 2013
+14:17 < jtanx> it'd have been cool to have written then server in python
+14:19 < Callum> gah havent done much for this project this week. not sure what i should do either
+14:19 < jtanx> hmm
+14:19 < Callum> so far behind in one of my units too. haha joys of uni
+14:19 < jtanx> lol
+14:20 < jtanx> werent we meant to get the camera stuff working or something
+14:21 < Callum> well yea but thats more rosher getting stuff working on his end. still not really sure what's going on. need to find an efficient way to transfer data (which would be directly streaming but it seemed adrian wanted some sort of processing)
+14:21 < Callum> guess i could start working on edge detection
+14:21 < jtanx> james hasn't got much done afaik
+14:21 < Callum> nah dont think he ahs
+14:22 < jtanx> but man I was looking at the javascript stuff
+14:22 < jtanx> and it's really annoying
+14:22 < jtanx> everything in javascript is asynchronous
+14:22 < jtanx> so you have a callback for an AJAX query, and it gets executed some time in the future
+14:23 < jtanx> it's really hard to pass variables to the callback and then also retrieve them
+14:23 < Callum> hmm
+14:23 < jtanx> i'm probably not doing it in the right fashion or something
+14:28 < Callum> not sure. don't really understand this stuff myself. havent done much/any
+14:45 < jtanx> flask is so cool
+15:01 < jtanx> oh
+15:02 < jtanx> maybe we can use cookies to store authorization
+15:02 < jtanx> instead of in javascript
+15:02 < jtanx> hmm
+15:02 < jtanx> http://stackoverflow.com/questions/15722795/how-to-create-a-cookie-with-fastcgi-nginx-in-c
+15:57 < sam_moore> Maybe a cookie is better, but couldn't you have a global variable that the JavaScript code sets in the callback?
+15:57 -!- Irssi: #mctxuwa_softdev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
+15:59 < sam_moore> Ok, I'll do the simulated "digital" sensor and actuator
+15:59 < sam_moore> We should make some kind of minimal gui in JavaScript
+16:00 < sam_moore> I'm not sure what James has done, but there's nothing under git
+16:02 < sam_moore> http://www.flotcharts.org/flot/examples/ajax/index.html is a good starting point for updating sensor graphs
+16:03 < sam_moore> jtanx: I wouldn't worry about the login/authentication too much for this week
+16:04 < jtanx> james said he got the buttons working but that's about it
+16:04 < jtanx> he's more concerned about issues with styling them than getting a fully fledged gui
+16:04 < sam_moore> I think actually having a gui is more important than having a pretty gui
+16:04 < sam_moore> At the moment anyway
+16:05 < jtanx> yeah
+16:05 < jtanx> it would be great to have *something*
+16:05 < jtanx> the problem with js
+16:05 < jtanx> is from what i've seen, the callback occurs in the jQuery file
+16:06 < jtanx> so you can't set global variables in say sensors.js
+16:06 < jtanx> and expect to be able to read/set them in the callback
+16:06 < sam_moore> Hmm, that's wierd
+16:06 < jtanx> what really shits me about javascript is variable handling
+16:06 < sam_moore> Hang on, let me have another look at the only project I ever used jQuery for... :P
+16:07 < jtanx> you can pass one/none/more than specified parameters
+16:07 < sam_moore> It was a chess game, so it should definietly be possible to modify variables in the callback function
+16:07 < jtanx> yeah there's probably a way, I just don't know it
+16:08 < jtanx> about the actuators
+16:08 < jtanx> I've already got something working in my repository
+16:08 < jtanx> but I don't really like how I've done it
+16:30 < sam_moore> I'm making a minimal gui (it will be able to plot something, and have a button); we can either ditch it or improve on it later
+16:31 < jtanx> sounds good
+16:35 < sam_moore> Callum: If you want to make a (really awful but possibly looking good enough at this stage for Adrian) "streaming" images thing
+16:35 < sam_moore> You can have your program continuously save to a file
+16:35 < sam_moore> And a html page that just has "<meta http-equiv="refresh" content="0">" in the header
+16:35 < sam_moore> With a link to the image
+16:36 < Callum> alright il look into it
+16:36 < sam_moore> It's absolutely aweful, but it will give the effect of a really laggy video
+16:36 < jtanx> nice :P
+16:36 < sam_moore> You can improve it (if you get time) by having 2 images instead of one, with a symbolic link to swap between them
+16:38 < sam_moore> I'll bring the raspberry pi with the webcam tomorrow and we'll put everything on it to show Adrian
+16:38 < jtanx> hehehe
+16:38 < jtanx> can you install ffserver on the raspi?
+16:39 < sam_moore> Probably
+16:40 < jtanx> actually
+16:41 < jtanx> does our code run on the raspi?
+16:50 < sam_moore> Yes, at the moment
+16:54 < Callum> how are we integrating my code into it?
+17:01 < sam_moore> Keep it as a seperate process for now
+17:01 < Callum> alright
+17:01 < sam_moore> I'll modify the "run.sh" script to start both of them
+17:01 < sam_moore> Sigh javascript
+17:01 < sam_moore> So useful and yet so horrible
+17:02 < sam_moore> Still, I think if we can get our heads around it it is actually a nice way to do this
+17:09 < jtanx> the camera thing or the api or both?
+17:24 < sam_moore> The API
+17:24 < Callum> ok so how do i link to the image? (
+17:24 < sam_moore> Just put a html file in the /server directory for now
+17:25 < sam_moore> With <img src="path_to_image"> in the body somewhere
+17:29 < Callum> where are we going to put the images?
+17:31 < sam_moore> /server/images (?)
+17:31 < sam_moore> Wherever it seems logical I guess
+17:33 < sam_moore> If either of you are available earlier on Monday, I'm free for pretty much the whole day
+17:33 < sam_moore> Do you want to meet earlier and actually do coding as a group?
+17:37 < sam_moore> Dammit why does javascript remove the [] brackets when printing string representations of arrays
+17:37 < sam_moore> How are you supposed to tell what dimensions the array has...
+17:37 < jtanx> if you want sample code of how I printed the array of sensor values
+17:37 < jtanx> see the unit tests
+17:37 < sam_moore> Ok, thanks
+17:37 < jtanx> for (var i = 0; i < data.data.length; i++) {
+17:37 < jtanx> result += data.data[i][0] + ":" + data.data[i][1] + ", ";
+17:37 < jtanx> }
+17:56 < Callum> ok well iv done trhat, i think. you should probably check it to make sure its right
+17:58 < Callum> sent pull request. and i'v got food so brb
+17:58 < sam_moore> Ok, thanks
+17:59 < sam_moore> jtanx: You're right, altering variables on a successful ajax call is a pain in the ass
+17:59 < jtanx> hehe
+17:59 < sam_moore> ... You can modify html attributes really easily though
+17:59 < jtanx> true
+17:59 < jtanx> that's what I was thinking
+17:59 < sam_moore> Must resist urge to store data in a comment
+17:59 < jtanx> have a hidden input field?
+18:01 < jtanx> I must say that the firebug debugger and inbuilt web console were both quite useful
+18:02 < sam_moore> Yes, I've got firebug running
+18:04 < jtanx> I was looking at flask and it was ridiculously easy to set up a similar API in python
+18:05 < sam_moore> Do you want to change to python then?
+18:06 < sam_moore> Don't we still have to do the javascript though?
+18:07 < sam_moore> The API we have at the moment isn't that terrible
+18:07 < jtanx> nah
+18:07 < jtanx> it's probably best to stick with what we have
+18:07 < jtanx> the javascript stuff would remain the same yeah
+18:09 < sam_moore> Ok
+18:26 < sam_moore> Right... you can update global variables on a successful AJAX request
+18:27 < sam_moore> If you put "var" in front of the variable in the global scope then the AJAX callback will just make a new local variable and modify that -_-
+18:27 < sam_moore> But if you Don't put the "var" there, it will work
+18:40 < jtanx> lol
+18:41 < jtanx> but using global variables in javascript can get.... messy
+18:41 < sam_moore> Mmm
+18:42 < sam_moore> But doing pretty much *anything* in javascript is messy
+18:42 < jtanx> yeah
+18:42 < jtanx> true that
+18:43 < sam_moore> I wonder...
+18:43 < sam_moore> Should we just have one html page for each sensor/actuator
+18:43 < sam_moore> And then the user can open multiple tabs?
+18:45 < sam_moore> That's probably not very nice though
+18:46 < sam_moore> I think we should return data about multiple sensors at a time
+18:51 < jtanx> you'd probably want it all on one page
+18:51 < sam_moore> Yeah
+18:51 < jtanx> how many sensors are we talking about again
+18:51 < sam_moore> 6 or 7 I think, + a camera
+18:51 < jtanx> oh yeah
+18:51 < sam_moore> Oh well, we can redesign it later
+18:51 < jtanx> I guess we can design for max 7
+18:52 < sam_moore> But it might be a good idea to query multiple sensors in one ajax request
+18:53 < jtanx> yep
+18:53 < jtanx> supply more than one id in a go?
+18:53 < jtanx> could have an array (max size 7) that holds all the sensors you want to get data for
+18:53 < jtanx> i guess
+18:55 < sam_moore> It's probably more flexible to just add a "getall" key to the sensor module
+18:57 < jtanx> oh yeah
+18:57 < jtanx> I'm free until 12 tomorrow
+18:57 < jtanx> do you want to work together before that?
+18:58 < sam_moore> Sure
+18:59 < sam_moore> Try G19 again, but if that doesn't work we can go to the physics lab, or the computer science labs
+19:01 < jtanx> yeah ok
+19:02 < jtanx> what time do you want to start?
+19:04 < sam_moore> I'll probably get in around 9 or 10, depending on how much sleep I get
+19:04 < sam_moore> Let's say 10:00
+19:05 < sam_moore> Got to go, I'll be back later
+19:05 < jtanx> ok
+21:35 < sam_moore> I'm just going to use the same Sensor stuff for digital sensors
+21:36 < sam_moore> Adding a second type of sensor seems needlessly complicated
+21:36 < sam_moore> 1 = on and 0 = off
+21:37 < sam_moore> Probably do the same for actuators (just have some sanity checks on the values you can set, both at the client and the server)
+21:38 < jtanx> usually I'd just say 0 is off and not 0 is on
+21:38 < sam_moore> Haha, fair enough
+21:39 < jtanx> I kinda hate over-checking stuff :P
+21:39 < sam_moore> The actual GetData function has to return something reasonably sane though
+21:39 < sam_moore> It's easy to just make it only return 0 or 1
+21:39 < jtanx> oh I was more talking about setting the value of the actuator
+21:39 < sam_moore> Right
+21:40 < sam_moore> We should probably check for 0 or 1 anyway
+21:40 < sam_moore> In case the user does something dumb
+21:40 < jtanx> well
+21:40 < sam_moore> Like think they are setting an analog sensor and put in like "200"
+21:40 < jtanx> it should be the js code that's setting it
+21:41 < jtanx> so if you write the code properly it shoul be ok
+21:41 < sam_moore> "should be OK"...
+21:41 < jtanx> you shouldn't access the api directly
+21:41 < sam_moore> Alright, we'll see, but it's like, 1/2 a line of code to check :P
+21:41 < sam_moore> Redundancy and all that
+21:41 < jtanx> but even if they entered 200
+21:41 < jtanx> well so what
+21:41 < sam_moore> Yeah, but people *can* access the API directly
+21:41 < jtanx> it'd just represet 1
+21:42 < jtanx> represent
+21:42 < jtanx> *
+21:42 < sam_moore> How does the server know the difference between someone typing the URL and an AJAX request to the URL?
+21:42 < jtanx> yeah
+21:42 < sam_moore> Someone could go view source, "How can I break this... ah, what happens if I pass stupid values directly to the API"
+21:42 < jtanx> well if you define that 0 is off and not zero is on
+21:43 < jtanx> then it meets specs :P
+21:43 < sam_moore> Ok, I suppose it doesn't really matter
+21:44 < sam_moore> I respectfully disagree with the idea of having too many checks :P
+21:44 < sam_moore> Unless we went "while (true) DoCheck();" or something like that
+21:44 < sam_moore> That would be dumb
+21:44 < jtanx> hahaha
+21:45 < jtanx> but sometimes it gets really messy to maintain when you have that many checks
+21:45 < jtanx> and then when you want to modify something it's a real pain
+21:45 < jtanx> and really easy to break
+21:45 < sam_moore> True, but a bounds check isn't that bad
+21:46 < jtanx> yrue
+21:46 < sam_moore> I mean, you have to convert the value that isn't zero to an "on" anyway, which requires a check
+21:46 < jtanx> not really
+21:46 < sam_moore> Depends on the actuator
+21:46 < jtanx> you check if !value
+21:47 < sam_moore> Alright
+21:58 < jtanx> do you think there should be a stop/start method?
+21:58 < jtanx> eg start the experiment
+21:58 < jtanx> stop the experiment
+22:28 < sam_moore> Yes, probably
+22:28 < sam_moore> The stuff I wrote for Thread Exit conditions may actually help there...
+22:29 < sam_moore> Remove the bit where the FCGI loop exits though
+22:29 < jtanx> yeah
+23:09 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Mon Sep 02 2013
+08:33 < sam_moore> Hi
+08:33 < sam_moore> I managed to get a reasonable sensor plotting GUI done
+08:35 < sam_moore> So, adrian wanted: 1) A digital sensor simulation (done) 2) Sensors plotted in GUI (done) 3) A test actuator in the GUI 4) Camera images in the GUI (sort of done, kind of)
+08:35 < sam_moore> Was there anything else?
+08:38 < sam_moore> I have to go to Uni, I'll be in G19 otherwise I'll send an email
+08:38 < sam_moore> See you
+08:42 < jtanx> ok then
+09:02 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+09:55 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+13:15 < jtanx> hey
+13:18 < james__> hey
+13:18 < james__> I have the AJAX call working i am pretty sure
+13:19 < jtanx> ok
+13:19 < james__> Do you know if we have the beaglebones in yet?
+13:19 < jtanx> I don't know
+13:19 < jtanx> it should be ready soon though
+13:19 < jtanx> anyway, sam got a gui with graphs semi working
+13:20 < jtanx> could you update your git repository with what you've done?
+13:28 -!- james__ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+13:31 < jtanx> :(
+13:31 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+21:04 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Sep 03 2013
+21:35 -!- jtanx_ is now known as jtanx
+22:10 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Wed Sep 04 2013
+09:02 -!- jtanx_ is now known as jtanx
+09:03 -!- MctxBot_ is now known as MctxBot
+11:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+16:00 -!- jtanx_ is now known as jtanx
+20:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Thu Sep 05 2013
+09:34 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+18:51 < jtanx> hm, so to get clock_gettime to work, you need to use std=gnu99 instead of std=c99
+18:52 < jtanx> do you think we should just stick with gettimeofday?
+--- Day changed Fri Sep 06 2013
+12:05 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+16:05 < jtanx> I was just thinking, what sort of identification information is needed from the server?
+16:05 < jtanx> The gui should have some understanding of what sort of sensors/actuators it needs to display
+16:10 < jtanx> it might be enough to say this is API version x
+16:10 < jtanx> and at version x, it's agreed that these id values correspond to these sensors/actuators etc?
+16:19 < jtanx> anyway, what I've done for now is if asked, the api will list the sensor/actuator ids and the corresponding human readable string
+16:19 < jtanx> api/?sensors&actuators
+18:06 < jtanx> also, what do you think of keeping track of the number of points stored
+18:07 < jtanx> then you can allow the user to request from where they want to retrieve data from and how many to retrieve
+18:08 < jtanx> the only problem is that it wouldn't be time based, but based on the number of data points recorded
+18:08 < jtanx> this method is simpler because you now the offset to use with fseek
+18:08 < jtanx> if it's time based you have to search the data for the correct point
+19:51 < sam_moore> All the above makes good sense
+19:52 < sam_moore> If we can make a working "request X number of points" first instead of "request from time T onwards", we might be able to convert the latter to the former if necessary
+20:04 < jtanx> ok I just submitted a pull request for some stuff
+20:04 < jtanx> mostly the identification stuff and some reordering
+20:04 < jtanx> FCGI_RejectJSON now requires that you give a description explaining why
+20:05 < jtanx> when RejectJSOn is called, it's always logged along with the description, so some of the current log messages within the handler functions may be redundant
+21:11 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sat Sep 07 2013
+18:29 < jtanx> hmm
+18:29 < jtanx> what if you had two file pointers to the same file
+18:29 < jtanx> one read only, one write only
+18:29 < jtanx> then if you also kept track of how many points were written to the file
+18:29 < jtanx> you don't need to have mutexes anymore
+18:30 < jtanx> as long as you write the read/write calls carefully
+18:44 < jtanx> ahp, may have spoken too soon
+18:44 < jtanx> you'd still need a mutex around the read/write from/to the counter
+18:45 < jtanx> I think...
+19:07 < jtanx> but it might still be a good idea
+21:38 < jtanx> I went the simple route
+21:53 < jtanx> what I've got: /api/sensors?id=x&from=y&count=z
+21:54 < jtanx> In dump mode:
+21:54 < jtanx> If from < 0, then return from start, else from the given index (0-indexed)
+21:54 < jtanx> if count < 0, then return all points, else return /at most/ that many points
+21:55 < jtanx> in normal mode:
+21:55 < jtanx> if from < 0, then return from the end (return the most recent points)
+21:55 < jtanx> if count < 0, then return at most the default amount (SENSOR_QUERYBUFSIZ)
+21:56 < jtanx> otherwise return /at most/ that many points
+21:56 < jtanx> oh ya, if from >= 0 then return from that indicated index
+21:57 < jtanx> it's only in my git repository for now because I haven't tested it enough and I'm still not sure how I should go about integrating it with the current code
+21:58 < jtanx> (I basically rewrote Sensor_Handler and it has less error checks on the input; not sure if they're necessary or not)
+21:59 < jtanx> Since requesting a huge range could impact on sensor readings due to the mutex, it may be better to at least restrict dumps to when the experiment is not 'running'
+--- Day changed Sun Sep 08 2013
+18:06 < Callum_> what was the server stuff you said to install? also what packages do i need?
+18:09 -!- Callum_ is now known as Callum
+18:21 < jtanx> if you want to install the server, you need at least the 'nginx' and 'spawn-fcgi' packages
+18:21 < jtanx> one nginx is installed you need to copy the config files from the git repository in
+21:14 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+22:36 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+22:38 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Mon Sep 09 2013
+10:54 -!- jtanx_ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+11:30 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+15:55 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+21:01 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Sep 10 2013
+17:25 < jtanx> it looks like we do need an sd card, at least to install the os onto it
+17:26 < jtanx> http://beagleboard.org/Getting%20Started#update
+17:41 < jtanx> http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc/
+17:42 < sam_moore> Ok, we should write a BOM for next week then
+17:42 < sam_moore> 1x SD Card
+17:44 < jtanx> from what I understand
+17:45 < jtanx> you write an image to the sd card
+17:45 < jtanx> boot off the sd card
+17:45 < jtanx> then you can write another image directly too the internal storage
+17:45 < jtanx> after that you don't need the sd card any more
+17:46 < sam_moore> Alright
+17:46 < jtanx> http://www.armhf.com/index.php/boards/beaglebone-black/
+17:47 < jtanx> any preference for ubuntu or debian?
+17:48 < sam_moore> As a debian user, I'd have to say debian :P
+17:49 < jtanx> hehe
+17:49 < sam_moore> If it works on debian stable, we know it will work for at least the next 6 years
+17:49 < jtanx> yup
+17:49 < jtanx> debian should be fine
+17:53 < jtanx> *correction; we need a microsd card
+17:56 < jtanx> that's at least 2GB in size
+17:57 < sam_moore> Ok
+18:04 < jtanx> haha it's cheaper to buy a 4gb one than a 2gb one
+18:35 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+20:15 < jtanx> Well I can confirm that angstrom doesn't have nginx precompiled - http://www.angstrom-distribution.org/repo/
+20:57 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Wed Sep 11 2013
+15:58 < jtanx> urgh
+15:58 < jtanx> it took so long just getting internet access to the bbb
+16:01 < jtanx> dhcp/dns issues
+16:01 < jtanx> the debian image on the microsd is set to static ip 192.168.0.7
+16:02 < jtanx> /etc/resolv.conf should have the uwa nameservers in it, but it may have been rewritten by resolvconf
+16:02 < jtanx> I've left it in g19
+16:51 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+19:32 < jtanx> I've moved the 'current_time', 'start_time' and 'running_time' to the identify module instead of sticking it on every json response, because it's probably not information that will be required most of the time
+19:37 < jtanx> actually, we may have to rethink those, especially if we introduce start/stop control
+20:38 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Thu Sep 12 2013
+09:36 < sam_moore> I think I have some time after the tutorial today to work on stuff
+09:36 < sam_moore> I take it we have the bbb now?
+09:37 < sam_moore> I'll bring that crappy webcam
+09:37 < sam_moore> Maybe look into sending images as part of the API, see if it's feasable to do it that way
+09:38 < sam_moore> I think we can introduce start/stop control fairly easily
+09:40 < sam_moore> "Mush Mush"
+09:40 < sam_moore> Heh
+09:41 < sam_moore> To reduce the load on the client, we might be able to send averaged data points instead of every data point
+09:41 < sam_moore> You specify "averages per point"
+09:42 < sam_moore> So each [time, value] pair is actually an average of X recordings
+09:42 < sam_moore> In fact it's better to send [mean_time, mean_value, std_dev]
+09:42 < sam_moore> The std_dev gives you an idea of noise and/or if the value is changing a lot
+09:43 < sam_moore> And of course you can always specify a single average and it becomes equivelant to what we currently do
+09:50 < jtanx> yeah
+09:50 < jtanx> I'm free after the tute
+09:50 < jtanx> I'm bringing in a router to make it easier
+09:50 < jtanx> to work on the bbb together
+09:51 < jtanx> yesterday it was so painful trying to get shit working
+09:51 < jtanx> dhcp issues, dns issues, internet connection sharing issues...
+09:51 < jtanx> (mostly the fault of my own computer though)
+09:51 < jtanx> btw I'm working on adding an extra function to FCGI to makeit easier to parse parameters
+09:51 < jtanx> (hoepfully)
+09:55 < jtanx> gtg see you at the tute
+09:55 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+18:26 < Callum> would be easier to talk here...if everyone was on
+18:41 < jtanx> did you bring the bbb home?
+18:43 < sam_moore> Yep
+18:44 < sam_moore> I'll put it back tomorrow morning
+18:49 < jtanx> ok
+19:47 < jtanx> I'm so tempted to use bitflags for that request function
+19:52 < jtanx> one thing that I need to do is to sanitise json string fields
+20:18 < sam_moore> Sanitise? As in "make sane" or "make clean"?
+20:18 < sam_moore> Um... if you think bitflags are necessary, I fully support you :P
+20:19 < jtanx> as in
+20:19 < jtanx> If I allow FCGI_JSONPair to also be passed a format string
+20:19 < jtanx> then having stuff like \ or " or newline characters for eg in the string
+20:20 < jtanx> is not a good idea
+20:20 < sam_moore> Hmm
+20:20 < jtanx> it's sorta like this:
+20:20 < sam_moore> Well, writing the function to print out data (either as TSV or JSON)
+20:20 < sam_moore> I've only been using FCGI_PrintRaw
+20:20 < jtanx> yeah
+20:20 < jtanx> but right now, you're logging messages in Server_handler
+20:20 < jtanx> about invalid values
+20:21 < sam_moore> Yes, I'm not sure how to deal with that
+20:21 < jtanx> Sensor_handler*
+20:21 < jtanx> so
+20:21 < jtanx> eg Log(LOGERR, "Require \"all\" or an integer value: %s = %s", key, value);
+20:21 < sam_moore> Yes
+20:21 < jtanx> if I wanted to send that back to the client in FCGI_RejectJSON
+20:21 < jtanx> there's the potential (...) that the user could hvae included a " in the value
+20:22 < jtanx> so if you return it as part of your json response, then suddenly it's broken
+20:22 < sam_moore> Oh, that sucks
+20:23 < sam_moore> Perhaps treat Log messages seperately from JSON responses?
+20:23 < jtanx> eg: "description":" required an id, got 'blah-stray"'"
+20:23 < jtanx> yeah
+20:24 < jtanx> What I could do is just replace any special characters with space
+20:24 < jtanx> and return that in description
+20:24 < jtanx> but keep the actual value in log
+20:24 < sam_moore> Maybe
+20:24 < sam_moore> You could also call FCGI_RejectJSON as soon as you get a special character
+20:25 < sam_moore> Since we shouldn't have any key/values that use them
+20:25 < sam_moore> (I think :P)
+20:25 < jtanx> lol
+20:25 < sam_moore> Whatever seems best
+20:25 < jtanx> let me think about it some more
+20:25 < sam_moore> Yeah, fair enough
+20:25 < sam_moore> Um, another thing (sorry) is error messages that you might get independent of any request
+20:26 < sam_moore> Like you suddenly have an I/O error on a file
+20:26 < sam_moore> Currently we handle that with Fatal
+20:26 < sam_moore> Which it would be convenient to keep; but instead of terminating the whole program, we need to notify the client somehow
+20:26 < jtanx> that won't happen until the next request
+20:27 < jtanx> what you could do is keep it exiting
+20:27 < jtanx> when that happens, nginx sends 502 bad gateway
+20:27 < jtanx> then if that's detected, send a link to the log file
+20:27 < sam_moore> Yeah, that seems good
+20:27 < jtanx> and a method to restart the software
+20:28 < sam_moore> Do we want to notify the client of non-fatal errors or warnings though?
+20:28 < sam_moore> Hmm
+20:29 < jtanx> hmm
+20:29 < jtanx> probably a good idea
+20:29 < jtanx> but how
+20:29 < sam_moore> The client could periodically request the log file and deal with messages?
+20:30 < jtanx> It could just display it I guess
+20:30 < jtanx> onus on the user to take action if required
+20:30 < sam_moore> Sure, an alert might be nice though
+20:30 < sam_moore> Perhaps have an extra log file that just has the most recent message in it (with a timestamp)
+20:31 < jtanx> you could perform a regex on the text and highlight lines with warning or something
+20:31 < sam_moore> The client just periodically looks at that and if it's a new message can alert
+20:31 < sam_moore> Yeah that would work, as long as the file doesn't get too big
+20:31 < sam_moore> It probably won't
+20:31 < jtanx> well you could autoscroll it anyway
+20:32 < jtanx> but ok maybe that's getting a bit ahead of ourselves
+20:32 < sam_moore> Yeah, sure
+20:32 < sam_moore> I'll get back to rewriting 90% of the sensor code :P
+20:32 < jtanx> haha
+20:32 < jtanx> currently, I've got
+20:32 < jtanx> bool FCGI_ParseRequest(FCGIContext *context, char *params, FCGIValue values[], size_t count);
+20:32 < jtanx> (any better suggestion for FCGIValue?)
+20:32 < jtanx> (the name that is)
+20:33 < jtanx> with
+20:33 < sam_moore> That's probably fine
+20:33 < jtanx> typedef struct FCGIValue {
+20:33 < jtanx> const char *key;
+20:33 < jtanx> void *value;
+20:33 < jtanx> unsigned flags;
+20:33 < jtanx> } FCGIValue;
+20:33 < jtanx> you then do
+20:33 < jtanx> something like:
+20:33 < jtanx> FCGIValue values[2] = {{"sensors", &ident_sensors, FCGI_REQUIRED(FCGI_BOOL_T)},
+20:33 < jtanx> {"actuators", &ident_actuators, FCGI_BOOL_T}};
+20:33 < sam_moore> Looks good
+20:33 < jtanx> although I'm open to suggestions on those type names too
+20:34 < jtanx> if you really have to
+20:34 < jtanx> you can do something like FCGI_RECEIVED(values[0].flags)
+20:34 < jtanx> to check if you received the argument or not
+20:34 < sam_moore> If it's not too hard to implement, then OK
+20:35 < jtanx> ?
+20:35 < sam_moore> That looks reasonably nice
+20:35 < jtanx> the #defines look less so:
+20:35 < jtanx> #define FCGI_PARAM_REQUIRED (1 << 0)
+20:35 < jtanx> #define FCGI_PARAM_RECEIVED (1 << 1)
+20:35 < jtanx> #define FCGI_BOOL_T (1 << 2)
+20:35 < jtanx> #define FCGI_LONG_T (1 << 3)
+20:35 < jtanx> #define FCGI_DOUBLE_T (1 << 4)
+20:35 < jtanx> #define FCGI_STRING_T (1 << 5)
+20:35 < jtanx> #define FCGI_REQUIRED(x) ((x) | FCGI_PARAM_REQUIRED)
+20:35 < jtanx> #define FCGI_IS_REQUIRED(x) ((x) & FCGI_PARAM_REQUIRED)
+20:35 < jtanx> #define FCGI_RECEIVED(x) ((x) & FCGI_PARAM_RECEIVED)
+20:35 < jtanx> #define FCGI_TYPE(x) ((x) & ~(FCGI_PARAM_REQUIRED | FCGI_PARAM_RECEIVED))
+20:35 < sam_moore> In fact it's similar to how you use select(2)
+20:35 < sam_moore> Wow, macros
+20:35 < jtanx> :P
+20:35 < jtanx> makes life easier
+20:36 < sam_moore> Alright, this is C
+20:36 < sam_moore> Yeah, FCGI_RECEIVED(values[i].flags) looks nice (from the point of view of actually using it anyway)
+20:37 < jtanx> yeah it's ok
+20:37 < jtanx> the only stickler is that hardcoded index
+20:37 < jtanx> can't really do much about that though
+20:37 < sam_moore> I can put an enum in the function
+20:38 < jtanx> if you want; it might be more work to maintain the enum than anything though
+20:39 < jtanx> but yeah, essentially if you require a parameter, you surround the type in FCGI_REQUIRED()
+20:39 < jtanx> hopefully that part was clear
+20:39 < sam_moore> Yep, I'm happy with that
+20:39 < jtanx> cool
+20:43 < jtanx> for the bool value, what behaviour do you think is better
+20:43 < jtanx> always set the value to true, or invert the current value
+20:44 < jtanx> right now it's set to always be true
+21:06 < sam_moore> Um... always set to true?
+21:09 < jtanx> yeah
+21:29 < jtanx> oh
+21:30 < jtanx> well I didn't need to escape after all
+21:30 < jtanx> If you do something like this: http://mctx.us.to:8080/api?afa%22%22%22%22
+21:30 < jtanx> it gets url encoded
+21:30 < jtanx> http://mctx.us.to:8080/api?afa""""
+21:30 < jtanx> I wonder if that's guaranteed
+21:32 < jtanx> well, apparently it's not because IE doesn't escape it for you
+21:32 < jtanx> so I did need to escape
+21:33 < sam_moore> There's no escape
+21:46 < jtanx> wait wat
+21:59 < sam_moore> (It's a pun)
+22:00 < sam_moore> So I've made a DataFile structure to isolate it a bit more from the higher level Sensor related stuff
+22:00 < sam_moore> Hopefully things make more sense
+22:00 < sam_moore> I put in 2 seperate FILE* as well
+22:00 < sam_moore> And got rid of the confusing "fill a buffer then dump the buffer to a file" loop
+22:01 < sam_moore> Now it just writes each point to a file
+22:01 < sam_moore> Hopefully it's thread safe enough
+22:01 < sam_moore> Now... I just need to simplify the Sensor_Handler function...
+22:02 < jtanx> > (It's a pun)
+22:02 * jtanx facepalm
+22:03 < jtanx> hoho
+22:03 < jtanx> ok
+22:03 < jtanx> I'll submit what I've done so far to git
+22:08 < jtanx> callum
+22:08 < jtanx> that code you submitted
+22:08 < jtanx> I don't think it's right
+22:08 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
+22:09 < jtanx> the stuff with g_sensor_names, that's the human readable name of each sensor
+22:10 < sam_moore> I've changed the name and how the sanity check gets called, but I've left the body unimplemented for now
+22:12 < jtanx> it's with the pull request he submitted ~30mins ago
+22:12 < sam_moore> Oh, ok
+22:13 < sam_moore> Good thing I made a new branch for my changes
+22:14 < jtanx> the pull request isn't merged yet
+22:15 < sam_moore> Yeah, I don't think we should merge that, sorry Callum
+22:17 < jtanx> ok just submitted the pull request
+22:17 < sam_moore> I never put documentation on g_sensor_names I guess, sorry
+22:17 < jtanx> I think I did though
+22:17 < jtanx> but in the header file
+22:18 < jtanx> which is annoying :/
+22:18 < jtanx> (as in there's more than one spot to put documentation)
+22:19 < sam_moore> Yeah... does one overwrite another?
+22:19 < sam_moore> I'll just copy paste the same thing into the .c file
+22:19 < jtanx> No idea how doxygen handles that
+22:20 < sam_moore> I wonder how much fun I'll have merging these branches...
+22:20 < jtanx> hehe
+22:20 < jtanx> I'm not really sure if FCGI_ParseRequest will be that helpful or not
+22:20 < jtanx> if you find it doesn't really help then we can scrap it
+22:21 < sam_moore> Well it makes sense to seperate the code for getting key,value pairs from the code that does stuff with them
+22:23 < jtanx> I guess
+22:23 < sam_moore> I've basically moved a lot of functionality from sensor.c into a new file data.c under functions with the prefix "Data_"
+22:24 < jtanx> ok
+22:24 < sam_moore> data.c doesn't care anything about what the data is or where it came from, it just wraps around saving/reading/selecting ranges of DataPoints
+22:25 < jtanx> sounds like a good idea
+22:25 < jtanx> it might be of use in actuator code I guess
+22:25 < sam_moore> Yeah, there's a DataFile structure that basically wraps around the binary file
+22:25 < sam_moore> Yes, I was thinking that too
+22:25 < sam_moore> Because we'll probably want to store DataPoints when an actuator gets changed
+22:26 < jtanx> yeah true
+22:27 < sam_moore> If the idea about using 2 FILE* is right... I don't think we really need any mutexes?
+22:28 < sam_moore> There is an index that gets incremented, but since only one thread can write to it, the worst that can happen is you return one (maybe two at the extreme) less point than actually exists
+22:29 < sam_moore> If you had 2 threads incrementing the index you'd need a mutex though
+22:29 < jtanx> the problem is that setting a value is not guaranteed to be atomic
+22:29 < jtanx> i think
+22:29 < sam_moore> Yes, sure
+22:29 < jtanx> so while setting and you read it it could be indeterminate
+22:29 < sam_moore> Mmm
+22:30 < jtanx> I think you need mutexes around reading/writing the points_written(?)
+22:30 < jtanx> index
+22:30 < jtanx> but that's it
+22:31 < jtanx> http://stackoverflow.com/questions/54188/are-c-reads-and-writes-of-an-int-atomic
+22:31 < sam_moore> I'm not sure you do if you are writing in one thread and reading in another
+22:31 < sam_moore> Ah, stackoverflow, OK
+22:32 < jtanx> it's actually very architecture specific
+22:32 < sam_moore> Yeah "Yes, no, hmmm, well it depends" is probably right
+22:32 < jtanx> haha
+22:32 < sam_moore> Well... there are no mutexes at the moment, but maybe I should get around to putting them in
+22:32 < sam_moore> I think I had one thread writing and another reading in my parallel programming assignment and got full marks :S
+22:33 < sam_moore> Threads are strange and magical
+22:33 < jtanx> hey well it probably works 99% of the time
+22:34 < sam_moore> Ah, it probably works if the size of the integer is smaller than the bus
+22:34 < sam_moore> smaller or equal
+22:34 < jtanx> too bad linux doesn't have something like InterlockedExchange
+22:35 < sam_moore> I'll add mutexes in later then
+22:35 < jtanx> One thing I liked about C++ was auto locks
+22:36 < jtanx> (you could call some lock function and once that scope ended the lock ended too)
+22:36 < sam_moore> That's nice
+22:40 < jtanx> Ok, that's all I'm probably going to get done today
+22:41 < sam_moore> Yeah, thanks
+22:42 < jtanx> what's with the meeting tomorrow though
+22:43 < sam_moore> I'm busy from 2:00pm until at least 4:00pm (maybe later)
+22:43 < sam_moore> But I think I should be preparing for something before 2:00pm
+22:44 < jtanx> ok, I'll probably come in around 1.30pm so I can work with Callum, and I'll stay on until whatever time
+22:44 < sam_moore> Alright
+22:45 < sam_moore> Check github in the morning, I'll push all my changes
+22:45 < jtanx> ok I'll do that
+22:45 < sam_moore> Hopefully they make sense, otherwise you can change everything back :P
+22:45 < sam_moore> The wonders of git
+22:45 < jtanx> haha I'm sure it'll make sense
+22:46 < jtanx> after staring for a while
+22:46 < sam_moore> Yeah it should be a bit simpler
+22:46 < jtanx> thanks
+22:47 < jtanx> see you tomorrow (probably)
+22:48 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:28 -!- Callum_ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Fri Sep 13 2013
+08:31 < jtanx> oh yeah, I forgot to restart the bot :P
+08:53 < sam_moore> So, using 2 FILE* causes some problems, I recommend we just use 1
+08:54 < sam_moore> In theory the operating system is supposed to use locks when multiple processes have access to the same file
+08:54 < sam_moore> But...
+08:54 < sam_moore> It probably doesn't work with threads
+08:55 < sam_moore> I'm not sure exactly what goes wrong, but using 1 works and isn't really going to be slower (if the OS uses locks then that probably has a similar overhead to using a mutex)
+08:59 < jtanx> yeah, let's stick to one then
+09:00 < jtanx> there's still a few bugs around I think
+09:00 < sam_moore> Probably
+09:01 < sam_moore> I put valgrind back in, I got rid of a lot last night
+09:01 < jtanx> nice
+09:01 < sam_moore> Although I probably introduced them in the first place
+09:01 < jtanx> what was with that mem leak in fastcgi code?
+09:03 < sam_moore> Oh, that wasn't a memory leak, it was an uninitialised value
+09:04 < sam_moore> I thought I'd be clever and use sizeof() on the FCGIValue array
+09:04 < sam_moore> But I forgot that the actual number of elements is not just sizeof()
+09:04 < sam_moore> It's sizeof(array) / sizeof(element)
+09:04 < jtanx> oh right haha
+09:05 < sam_moore> So the refactored code basically does the same thing
+09:05 < sam_moore> But hopefully it's a bit cleaner
+09:05 < jtanx> yep
+09:05 < jtanx> it's pretty good
+09:06 < jtanx> when you get an invalid id or format, do you want to reject that?
+09:07 < sam_moore> Yeah, I wasn't sure what I should do there, but I think Sensor_Handler is the only place you can really deal with that
+09:07 < jtanx> yeah
+09:07 < sam_moore> I did have it calling FCGI_RejectJSON if the sensor id was invalid
+09:08 < jtanx> the current code on git just calls Log
+09:08 < sam_moore> But I must have done something wrong, because the normal JSON was getting printed just after that
+09:08 < sam_moore> So I removed it
+09:08 < jtanx> oh yeah
+09:08 < jtanx> you have to return after FCGI_RejectJSON
+09:08 < sam_moore> Ah
+09:08 < sam_moore> Durr
+09:08 < jtanx> :P
+09:09 < jtanx> anyways I'll look through and see if I can fix stuff up
+09:09 < jtanx> then I'll try and do that start/stop stuf
+09:10 < sam_moore> Ok
+09:10 < sam_moore> I put in Sensor_Start and Sensor_Stop which might help
+09:10 < sam_moore> I thought you might want to pause data collection without actually "stopping" the experiment?
+09:11 < jtanx> ok
+09:11 < jtanx> that might be a good idea
+09:11 < sam_moore> And also it should be fairly easy to implement a Sensor_Load if we want to be able to load previous experiments
+09:11 < jtanx> yeah
+09:38 < jtanx> those issues with fread
+09:38 < jtanx> it could be because you didn't specify the 'b' flag in fopen
+09:38 < jtanx> ?
+09:39 < jtanx> // Clear the FILE*s
+09:39 < jtanx> df->read_file = NULL;
+09:39 < jtanx> df->write_file = NULL;
+09:39 < jtanx> fclose(df->write_file);
+09:52 < sam_moore> Oh... hurdur
+09:52 < sam_moore> Wait how is it working at all
+09:52 < sam_moore> The write file is mode "w+" which should make it plain text
+09:53 < jtanx> so it's no longer a binary file?
+09:53 < jtanx> I think i may not be experiencing the same issues as you just because I'm running everything on single core processors
+09:53 < sam_moore> Well... it certainly looks like a binary file when you try and cat it
+09:53 < jtanx> ok
+09:53 < jtanx> it's probably a good idea to stick to one file pointer and use mutexes
+09:53 < sam_moore> Yeah
+09:53 < sam_moore> But also make sure that file is binary
+09:53 < jtanx> yeah
+09:54 < sam_moore> It's probably compiler specific what happens when you use fwrite and fread on a plain text file
+09:54 < jtanx> probably
+09:54 < sam_moore> But it looks like a binary file to me, so I'm not sure that's related to the problems with fread
+09:54 < sam_moore> I can investigate this by changing like 4 characters...
+09:55 < jtanx> one thing I did notice on linux
+09:55 < jtanx> if it wasn't a binary file you'd have to use fflush to explicitly write out text and have it appear when you used cat
+09:56 < jtanx> but overall I think it's not due to it being a binary file or not
+09:56 < sam_moore> Yep
+09:56 < sam_moore> I just put the second FILE* for read_file back in
+09:56 < sam_moore> Made them both binary
+09:56 < sam_moore> Still get the "Transport endpoint is not connected" errors
+09:57 < sam_moore> So there should be a "b" in the file mode, but that's unrelated to having multiple FILE*
+09:57 < jtanx> yep then I think that's due to you running it on a multicore processor
+09:57 < jtanx> maybe
+09:57 < sam_moore> I think the OS locks around file access are based on PID
+09:58 < jtanx> on linux all file locks are advisory only
+09:58 < sam_moore> Can
+09:58 < sam_moore> Anyway, it's clearly safest to just have one FILE*
+09:58 < jtanx> yeah
+09:58 < jtanx> I'm changing it now
+10:09 < jtanx> oh ffs that's the second time it's crashed simply because I didn't do make clean before make
+10:16 < sam_moore> haha
+10:17 < sam_moore> Modify the make file to always run make clean?
+10:28 < jtanx> haha that's one option
+10:28 < jtanx> it's because make doesn't consider changes to the header files
+10:28 < jtanx> there's a way to make it detect those, but *effort*
+10:40 < sam_moore> Regarding Actuators, I think if we design for a thread to control (one or more) actuators that will make it easy to add more advanced control later
+10:42 < sam_moore> eg: The Actuator_Handler just sets some kind of formula or says "Every time sensor 0 is stable for Xs (within a range) change actuator by Y" and the thread watches the sensor data and changes the actuator when necessary
+10:43 < sam_moore> You could also add feedback that way too
+10:44 < sam_moore> "Set this actuator so that sensor 0 has value X"
+10:46 < jtanx> hmm
+10:47 < jtanx> about the sensor stuff
+10:47 < jtanx> there were a few things I noticed
+10:48 < jtanx> the time wrapping
+10:48 < jtanx> could still give a negative start_time or end_time
+10:48 < jtanx> if the user specified a very negative start_time/end_time
+10:49 < jtanx> (eg specifies a negative time greater than the total running time)
+10:49 < sam_moore> Oh yeah
+10:49 < jtanx> so in data_printbytimes
+10:49 < jtanx> I just clamped it to zero
+10:49 < jtanx> instead of asserting
+10:49 < sam_moore> Fair enough
+10:49 < jtanx> strangely this code seems to work pretty good:
+10:49 < jtanx> void Data_PrintByTimes(DataFile * df, double start_time, double end_time, DataFormat format)
+10:49 < jtanx> {
+10:49 < jtanx> assert(df != NULL);
+10:49 < jtanx> //Clamp boundaries
+10:49 < jtanx> if (start_time < 0)
+10:49 < jtanx> start_time = 0;
+10:50 < jtanx> if (end_time < 0)
+10:50 < jtanx> end_time = 0;
+10:50 < jtanx> int start_index = 0, end_index = 0;
+10:50 < jtanx> if (start_time < end_time)
+10:50 < jtanx> {
+10:50 < jtanx> start_index = Data_FindByTime(df, start_time, NULL);
+10:50 < jtanx> end_index = Data_FindByTime(df, end_time, NULL);
+10:50 < jtanx> }
+10:50 < jtanx> Data_PrintByIndexes(df, start_index, end_index, format);
+10:50 < jtanx> }
+10:50 < jtanx> oh but that was the other ting
+10:50 < jtanx> it works better if you have exclusive end index/time
+10:50 < sam_moore> Ok
+10:50 < sam_moore> I have to go now
+10:50 < jtanx> ok
+10:50 < sam_moore> See you this afternoon if you're still there
+10:50 < jtanx> yep see you then
+10:51 < jtanx> probably
+13:44 < callum> should i just add the sensor threshold values to the sensor struct?
+13:47 < jtanx> probably not
+13:47 < jtanx> I think you have to create a new struct
+13:48 < jtanx> are you at uni?
+13:49 < callum> yea. why is a new struct necessary?
+13:49 < jtanx> come to g19
+13:49 < jtanx> the bbb is setup too
+16:17 < sam_moore> Are you guys still in G19?
+16:17 < sam_moore> On my way now
+18:42 < jtanx> lol you need to use a transistor to turn on an led from the gpio pins
+19:56 < jtanx> ok I think I'll just escape all input parameters from within the request loop
+19:56 < jtanx> then at least you're guaranteed that user input won't stuff up anything
+19:56 < jtanx> (as in making it generate invalid JSON)
+20:53 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sat Sep 14 2013
+11:32 < sam_moore> blergh, too many different versions of OpenCV
+11:32 < sam_moore> Also too many different data types
+11:33 < sam_moore> "Getting a digital image into numbers can be very handy for your image processing. In this post i will brief just that."
+11:34 < sam_moore> Thank god, finally a tutorial that makes sense
+11:34 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+11:34 < sam_moore> ... no one else is in the channel
+11:34 < sam_moore> :S
+12:36 < jtanx> on start/stop/pausing an experiment
+12:36 < jtanx> currently everything is relative to g_options.start_time
+12:42 < sam_moore> Yeah
+12:43 < sam_moore> Perhaps make an ExperimentTime function and that leaves us free to change what the time stamps are relative to?
+12:43 < sam_moore> Looking into this interferometer stuff...
+12:43 < jtanx> ok, maybe as part of the Control_ module then
+12:43 < sam_moore> Interesting problem, I think I've worked out an algorithm that isn't too terrible
+12:44 < jtanx> yeah?
+12:44 < jtanx> how does it work
+12:45 < sam_moore> If you have a sinusoidal wave, find the x intercepts, and that lets you calculate the phase and frequency
+12:45 < sam_moore> That's the simple version
+12:46 < jtanx> haha alright
+12:46 < sam_moore> I have 3 pages of notes that I can show Adrian/Adam if I can't get it working
+12:46 < jtanx> wow
+12:46 < jtanx> nice work
+12:47 < sam_moore> Fortran would be good for the array operations
+12:47 < sam_moore> If fortran were able to do anything *other* than array operations it would be a nice language...
+12:47 < jtanx> have you ever used Fortan before?
+12:48 < sam_moore> Yes
+12:48 < sam_moore> I'm going to keep it in C though
+12:48 < sam_moore> It took long enough to get OpenCV working
+12:48 < sam_moore> I'm sure there's some kind of convoluted Fortran library
+12:49 < sam_moore> But a seperate fortran program won't talk to our server
+12:49 < jtanx> can you compile the code as a library with C interop
+12:49 < sam_moore> Erm..
+12:49 < sam_moore> Probably more effort than just doing it in C
+12:49 < jtanx> probably
+12:51 < jtanx> I think a separate mutex is needed around the *_Stop() functions
+12:51 < jtanx> because if a client sends in a request
+12:51 < sam_moore> Oh, good point
+12:52 < jtanx> although that's only going to be a problem if our own software calls the stop function because of the sanity checks
+12:52 < sam_moore> If there are 2 requests?
+12:52 < sam_moore> No wait, the FCGI stuff is serial
+12:52 < jtanx> the request loop is single threaded
+12:52 < sam_moore> It has to finish processing one request to respond to the next
+12:52 < sam_moore> That's fine
+12:56 < sam_moore> Put a mutex in the Sensor struct, use the same one that's already in the Actuator struct, put critical sections around setting the "s->record_data" or "a->activated" variables (or whatever you choose to use as a "is thing running" flag)
+12:56 < sam_moore> And check the flag hasn't already been set before doing anything
+12:57 < sam_moore> Similar to how the Thread_Running() and Thread_QuitProgram() functions used to work
+12:57 < sam_moore> .... Before I deleted them
+12:57 < sam_moore> Any thread could call Thread_QuitProgram, and repeated calls would have no effect
+13:01 < jtanx> ok I'll try that
+13:51 < jtanx> actually, what about this:
+13:51 < jtanx> in control.c, it maintains its own mutex
+13:51 < jtanx> so
+13:52 < jtanx> and it's the only place where Sensor_Start/Stop Actuator_Start/Stop is called
+13:53 < jtanx> You then have Control_Lock/Unlock that's placed around the responses in the handler functions
+13:53 < jtanx> those functions internally lock/unlock the mutex held in control.c
+13:53 < jtanx> ah stuff it
+13:53 < jtanx> I'll commit it to my git repo
+13:54 < jtanx> I still don't know how the pause functionality should be done though
+13:54 < jtanx> especially with the time discontinuities
+14:01 < jtanx> oh yeah, just a reminder that you have to be careful using FCGI_LONG_T vs FCGI_INT_T
+14:02 < jtanx> if your variable is of type int but you give FCGI_LONG_T, and where sizeof(int) != sizeof(long) then there could be a buffer overflow
+14:13 < sam_moore> Right
+14:14 < sam_moore> If you want to commit to the main repo you can use a new branch
+14:14 < sam_moore> Having a single mutex in control.c instead of one per sensor/actuator is probably better
+14:15 < sam_moore> With the pause functionality... I think if you just don't call Data_Close() (and don't call Data_Open on resuming) but otherwise stop the threads running Sensor_Loop in the same way
+14:15 < sam_moore> That should do most of it
+14:16 < sam_moore> Don't reset the experiment start time
+14:17 < sam_moore> Perhaps the experiment start time needs to be stored somewhere though
+14:18 < sam_moore> Anyway, I'll let you solve the problem :P
+14:48 < jtanx> ._.
+15:45 < jtanx> well I think I got something semi-working
+15:45 < jtanx> it involved adding on Sensor_PauseAll/ResumeAll + Acuator_PauseAll/ResmueAll (plus the individual Pause/Resume) functions
+15:46 < sam_moore> Cool
+15:46 < sam_moore> I think I'm starting to get my head around OpenCV
+15:46 < sam_moore> The documentation for it is a bit crap
+15:46 < jtanx> oh don't get me started on opencv documentation
+15:47 < jtanx> yesterday it took me and callum around 30 mins to figure out that CvMat structure
+15:47 < sam_moore> Haha
+15:47 < sam_moore> It probably took me a bit longer :S
+15:47 < jtanx> the problem is that most of it's geared towards c++ usage
+15:49 < jtanx> back on that control stuff, basically those Sensor/Actuator_[Start|Stop|Pause|Resume] functions can only be called via the Control_[Start|Stop|Pause|Resume] functions
+15:50 < jtanx> partly because of threading issues but also because it's the only place where the current state is currently kept track of
+15:51 < jtanx> (e.g if you call Sensor_Start twice then...
+15:53 < sam_moore> Seems sensible
+15:53 < jtanx> anyway, I'm taking a break from this stuff for a while
+15:53 < sam_moore> Yeah, fair enough
+15:54 < jtanx> If you want to see what I've done so far, it's on my git repo (haven't added comments yet)
+15:54 < sam_moore> Cool
+16:50 < sam_moore> The IplImage vs CvMat conversion is dumb
+16:50 < sam_moore> In fact I don't think you even need to do it?
+16:51 < sam_moore> Well at least to display an image you can just pass a CvMat
+16:51 < sam_moore> Maybe you still need the IplImage to capture from a camera
+16:51 < sam_moore> I worked out how to convert from IplImage to CvMat anyway
+16:53 < sam_moore> Other than that, OpenCV doesn't actually seem horrible to use
+16:53 < sam_moore> Just... contradictory documentation
+16:55 < sam_moore> Anyway... I've created a moving sinusoidal image!
+16:56 < sam_moore> Now to work out why the algorithm keeps returning -nan :S
+16:56 < sam_moore> Also for some reason the image is blue instead of red
+16:56 < sam_moore> But whatever
+16:57 < jtanx> :S
+16:57 < jtanx> BGR vs RGB?
+17:02 < sam_moore> Looks like it
+17:03 < sam_moore> Doing this with an actual camera is going to suck
+17:04 < sam_moore> See, I've worked out an algorithm to cope with changing background light conditions
+17:04 < sam_moore> Because differentiating a sinusoid gives you another sinusoid with the same phase (offset by pi/2)
+17:05 < sam_moore> Buut... differentiating with finite differences adds more noise
+17:05 < sam_moore> Or rather it makes the noise more pronounced
+17:07 < sam_moore> Hopefully sensors is considering this
+17:07 < sam_moore> If they want to shoot a laser into a camera, they should really do it in a way that keeps out background light
+17:07 < sam_moore> Buuut
+17:07 < sam_moore> I think they mentioned using one camera to do both the interferometer and look at the can
+17:07 < sam_moore> :S
+17:08 < sam_moore> Oh well, the optics is their problem
+17:09 < sam_moore> I suppose I will prepare a report or something about the algorithm and what conditions the image needs to satisfy
+17:12 < jtanx> um
+17:12 < jtanx> there's going to be two cameras
+17:12 < jtanx> because it was too much hassle moving it
+17:12 < sam_moore> Yes... but one was meant to be looking at each can?
+17:13 < jtanx> oh
+17:13 < jtanx> hmm
+17:13 < sam_moore> We should ask them
+17:13 < jtanx> I just thought that one would be for the interferometer (no need to look at can) and the other would be for the can to be blown up
+17:13 < sam_moore> Probably
+17:15 < jtanx> but I was thinking for the one to be blown up
+17:16 < jtanx> you could possibly just stream it using something like ffserver
+17:16 < jtanx> instead of passing it through opencv
+17:16 < sam_moore> Yeah, that seems like it's probably easier
+17:23 -!- jtanx [
[email protected]] has quit ["my antivirus is pestering me to restart"]
+18:19 < sam_moore> So... when you take an image with a camera the pixels are stored as rgb with 0->255 values
+18:20 < sam_moore> You can convert the IplImage to a CvMat and it keeps the values ordered as rgb with 0->255 values
+18:20 < sam_moore> And then...
+18:20 < sam_moore> If you try and display it...
+18:20 < sam_moore> The display function treats it as having values in bgr order with 0->1 values
+18:20 < sam_moore> -_-
+18:21 < sam_moore> (So unless you manually adjust all the values you'll just get a white picture in the display)
+18:54 < jtanx> hahaha
+18:54 < jtanx> what
+18:56 < jtanx> for cvShowImage:
+18:56 < jtanx> If the image is 8-bit unsigned, it is displayed as is.
+18:56 < jtanx> If the image is 16-bit unsigned or 32-bit integer, the pixels are divided by 256. That is, the value range [0,255*256] is mapped to [0,255].
+18:56 < jtanx> If the image is 32-bit floating-point, the pixel values are multiplied by 255. That is, the value range [0,1] is mapped to [0,255].
+18:57 < jtanx> so it's treating it as 32-bit floating point?
+20:41 < sam_moore> I think it's because of how I converted the IplImage to a CvMat
+20:42 < sam_moore> My algorithm is almost working
+20:43 < sam_moore> The fact that angles wrap around every 2*pi is giving me a headache though
+20:43 < sam_moore> This is pretty fun
+20:45 < sam_moore> Hopefully I can do Computer Vision as an optional, I think its in the list
+20:45 < sam_moore> Maybe I shouldn't make all my optionals CS units, but meh
+21:20 < jtanx> :P
+21:20 < jtanx> the computer vision unit sounds interesting, but a lot of maths/theory involved
+22:02 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sun Sep 15 2013
+11:02 < sam_moore> I'm really glad I put the IRC logs under git
+11:02 < sam_moore> It's very helpful for keeping my diary up to date
+11:40 < jtanx> hehe
+11:40 < jtanx> I'm gladful for git
+11:48 < jtanx> about the bbb
+11:48 < jtanx> it's probably best to just install debian to the internal memory
+11:54 < jtanx> on the controls
+11:54 < jtanx> maybe we can have the following states: start/pause/resume/stop/close
+11:56 < jtanx> actually, maybe just start/pause/resume/close
+11:56 < jtanx> when an 'emergency stop' due to the sanity checks occurs
+11:57 < jtanx> actually, start/pause/resume/close/emergency
+11:57 < jtanx> start/pause/resume/close can only be initiated by the client
+11:58 < jtanx> emergency can be initiated by client/server
+11:58 < jtanx> in emergency, actuators are set as necessary then deactivated
+11:58 < jtanx> but importantly, the data files remain open, which hopefully removes the need for mutexes
+12:26 < sam_moore> That seems sensible
+13:20 < sam_moore> Hey
+13:20 < sam_moore> It's actually quite simple to stream an image through FastCGI
+13:21 < jtanx> yeah
+13:21 < jtanx> you just fwrite the image buffer
+13:21 < sam_moore> Yep
+13:21 < jtanx> I had some test code for that but could never test it
+13:22 < jtanx> no webcam
+13:22 < sam_moore> Ah, damn
+13:22 < sam_moore> I've written some code, it works pretty brilliantly
+13:22 < jtanx> nice
+13:22 < jtanx> this control code is really annoying me
+13:23 < jtanx> just all the considerations of if you need a mutex here or not and 'what happens if...'
+13:23 < sam_moore> Ah, sorry to hear that
+13:23 < jtanx> yeah nah its ok
+13:24 < jtanx> but that interferometer stuff you did looks really cool
+13:26 < sam_moore> Yeah, it worked surprisingly well
+13:26 < sam_moore> It can cope with a fair bit of background light, even without all the improvements I was thinking about
+13:27 < sam_moore> If I add 2 or 3 more columns to scan, and use the fact that we actually know the spatial frequency to eliminate nodes that are too close together
+13:27 < sam_moore> It should be pretty good
+13:27 < sam_moore> I'm not sure what the laser intensity will be, but the generated image looks similar to ones you can find on the internet
+13:28 < sam_moore> One possible problem is if the mirrors aren't flat enough
+13:28 < sam_moore> But hopefully it won't be a big issue (since they've pretty much just specified an expensive pre-built kit which presumably has flat mirrors)
+13:29 < jtanx> yeah
+13:30 < jtanx> here's to hoping 'it just works'
+13:30 < sam_moore> Yep :P
+13:31 < sam_moore> Got to go, bye
+13:32 < jtanx> ok cya
+15:56 -!- jtanx_ is now known as jtanx
+21:48 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Mon Sep 16 2013
+16:05 -!- jtanx_ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+19:44 < jtanx> no mctxbot while I work on my f# project
+22:58 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Sep 17 2013
+09:50 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+15:34 < jtanx> to run the software not as root, we need to at least add it to the 'video' group so it can access the webcam
+15:34 < jtanx> not sure about the sensors
+15:34 < jtanx> eg sudo usermod -a -G video debian
+15:38 < sam_moore> Ah, cool
+15:39 < sam_moore> I think I worked out how to get around the camera crashing without killing the rest of the program, won't implement it for a while though
+15:57 -!- jtanx_ is now known as jtanx
+16:46 -!- jtanx_ is now known as jtanx
+18:02 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:18 < Callum> hey
+23:23 < sam_moore> Hi
+23:24 < Callum> do you know how to do the second question of that assignment?
+23:24 < Callum> https://docs.google.com/file/d/0B241H5liqVlnbHZETXRZX1Mwd1k/edit?usp=sharing
+23:25 < Callum> rather remember
+23:35 < sam_moore> Well, you can eliminate any epsilon^2 when you substitute those formulae for v into the formula for gamma
+23:35 < sam_moore> Then it has a really simple taylor expansion
+23:35 < Callum> i might have to hunt you down tomorrow to show me. or maybe il be able to think straight tomorrow.
+23:38 < sam_moore> You can express one of the epsilons in terms of the other one after that
+23:40 < sam_moore> I'm pretty busy tomorrow
+23:42 < Callum> mhmm. so no free time at all? coz im fairly free
+23:49 < sam_moore> Not from 8:00am until 5:00pm
+23:49 < Callum> ohwow. you are busy
+23:49 < Callum> im still unsure what im meant to be applyign the taylor expansion to
+23:53 < sam_moore> Substitute in the suggested formulae to gamma, simplify it, then apply a taylor expansion
+23:53 < sam_moore> Anyway, goodnight, good luck
+23:53 < Callum> night
+--- Day changed Wed Sep 18 2013
+09:11 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+21:03 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Thu Sep 19 2013
+16:08 < jtanx> one thing I forgot to mention - the latest version on git uses syslog
+16:08 < jtanx> if you copy the config file (server-configs/rsyslog.d/* ??) to /etc/
+16:09 < jtanx> it will log to /var/log/mctx[something I can't remember].log
+16:10 < jtanx> i'm pretty sure you can also create a log file specifically for warning level and above (so it logs in three places, stderr, the normal log, and a special 'error' log), but I haven't set this up yet
+18:17 < jtanx_> :0
+18:22 < sam_moore> ?
+18:50 -!- jtanx_ is now known as jtanx
+19:52 -!- MctxBot_ is now known as MctxBot
+20:24 < jtanx> I got the camera image to be updated in javascript instead: http://mctx.us.to:8080/test/
+20:25 < jtanx> right now it's updated around every ~400ms because my webcam is running through a usb1.1 link which seriously limits how fast it can update
+20:36 < jtanx> (its running on a pentium 3 computer)
+21:35 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Fri Sep 20 2013
+18:02 < jtanx> this seems like an interesting option, at least for the cam that just shows the can explode:http://sourceforge.net/apps/mediawiki/mjpg-streamer/index.php?title=Main_Page
+18:51 < sam_moore> Cool
+18:51 < sam_moore> It, ah
+18:52 < sam_moore> Looks like we might have to recompile the kernel to get PWM working
+18:52 < sam_moore> Hooray
+18:52 < sam_moore> Kernel compiling
+18:52 < sam_moore> What could possibly go wrong?
+19:02 < jtanx> really??
+19:02 < jtanx> why....
+19:03 < jtanx> no am33xx_pwm module?
+19:04 < sam_moore> Not that I can tell
+19:05 < jtanx> well crap
+19:06 < sam_moore> Well... surely I can find a precompiled kernel somewhere
+19:06 < jtanx> it seems that stuff for the BBB is at a really premature stage
+19:07 < sam_moore> Yeah, RPi is much nicer
+19:07 < jtanx> the BBB is just too new..
+19:07 < sam_moore> What's the point of having fancy things like ADC and PWM...
+19:07 < sam_moore> If you can't actually use them without jumping through hoops
+19:07 < jtanx> hahaha
+19:07 < jtanx> were you referencing this, when you said we might have to recompile the kernel? https://groups.google.com/d/msg/beagleboard/wjbOVE6ItNg/AGYVRhYbTX8J
+19:08 < sam_moore> Yeah
+19:08 < sam_moore> ...
+19:08 < sam_moore> I wonder if I can take the kernel used by Angstrom and stick it in /boot
+19:08 < sam_moore> on the SD card
+19:09 < jtanx> ._.
+19:10 < jtanx> what about kernels from here
+19:10 < jtanx> http://rcn-ee.net/deb/precise-armhf/
+19:10 < jtanx> sorry
+19:10 < jtanx> http://rcn-ee.net/deb/wheezy-armhf/
+19:11 < jtanx> what's it currently running
+19:12 < sam_moore> 3.8.13-bone20
+19:13 < sam_moore> Try 3.8.13-bone28 ?
+19:15 < jtanx> what about v3.8.9-bone15
+19:15 < jtanx> oh wait
+19:15 < jtanx> ~.~
+19:15 < sam_moore> I wonder why the BBB developers didn't go with debian...
+19:15 < jtanx> v3.11.0-bone5
+19:15 < jtanx> yeah
+19:15 < jtanx> why angstrom, of all things
+19:15 < sam_moore> Is angstrom used anywhere else?
+19:16 < jtanx> dunno
+19:16 < sam_moore> Other embedded devices, heh
+19:16 < sam_moore> Everyone just has to use their own distro :P
+19:17 < sam_moore> I didn't see the .11 kernels, I'll try the latest one
+19:17 < jtanx> want to try the rc version? lol
+19:18 < jtanx> oh the rc versions are older than .11
+19:19 < jtanx> how does it work?
+19:19 < jtanx> do you just download from http://rcn-ee.net/deb/wheezy-armhf/v3.11.0-bone5/
+19:19 < jtanx> the .sh script and run it from the BBB?
+19:24 < sam_moore> I think so
+19:25 < sam_moore> Well... here goes nothing
+19:26 < sam_moore> Hopefully between 3.8 and 3.11 they actually enabled PWM by default...
+19:27 < sam_moore> It looks like install-me.sh downloads all the .deb files appropriately
+19:29 < sam_moore> It's creating files like: /lib/firmware/bone_pwm_P8_36-00
+19:29 < sam_moore> Which looks promising
+19:29 < sam_moore> Snoopy is not yet on fire
+19:29 < sam_moore> Which is promising
+19:29 < sam_moore> Rebooting and praying
+19:31 < sam_moore> And... it booted into 3.8.13-bone20 -_-
+19:31 < sam_moore> Tempted to just symlink that filename to the new kernel
+19:34 < sam_moore> The new kernel exists in /boot, but obviously there's some boot config that needs to get set
+19:39 < sam_moore> Ok, screw this, I'm making a symlink just to see if it works
+19:40 < jtanx> lol
+19:41 < jtanx> no grub
+19:43 < jtanx> did update-initramfs run?
+19:46 < jtanx> or maybe we need mkimage
+19:47 < jtanx> yeah probably need mkimage
+19:50 < sam_moore> Um, zImage is a symlink to the kernel
+19:50 < sam_moore> But regardless, the new one won't boot
+19:50 < sam_moore> Such a pain
+19:50 < sam_moore> I wonder if we can just toggle the GPIO pin fast enough to implement PWM
+19:56 < sam_moore> Using a decent oscilloscope, I read a 6us period when switching GPIO1_28 on/off as fast as possible
+19:59 < sam_moore> That
+19:59 < sam_moore> s like 166KHz
+19:59 < sam_moore> Heh
+19:59 < sam_moore> Maybe the sources you found were closing the file and reopening it?
+20:01 < sam_moore> Yeah, wow
+20:02 < sam_moore> Using fopen, fprintf and fclose each time takes the period to 224us
+20:02 < sam_moore> Or 4KHz
+20:03 < sam_moore> Also for future reference, that CRO in G19 is definitely broken; it's always a lovely square wave on the modern oscilloscope I'm testing with now
+20:12 < jtanx> haha ok
+20:13 < jtanx> but without kernel support your pwm signal won't be very accurate
+20:13 < sam_moore> Yeah, I suppose
+20:13 < jtanx> how come the new kernel won't boot?
+20:14 < sam_moore> No idea
+20:14 < jtanx> Hmm
+20:14 < jtanx> this lack of documentation on how you do such procedures is pretty crap
+20:15 < sam_moore> Yeah, kernel developers aren't great on documentation
+20:15 < jtanx> is the mkimage package present?
+20:15 < jtanx> if not, install it and try running the install-me script again
+20:16 < jtanx> from this: http://www.jeremycole.com/blog/2011/03/09/beagleboard-upgrading-from-debian-5-to-debian-6/
+20:16 < jtanx> it should be just running that install script and rebooting
+20:16 < sam_moore> Alright, uboot-mkimage I presume?
+20:16 < jtanx> i guess
+20:17 < jtanx> and update-initramfs?
+20:18 < jtanx> (just looking at what the install-me.sh script uses)
+20:18 < sam_moore> Oh, does the script not fail if packages it needs don't exist...
+20:18 < sam_moore> -_-
+20:19 < jtanx> a quick scan says nup
+20:24 < sam_moore> Already had initramfs-tools but not mkimage, so I'll try again
+20:27 < sam_moore> I should probably have focused on the ADC reading before PWM
+20:27 < sam_moore> We're definitely going to get asked about aliasing again
+20:28 < jtanx> urgh yeah
+20:28 < sam_moore> I don't have a signal generator here though
+20:28 < jtanx> this BBB has definitely not been designed with 'plug n play' in mind
+20:28 < sam_moore> Mmm
+20:29 < sam_moore> The Angstrom image would work for this stuff, but obviously has limitations in terms of the webserver stuff
+20:29 < sam_moore> But even with Angstrom you still have to go through a similar convoluted process to control pins
+20:30 < sam_moore> From what I can tell there are two ways to do it
+20:30 < sam_moore> SYSFS, which I can't find much documentation on
+20:30 < sam_moore> Which is the /sys/class/gpio/ stuff
+20:30 < sam_moore> Which actually seems more intuitive than the other way
+20:31 < sam_moore> That involves echoing a bunch of cruft to /sys/devices/cape-manager/slots/ or something similar
+20:31 < jtanx> hmm
+20:32 < sam_moore> There is a /sys/class/pwm
+20:32 < sam_moore> But unfortunately whatever you export it complains about
+20:32 < sam_moore> Probably because the kernel wasn't compiled with it enabled
+20:32 < jtanx> is this with the old kernel?
+20:32 < sam_moore> Yeah
+20:33 < sam_moore> Hangon, the new one's probably finished building by now
+20:34 < jtanx> we don't know if the new one has been compiled with pwm support though
+20:34 < sam_moore> Yeah
+20:36 < sam_moore> The diff between the config options for the kernels shows that the old one has a comment "CONFIG_EHRPWM_TEST is not set" and the newer one has no reference to it
+20:37 < sam_moore> ...
+20:37 < sam_moore> Someone at some point
+20:37 < sam_moore> Has realised that PWM was not enabled
+20:37 < sam_moore> And commented that it isn't enabled
+20:37 < sam_moore> WHY THE HELL DIDN'T THEY JUST ENABLE IT
+20:37 < jtanx> :P
+20:37 < sam_moore> Anyway it still booted off the old kernel
+20:37 < sam_moore> Dinner time
+20:38 < jtanx> ok
+21:15 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
+21:15 < sam_moore> Looks promising
+21:16 < sam_moore> Hmm...
+21:17 < sam_moore> I'll try using 3.8 but building with the PWM
+21:18 < jtanx> building from source - fun fun :P
+21:19 < sam_moore> Well in theory I just change a config option
+21:19 < jtanx> yeah
+21:19 < sam_moore> When that doesn't work and I have to modify the source, that's when the fun begins
+21:19 < jtanx> let's just hope it works
+21:19 < sam_moore> Yeah, if it doesn't we're (beagle) boned
+21:19 < jtanx> oh while you're at it, figure out how to enable the ethernet-over-usb feature
+21:19 < sam_moore> Haha
+21:20 < jtanx> loljk
+21:25 < sam_moore> Hmmm... compiling a kernel is going to take a while
+21:26 < sam_moore> Ergh, why am I running it on this Pentium D
+21:30 < sam_moore> Hmmm, more troubling... why does a debian wheezy server have OpenSUSE sources in sources.list
+21:30 < sam_moore> Oh well, not my problem
+21:33 < jtanx> heh
+21:33 < sam_moore> How the hell are we going to explain this in the progress report...
+21:34 < sam_moore> Also, I didn't fully understand, why can't you use the same image for multiple BBB?
+21:34 < sam_moore> Are we going to have to do this all again for the other BBB?
+21:34 < sam_moore> Spike I mean
+21:37 < jtanx> no idea
+21:38 < jtanx> without some sort of debugging cable to see what happens when it boots, who knows
+21:38 < sam_moore> :S
+21:39 < sam_moore> I love how git gets to the head of the branch
+21:39 < sam_moore> By starting at the initial commit
+21:39 < sam_moore> And going through every commit and changing the file
+21:42 < sam_moore> It hasn't started building yet
+21:42 < sam_moore> And the way you customise the build...
+21:42 < sam_moore> Is to build it with the defaults, so that the options file exists, then change the options, then build it again -_-
+21:43 < jtanx> ಠ ಠ
+21:43 < sam_moore> Oh well, I have to go home, I'll try finish this tomorrow
+21:43 < sam_moore> Bye
+21:43 < jtanx> ok
+21:43 < jtanx> bye
+23:20 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sat Sep 21 2013
+11:23 < sam_moore> http://hipstercircuits.com/enable-pwm-on-beaglebone-with-device-tree-overlays/
+11:23 < sam_moore> So... according to this I should add pwm_test as a kernel module
+11:24 < sam_moore> "This is it. It is now three o’clock in the morning and I have not slept or eaten in two days. My neck is sore, my ass has fallen asleep and my organs are screaming “slow down, man”. I no longer see [CC]s, [LD]s and [AS]s, I only see blondes, brunettes and redheads flashing before my eyes. With my last ounce of energy I barely manage to type in “reboot” as my face hits the keyboard. And that is when it happens.."
+11:25 < sam_moore> Ummm
+11:25 < sam_moore> It's awesome that this guy has solved the problem (I think)
+11:26 < sam_moore> But a bit depressing that it still isn't in the official kernel
+11:29 < sam_moore> I think most people just give up and use Angstrom, which is tempting
+11:30 < sam_moore> I still have that HTTP server code... :P
+11:45 < sam_moore> Looks like Robert C Nelson's 3.8 kernel does have a pwm_test module
+11:45 < sam_moore> Maybe the image you used just had an out of date kernel?
+11:45 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
+11:51 < jtanx> hmm
+11:51 < jtanx> no idea
+11:51 < jtanx> it was made in july I think and it uses those rcn kernels
+11:51 < jtanx> We could always use lighttp
+11:51 < jtanx> lighttpd on angstrom if necessary
+11:52 < jtanx> lighttpd and install mod_fastcgi
+11:55 < jtanx> ok so the image uses 3.8.13-bone20, so maybe it wasn't enabled in that version, but it now is in 3.8.13-bone28?
+12:02 < sam_moore> I've just built 3.8.13-bone28 and the module pwm_test exists
+12:03 < sam_moore> ... I also copied the code from that guy's blog as pwm_test2 just in case :P
+12:03 < sam_moore> I'll have to test it later, but at least we have the kernel module
+12:08 < jtanx> nice
+12:39 < jtanx> ohhhhh I know why it didn't work from one bbb to the next, using the same image
+12:39 < jtanx> When you boot for the first time, it assigns the ethernet port eth0
+12:39 < jtanx> when you then take it out and boot it on a different BBB
+12:40 < jtanx> because the ethernet device has a different id, it gets assigned to say eth1
+12:40 < jtanx> and because you don't have any config for eth1 in your network config, there's no internet access
+12:40 < jtanx> http://www.eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-Networking:UsingasharedSDcardwithMultipleBeagleBone
+12:41 < jtanx> should fix that
+15:10 < jtanx> Eh, you know what I'll just stop the threads when you want to pause it
+15:10 < jtanx> instead of conditionals
+15:11 < jtanx> it's not like you're pausing the experiment that often
+15:18 < sam_moore> That's fine
+15:19 < sam_moore> The conditional approach is only really necessary if you're constantly pausing the threads
+15:19 < sam_moore> I used it for an nbody simulator, so the computation of force and position was split up between threads
+15:19 < sam_moore> It's really slow if you have to stop and then recreate the threads on every step
+15:22 < sam_moore> Although still actually faster than the single threaded program
+15:22 < sam_moore> Well, depending on how many objects you simulated
+15:23 < sam_moore> Anyway, just stop the threads, it's simpler to code and the performance effect in our case is probably negligable
+15:30 < jtanx> yeah
+15:30 < jtanx> say you had an actuator that was being controlled at that instant when an 'emergency stop' was issued
+15:31 < jtanx> since an 'emergency stop' is the same as just pausing (eg stopping the thread but keep DataFile open)
+15:31 < jtanx> you'd have to wait for that action to be completed before the 'emergency stop' would be propagated
+15:34 < jtanx> welp I guess that's why there's hardware safety interlocks
+15:38 < jtanx> Also, technically wouldn't it be possible to try to set the actuator value before the current value has been set
+15:38 < jtanx> Since there's no queue
+15:39 < jtanx> a->control could be overwritten by a new request as Actuator_SetValue operates
+16:12 < sam_moore> We want that right?
+16:13 < sam_moore> I'll look at it later if I get time
+16:14 < jtanx> I don't know if we want that or not
+16:15 < jtanx> wait want as in the current behaviour or the behaviour with a queue?
+16:16 < sam_moore> The current behaviour
+16:16 < sam_moore> I don't think you need a queue
+16:16 < sam_moore> You can extend the critical section in Actuator_Loop to stop the current control getting overwritten
+16:17 < sam_moore> Move the pthread_mutex_unlock on line 121 to below line 127 (Actuator_SetValue)
+16:17 < sam_moore> That way if Actuator_SetControl is called before the value has been successfully set, it will just wait
+16:17 < sam_moore> Mutexes actually implement a queue
+16:18 < sam_moore> If one thread has a lock on the mutex, subsequent threads that try to access the mutex will queue up; whenever the mutex is unlocked the next thread (if any) which was waiting will get it
+16:18 < jtanx> ok
+16:23 < jtanx> I'll leave it as is for now
+16:23 < sam_moore> Sure
+16:49 < sam_moore> PWM working
+16:49 < jtanx> nice
+16:50 < jtanx> I still don't really understand - did you compile the kernel from scratch
+16:50 < jtanx> or did you figure out how to use the install-me.sh script
+16:50 < sam_moore> I did, but I didn't need to modify it
+16:50 < jtanx> huh
+16:50 < jtanx> ok
+16:51 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
+16:52 < jtanx> so if we do this: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
+16:52 < jtanx> We should be able to just copy our image
+16:52 < jtanx> and stick it on the electronics' BBB
+16:53 < sam_moore> Sounds good
+16:53 < sam_moore> I'm glad that worked
+16:53 < jtanx> yeah
+16:54 < jtanx> I wonder if it also enabled the usb0 stuff (ethernet over usb)
+16:58 < sam_moore> PWM appears to have picosecond resolution? Or at least the arguments are in ps
+17:02 < jtanx> oO
+17:11 < sam_moore> ADC can sample at ~4KHz
+17:11 < sam_moore> But... that's using bash
+17:11 < sam_moore> It will probably be massively fast when done in C
+17:11 < jtanx> um
+17:11 < jtanx> is there any need to have it sample at a consistent rate
+17:11 < jtanx> as in, with threads there's no guarantee
+17:12 < jtanx> of a consistent sampling rate
+17:12 < sam_moore> Yes, you're right
+17:13 < sam_moore> I don't think we can achieve a consistent sampling rate, but I don't think it's critical that we do
+17:14 < sam_moore> As soon as we make our software run in an operating system with a kernel and other processes that can run as well, it gets pretty unfeasable to have a constant sample rate
+17:14 < sam_moore> We can have it constant to within an uncertainty I guess
+17:15 < jtanx> yeah, true
+17:18 < sam_moore> If you wanted a really high constant sample rate (say much faster than 1us which is probably the best case we could get) you'd have to use a more low level embedded device
+17:18 < sam_moore> Well I guess you could compile your own kernel for the BBB
+17:19 < sam_moore> But either way you'd have to physically run the webserver/GUI interface stuff on a seperate device
+17:19 < sam_moore> At this stage my feeling is what we have is good enough given the complexity of all the requirements we were given
+17:23 < jtanx> yeah
+17:25 < sam_moore> Hmm, I can set some GPIO pins to toggle whenever Sensor_Read is called and get an idea of sample rates and to what degree of accuracy we can quote the time stamps
+17:26 < sam_moore> I think I'll write some pin control code
+17:26 < sam_moore> I don't trust any of these custom libraries
+17:29 < jtanx> custom libraries?
+17:36 < sam_moore> Well they aren't really libraries
+17:36 < sam_moore> http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#Example_of_GPIO_access_from_within_a_C_program
+17:37 < sam_moore> Eg: That one has an fopen and fclose each time the value is changed
+17:38 < sam_moore> I could google until I find someone that has already written a C library, but chances are it will be slow or broken
+17:38 < sam_moore> Since I've worked out how to control the pins I may as well just write the C code to do it
+17:39 < jtanx> yep
+17:49 < sam_moore> I wonder if I can do this with a macro...
+18:30 < sam_moore> Ergh, screw that
+18:31 < sam_moore> Ok, I'm going to implement things like: GPIO/ADC/PWM_Export/Unexport to initialise or deinitialise all pins
+18:31 < jtanx> Ok
+18:31 < jtanx> too much effort with macros?
+18:31 < sam_moore> Yeah,
+18:32 < sam_moore> I was thinking of having something like "GPIOX_Set()" instead of GPIO_Set(int x)"
+18:32 < sam_moore> But that's probably not as nice as I thought it was
+18:32 < sam_moore> Anyway, there's an enum in the header file that contains the id of all pins used
+18:32 < sam_moore> The implementation defines some structs that wrap around the file descriptors
+18:33 < sam_moore> But to use the module you just give it an ID as defined in the enums
+18:33 < jtanx> Makes sense
+18:33 < jtanx> designing the gui is actually not too bad
+18:33 < sam_moore> That's good
+18:34 < jtanx> looks ok in ie8 too
+18:34 < sam_moore> Nice
+18:35 < jtanx> gotta go, dinner
+18:35 < sam_moore> Ok
+18:35 < sam_moore> Hmm, it would be nice if C had value checking on enums
+18:35 < sam_moore> You can define a function that takes an enum type as an argument
+18:36 < sam_moore> But people can still just pass any old integer
+18:36 < sam_moore> As far as I know
+18:36 < sam_moore> eg: typedef enum {FIRST=1, SECOND=10, THIRD=100} EnumType
+18:36 < sam_moore> void Foo(EnumType e);
+18:37 < sam_moore> If you go Foo(2) it won't complain
+18:38 < sam_moore> Annoying
+18:38 < sam_moore> That seems like something the compiler would be able to pick up
+19:31 < sam_moore> Ergh, I'm getting too obsessive compulsive with this pin thing
+19:35 < sam_moore> It's annoying because ADC, GPIO and PWM are treated completely differently
+19:35 < sam_moore> You write one thing and it enables *all* the ADCs
+19:35 < sam_moore> You have to enable each GPIO pin individually
+19:36 < sam_moore> And to enable PWM pins you give a string (not just an integer)
+19:37 < sam_moore> Also the location of the pin files is not guaranteed (though it probably doesn't change for a given system configuration)
+19:39 < sam_moore> Ah, I found a way to enable pwm with /sys/class/ instead of that cape manager thing
+19:39 < sam_moore> I think I'll use that, since at least it's consistent with the GPIO stuff
+19:41 < sam_moore> Ooh!
+19:41 < sam_moore> http://beagleboard-gsoc13.blogspot.com.au/2013/07/sampling-analogue-signals-using-adc-on.html
+19:41 < sam_moore> Provides a driver for continuously sampling with the ADC
+19:41 < sam_moore> Oh wait
+19:41 < sam_moore> Crap in a bucket
+19:42 < sam_moore> Because we're using those multiplexers we can't do that
+19:42 < sam_moore> We have to set the multiplexer before each sample
+19:42 < sam_moore> Oh well, never mind
+19:44 < sam_moore> I suppose we could write our own kernel module :S
+19:45 < sam_moore> I think I understand this enough to talk to Adam next time he tries to talk about sample rate
+19:46 < sam_moore> 1. It's not actually constant, but we can probably have it constant to within a few us
+19:46 < sam_moore> 2. To make it constant would require writing a kernel module
+19:47 < sam_moore> Unless electronics stops being stingy and gets one amplifier per channel :P
+20:22 < jtanx> hehehe
+20:22 < jtanx> next week's adrian though
+20:22 < sam_moore> Ah
+20:23 < jtanx> grilling time
+20:23 < sam_moore> He'll probably ask us the same things :P
+20:23 < jtanx> yeah
+20:23 < jtanx> but man, so much stuff to go through just to get some readings from a few pins
+20:24 < jtanx> so good job with that :P
+20:54 < sam_moore> Thanks
+22:45 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sun Sep 22 2013
+00:51 < sam_moore> Hell yes
+00:51 < sam_moore> PWM controlled through web browser
+00:51 < sam_moore> GPIO controlled through web browser
+01:19 < sam_moore> .... And ADC read through web browser
+01:19 < sam_moore> Blergh
+01:28 < sam_moore> I think I'll take the rest of today off from MCTX3420 :S
+11:53 < sam_moore> I've analysed the crap out of sampling rates for this ADC
+11:53 < sam_moore> At least as much as I can just using the timestamps according to gettimeofday
+11:54 < sam_moore> Contrary to my first email, reading the ADC is actually really slow. And also probably the greatest source of variation in sampling rate.
+11:56 < jtanx> wow
+11:56 < jtanx> only 100Hz?
+11:56 < sam_moore> Well it looks more like 1KHz on the oscilloscope, but there's a lot of variation, it has trouble getting a trigger
+11:57 < jtanx> the cpu datasheet rates it at 200kSPS
+11:57 < sam_moore> Hmm
+11:58 < sam_moore> Well judging by the control it is something about the ADC reading that makes it really slow
+11:58 < jtanx> That's annoyng
+11:58 < sam_moore> Yeah
+11:58 < sam_moore> Also annoying is that the ADC file is generally in a different place each time they're enabled
+11:59 < sam_moore> I ended up modifying the program to take the path to the ADC file as an argument
+11:59 < sam_moore> And making run.sh do the initialisation
+11:59 < sam_moore> I figured that was better than calling system()
+11:59 < jtanx> that makes sense
+11:59 < sam_moore> Yep, we might want to set other options that run.sh can pass to it anyway
+12:00 < sam_moore> Ok, I have to stop now, I'm spending way to much time on this
+12:00 < jtanx> Haha
+12:00 < sam_moore> It's getting to the point where I'm considering writing an ADC kernel module that doesn't suck :S
+12:01 < jtanx> :S let's hope it doesn't get to that stage
+20:12 < jtanx> the pressure regulator has a 1-5vdc analogue output
+20:12 < jtanx> is this considered one of the pressure sensors?
+20:14 < jtanx> or maybe it's just not used
+21:50 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Mon Sep 23 2013
+08:51 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+20:55 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+22:33 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+--- Day changed Tue Sep 24 2013
+14:18 < jtanx> with kernel 3.8 they decided to make life hard with device tree overlays
+14:19 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/277811.aspx
+14:19 < jtanx> https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
+14:47 < jtanx> huh
+14:47 < jtanx> http://www.youtube.com/watch?v=6gv3gWtoBWQ
+14:47 < jtanx> http://digital-drive.com/?p=146
+15:39 < sam_moore> I wonder if I can write a module that just uses /dev/adcX /dev/gpioX and /dev/pwmX
+15:40 < jtanx> that would make life simple
+15:40 < jtanx> but no
+15:42 < sam_moore> http://www.tldp.org/LDP/lkmpg/2.6/html/x569.html
+15:42 < sam_moore> Probably out of date (2.6?)
+15:45 < sam_moore> Also rt.wiki.kernel.org - realtime linux supposedly gives you better timing accuracy, although it would possibly break with our setup involving nginx
+15:46 < sam_moore> Actually it looks like there are quite a few ways for it to not work
+15:48 < jtanx> I think trying to write a kernel module would cause more grief than it's worth
+15:50 < jtanx> http://saadahmad.ca/using-pwm-on-the-beaglebone-black/
+15:51 < jtanx> I have no idea what's been updated and what hasn't
+15:51 < jtanx> as in, do we have that fix in our kernel
+15:53 < sam_moore> I don't know
+15:54 < sam_moore> We only need 1 PWM though
+16:00 < sam_moore> Or at least, last we heard there was only one. Doesn't make the system very expandable though.
+19:07 < jtanx> you know what I'll try loading an Ubuntu image from rcn to my sd card
+19:08 < jtanx> instead of from armhf
+19:08 < jtanx> armhf.com*
+19:17 < jtanx> ah screw it
+19:17 < jtanx> i'll stick with debian (but do the same thing)
+21:07 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Wed Sep 25 2013
+12:15 < jtanx> I think I know why we were having issues with pwm yesterday
+12:16 < jtanx> if you do this command
+12:16 < jtanx> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.8/slots
+12:16 < jtanx> you make it unavailable from /sys/class/pwm
+12:16 < jtanx> so in the run.sh script it was exporting all the pwm devices via the first method
+12:16 < jtanx> and then it becomes unavailable via sysfs
+12:17 < jtanx> anyway... I tried booting from the rcn image
+12:17 < jtanx> it comes with pwm enabled already
+12:17 < jtanx> and via that capemgr I got pwm to work
+12:17 < jtanx> I don't know what /sys/class/pwm/pwm0 corresponds to (which pin)
+12:19 < jtanx> the electronics teams' bbb wasn't done properly when we tried to upgrade the kernel
+12:19 < jtanx> probably something to do with the device tree stuff
+12:19 < jtanx> so I flashed it with the rcn image (which runs 3.8.13-bone26
+12:20 < jtanx> (demo image from here)
+12:20 < jtanx> elinux.org/BeagleBoardDebian
+13:09 -!- jtanx_ is now known as jtanx
+13:16 < jtanx> oh
+13:16 < jtanx> so it now works
+13:16 < jtanx> echo bone_pwm_P9_22 > slots
+13:16 < jtanx> if I do that line for pwm0
+13:26 < jtanx> oh right
+13:26 < jtanx> echo bone_pwm_P9_21 >slots
+13:26 < jtanx> for pwm1
+13:30 < jtanx> ahhhhhh
+13:30 < jtanx> if you comment out the line
+13:30 < jtanx> modprobe pwm_test
+13:30 < jtanx> from run.sh
+13:30 < jtanx> it works
+13:43 < jtanx> geeze kernel 3.8 has issues with usb hotplugging
+13:43 < jtanx> https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/usb/beagleboard/8aalvyWwaig/MUXAPuMTSOYJ
+13:43 < jtanx> which explains why we're having issues with cameras
+13:43 < jtanx> (partly at least)
+13:47 < jtanx> and now pwms not working again
+13:48 < jtanx> via sysfs
+13:50 < jtanx> oh
+13:50 < jtanx> I know why
+13:51 < jtanx> you have to export it /sys/class/pwm
+13:51 < jtanx> first
+13:51 < jtanx> *before* you do stuff like echo bone_pwm_P9_21 >slots
+13:52 < jtanx> yep
+13:53 < jtanx> so the order is: echo 0/1 > /sys/class/pwm/export
+13:53 < jtanx> then do that other stuff
+13:57 < jtanx> egh
+13:57 < jtanx> finnicky
+13:57 < jtanx> ok I have to stop now
+16:04 < jtanx> well that was an interesting experience
+16:04 < jtanx> it's most reliable when you work directly with /sys/devices/ocp2.helper/PWM9_22*
+16:05 < jtanx> I think if you echo am33xx_pwm to the slots thing when it's already loaded
+16:05 < jtanx> weird shit can happen
+16:05 < jtanx> too
+16:07 < jtanx> setting the period via sysfs (eg /sys/class/pwm) didn't work most of the time either
+16:07 < jtanx> you could change duty but not period
+16:07 < jtanx> although I swear I had it working at one point
+16:07 < jtanx> via the other way I think it works ok
+16:08 < jtanx> oh yeah, and I was doing this using the demo image from http://elinux.org/BeagleBoardDebian
+16:09 < jtanx> the electrical group's one has been reflashed with that version as well
+16:09 < jtanx> (for ours I worked off my sd card)
+16:10 < jtanx> that image also enables the ethernet-over-usb
+16:36 < jtanx> I think we have to be careful which pins we export/enable
+16:37 < jtanx> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
+16:37 < jtanx> pages 80-82
+16:37 < jtanx> the pins have different meanings based on what mode they're in
+16:41 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+18:05 < jtanx> ...so I brought the BBB home, even though I should be studying for 2402 :S
+18:05 < jtanx> the microphone came in today too
+18:19 < jtanx> ok
+18:19 < jtanx> so these documents: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
+18:19 < jtanx> describes what the pins are used for by default
+19:00 < sam_moore> Ah... they already got the microphone
+19:00 < sam_moore> Welp. Guess we're stuck with it.
+19:00 < sam_moore> So... we can record <50Hz sounds reliably, maybe
+19:00 < sam_moore> How useful
+19:01 < sam_moore> Have I been missing out on an email stream where the sensors team actually clears things with us?
+19:04 < jtanx> not that I know of
+19:04 < jtanx> haha
+19:04 < jtanx> in other news
+19:04 < jtanx> the sensors team ordered a pressure sensor with no mount
+19:04 < jtanx> adrian had a spat because it'd cost something like $200 to make the mount
+19:05 < jtanx> for a $10 part
+19:05 < jtanx> so he said, order it from online , I don't care if it's from overseas
+19:05 < sam_moore> Oh boy
+19:06 < sam_moore> If there's an issue with the camera and/or microphone they'll blame us
+19:06 < jtanx> yeah
+19:06 < jtanx> about that camera
+19:06 < sam_moore> Oh dear...
+19:06 < sam_moore> Go ahead?
+19:06 < jtanx> still couldn't get it to work today
+19:06 < sam_moore> God dammit
+19:06 < jtanx> although I didn't spend much time on it
+19:06 < jtanx> I got pwm to work
+19:06 < jtanx> mostly
+19:06 < sam_moore> I thought it might be something like adding the user to the "video" group
+19:06 < sam_moore> That's good!
+19:07 < sam_moore> What was happening?
+19:07 < jtanx> yeah, the problem is it doesn't show up at all (the camera)
+19:07 < sam_moore> Hmm
+19:07 < jtanx> and partly because 3.8 has an issue with usb hotplugging
+19:07 < sam_moore> Haha
+19:07 < jtanx> about pwm
+19:07 < jtanx> it seems that the sysfs method is not so reliable
+19:07 < jtanx> you can get it to work
+19:07 < jtanx> you have to export those first
+19:07 < jtanx> so echo 0 > /sys/class/pwm/export
+19:08 < jtanx> then (and only then)
+19:08 < jtanx> can you do
+19:08 < jtanx> that echo to the slots
+19:08 < jtanx> for those pins
+19:08 < jtanx> then it seems to be happy
+19:08 < jtanx> if you echo am33xx_pwm to the slots when it's already enabled
+19:08 < jtanx> that also screws things up
+19:08 < sam_moore> Ok
+19:09 < sam_moore> Thanks for working that out
+19:09 < jtanx> yeah
+19:09 < sam_moore> If you want to change from sysfs to the other method that's fine
+19:09 < sam_moore> But sysfs was much simpler to code
+19:09 < jtanx> should have spent that time studying for mech2402 though :P
+19:09 < sam_moore> Because you just sprintf an integer to the path
+19:09 < jtanx> yeah
+19:09 < jtanx> witht he other way it's all that dynamic path crap
+19:09 < sam_moore> Rather than keeping track of "bone_pwm_test_P9_22.15.arbitrary_string" crap
+19:09 < sam_moore> Exactly :P
+19:09 < jtanx> but
+19:10 < jtanx> you can enable pwm and analogue on boot
+19:10 < jtanx> if I can find the link
+19:10 < sam_moore> Sure, if that's easy
+19:10 < sam_moore> I figured if we put them in the /etc/init.d script that'd be fine too
+19:10 < sam_moore> Actually... maybe we should put it in the /etc/init.d script
+19:11 < jtanx> oh yeah
+19:11 < jtanx> and the demo image from that rcn image
+19:11 < sam_moore> Because if someone gets a different beaglebone then they'd have to reenable it on boot
+19:11 < jtanx> is better than screwing around with recompiling kernels
+19:11 < sam_moore> Can you give a link?
+19:11 < jtanx> I think it's the first image that you had originally
+19:11 < jtanx> http://elinux.org/BeagleBoardDebian
+19:12 < jtanx> there's this script in /boot
+19:12 < sam_moore> Oh
+19:12 < jtanx> that allows you to copy the sd card to flash
+19:12 < jtanx> it also enables the usb over ethernet
+19:12 < sam_moore> Oh right, the image I downloaded before we used yours
+19:12 < sam_moore> Cool
+19:12 < jtanx> yeah
+19:12 < jtanx> I flashed electronics' one with that
+19:12 < sam_moore> Does PWM and stuff work on it?
+19:13 < jtanx> probably
+19:13 < jtanx> I was using the same image
+19:13 < jtanx> on ours
+19:13 < jtanx> you run this script and it copies exatly what's on the sd card to the internal flash
+19:13 < jtanx> resizes the partition as necessary
+19:13 < jtanx> http://digital-drive.com/?p=146
+19:13 < jtanx> that page shows how to enable on boot
+19:13 < jtanx> it's just a change to uEnv.txt in the boot partition
+19:18 < sam_moore> Good work
+19:19 < sam_moore> While I remember, for multiple logins and crap... can you just try to login as a local user account?
+19:19 < sam_moore> Then we could make a wrapper around adduser and deluser for the "administrator" account
+19:19 < jtanx> wow
+19:20 < jtanx> I don't know
+19:20 < sam_moore> I was just thinking
+19:20 < sam_moore> Linux has a user account system already
+19:20 < jtanx> yep, but is it a good idea to be making ~300 on a BBB?
+19:21 < sam_moore> Well... putting LDAP on the BBB probably won't be less intense
+19:21 < sam_moore> I know it's called "Lightweight"
+19:21 < sam_moore> But that's in comparison to "DAP"
+19:21 < jtanx> well to be perfectly honest, adrian is asking way too much
+19:21 < sam_moore> Which was designed in the 1980s by a telephone directory company and used the original OSI networking model
+19:21 < jtanx> you simply can't support a 300-odd user base on something like a BBB
+19:21 < sam_moore> Yeah
+19:22 < sam_moore> But maybe something like 30 users would work?
+19:22 < jtanx> yeah
+19:22 < jtanx> let's just keep it at that limit
+19:22 < sam_moore> Another thing regarding the crazy requirements...
+19:22 < sam_moore> If we have multiple Beaglebones running FastCGI
+19:23 < sam_moore> We can design our GUI so that it has links to the appropriate Beaglebone for each function
+19:23 < sam_moore> I don't think we actually need to do anything in nginx or the Beaglebone software
+19:24 < jtanx> hmm
+19:24 < sam_moore> At least in terms of displaying sensor data
+19:24 < sam_moore> For actuator control, we would need to introduce networking between individual beaglebones
+19:24 < jtanx> it actually depends on what he means by 'extensible' and/or distributed
+19:24 < jtanx> like
+19:24 < jtanx> you could say this BBB is for this experiement
+19:25 < jtanx> this other BBB is for this other experiment
+19:25 < sam_moore> But quite frankly you'd be mad to trust a distributed system with networking delays to coordinate control over hardware
+19:25 < jtanx> well yeah
+19:25 < sam_moore> Well at least something like this where we care about safety
+19:25 < sam_moore> But if you keep the actual control over hardware independent and on seperate devices
+19:25 < jtanx> but I mean
+19:26 < jtanx> wait
+19:26 < jtanx> if we interpret it as meaning
+19:26 < jtanx> that each BBB runs an instance of the software
+19:26 < jtanx> then they would still be separate
+19:26 < jtanx> as in each BBB controls one 'experiment'
+19:26 < jtanx> you customise each BBB based on the experiment that needs to be done
+19:26 < sam_moore> Yes, that would work
+19:26 < sam_moore> Yep
+19:26 < jtanx> then there's no interaction between BBBS
+19:27 < jtanx> the only thing is you have some sort of control at the front
+19:27 < jtanx> that determines which BBB you connect to
+19:27 < sam_moore> Yes, if there's interaction between BBBs it gets problematic
+19:27 < jtanx> yeah
+19:27 < sam_moore> Yes, you have one BBB which gives the user the "main menu" part of the GUI
+19:27 < jtanx> I reckon that's a stupid requirement to ask
+19:27 < jtanx> yeah
+19:27 < sam_moore> Then the others just have customised GUIs or whatever
+19:28 < jtanx> once you have to get them to talk to each other, you're then having to try and invent a whole new protocol
+19:28 < jtanx> for that
+19:28 < sam_moore> Yeah, and it depends on exactly what the hardware is
+19:29 < sam_moore> You might be able to hack it onto the web protocol (eg: BeagleBone #1 sends http://beaglebone2/api/actuators?id=X?set=Y)
+19:29 < sam_moore> But... let's not think about that
+19:30 < sam_moore> It's clearly beyond the scope of this project
+19:31 < sam_moore> So, after all that, I reckon if we use snoopy for ADC/GPIO/PWM and spike for the dilatometer then that would be cool (probably not actually necessary though)
+19:31 < jtanx> yeah
+19:32 < sam_moore> The dilatomter... it's going to cause headaches if Kieren really wants to "return" an array of points
+19:33 < sam_moore> If the goal is to provide the user with a demonstration of what the dilatometer is doing, then you can just edit an image
+19:33 < sam_moore> If the goal is to provide more data... I don't see the point really
+19:34 < sam_moore> It's going to be the same sort of distribution every time
+19:34 < sam_moore> Realistically all anyone would do is average it
+19:34 < sam_moore> Maybe take a standard deviation
+19:36 < jtanx> I really don't know why a dilatometer's even needed
+19:36 < sam_moore> Educational reasons? :P
+19:37 < jtanx> haha sure
+19:37 < sam_moore> Anyway, hopefully Callum will deal with the dilatometer stuff
+19:37 < sam_moore> The interferometer code is a good starting point
+19:39 < jtanx> Yeah
+19:39 < jtanx> hopefully
+19:42 < sam_moore> We should arrange some meetings next week
+19:42 < sam_moore> Also I'd like to see more of the other group members committing to git and talking in this channel
+19:45 < sam_moore> People are missing a lot of design decisions here :S
+19:45 < jtanx> Yeah
+19:51 < jtanx> Ok
+19:51 < jtanx> so I made a LUT from pin number on the board to GPIO pin number
+19:52 < jtanx> so if you wanted to use P8_13
+19:52 < jtanx> you can use the lut to figure out what gpio number that corresponds to
+19:53 < jtanx> we should probably restrict which pins can be used
+19:53 < jtanx> because quite a few are reserved
+19:53 < sam_moore> Sure
+19:53 < sam_moore> Remove the #defines in bbb_pin_defines.h ?
+19:54 < sam_moore> Don't export those pins in pin_test.c
+19:54 < sam_moore> It is only really for testing anyway
+19:54 < jtanx> yeah
+19:55 < sam_moore> Although... I predict if we leave it in the software, *someone* at some point will try and control hardware directly through it :P
+19:55 < sam_moore> For all the educational stuff it's nice though
+19:56 < sam_moore> Oh, we could have an image of the pinout diagram
+19:56 < sam_moore> And when someone clicks on a part of the image they get to control that pin
+19:57 < sam_moore> Anyway... I really should study for MECH2402 or I will fail it
+19:57 < sam_moore> So bye
+19:57 < jtanx> yeah
+19:57 < jtanx> bye
+20:50 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Thu Sep 26 2013
+17:52 < jtanx> http://www.ti.com/lit/ug/spruh73i/spruh73i.pdf p1986 (chapter 15) on pwm
+17:55 < jtanx> page 1996 on ePWM
+17:56 < jtanx> ahhhhh
+17:56 < jtanx> for ehrpwm0a/0b
+17:56 < jtanx> the frequency is linked
+18:08 < jtanx> ehrpwm is enhanced resolution pwm
+18:08 < jtanx> Implemented using the A signal path of PWM, that is, on the EPWMxA output. EPWMxB output has
+18:08 < jtanx> conventional PWM capabilities
+18:08 < jtanx> (p2053)
+19:06 < jtanx> if you want to make the pwm stuff not suck
+19:06 < jtanx> there's this file called pwm_test.c
+19:06 < jtanx> that's the driver
+19:59 < jtanx> for future ref: http://armsdr.blogspot.com.au/2013/04/archlinux-on-beaglebone-and-linux-38.html
+21:19 < jtanx_> urgh wow
+21:19 < jtanx_> ok, so I think pwm1/3/5 shouldn't be used to avoid period conflicts
+21:19 < jtanx_> (pwm0/1 is for channel A/B of one pwm device, 3/4 another, 5/6 another)
+21:20 < jtanx_> btw the correspondence between pwmX and pin number is:
+21:21 < jtanx_> P9_22, P9_21, P9_42. P9_14, P9_16, P8_19, P8_13, P9_28
+21:23 < jtanx_> pwm 2/7 correspond to eCAP devices
+21:24 < jtanx_> which I think are to capture PWM input
+21:24 < jtanx_> but they can also be used to generate PWM output, afaik
+23:08 -!- jtanx_ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Fri Sep 27 2013
+13:29 < jtanx> so, apparently if we don't order stuff that we need before the mid semester break (ie today), adrian just won't order it
+13:29 < jtanx> in other news, I think I've mostly sorted out pwm
+13:43 < jtanx> trying to standardise the pin code
+20:10 < jtanx_> lol
+20:10 < jtanx_> we have a file authored '14 years ago'
+20:10 < jtanx_> in git
+20:10 < jtanx_> talk about commitment
+21:47 < jtanx_> so on non-BBB platforms, I disabled the pin code
+21:47 < jtanx_> required some pretty dubious hacks to stop gcc from complaining
+21:48 < jtanx_> 1st attempt: define the functions to nothing
+21:48 < jtanx_> gcc complains about statements that do nothing
+21:48 < jtanx_> various combinations later on statements that do nothing, I move to making function stubs
+21:49 < jtanx_> shaft all the parameters to the stubs
+21:49 < jtanx_> to stop complaints about unused variables
+21:49 < jtanx_> (eg if you did int freq=1000; PWM_Set(...,freq) where the define for PWM_Set doesn't use freq
+23:12 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
git.ucc.asn.au / matches / MCTX3420.git / blobdiff
UCC git Repository :: git.ucc.asn.au