22:23 < sam_moore> 0/away
22:24 < sam_moore> Stupid network lag
23:13 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sat Oct 05 2013
+11:37 < sam_moore> Hi, I'm at Uni, but we can't access G19
+11:38 < sam_moore> I was hoping Rowan, Justin, James or Callum would come in though
+11:38 < sam_moore> But I guess I need to do more stuff for CITS3003 anyway
+12:18 < jtanx> Sorry, I can't make it today
+12:19 < jtanx> Too much crap with my CITS3242 and CITS2232 projects to deal with
+12:19 < sam_moore> Ok no problem
+13:16 < jtanx> james just posted some layout stuff via email
+18:06 < jtanx> now... to do some work on this gui
+21:15 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sun Oct 06 2013
+11:17 < jtanx> slight problem: http://i.imgur.com/D28SHaQ.png
+11:17 < jtanx> 100% cpu usage on idle
+11:18 < jtanx> that memory usage too doesn't look too healthy
+11:18 < sam_moore> Damn
+11:20 < jtanx> I also probably figured out why valgrind crashes with the --trace-origins option - not enough memory on my system :P
+11:30 < jtanx> It's probably because in read data all the cases except one have a sleep in them
+11:31 < sam_moore> I'd say so
+11:31 < sam_moore> There are like 8 threads
+11:31 < sam_moore> We don't need 8 threads
+11:39 < sam_moore> Are you in G19?
+11:39 < jtanx> no
+11:40 < sam_moore> Alright
+11:40 < sam_moore> I suppose I should do some work on this
+11:40 < sam_moore> CITS3003 is funner though
+11:40 < sam_moore> I'll look into the performance issues
+11:41 < jtanx> hehe
+11:42 < sam_moore> My "Incident" with UWA IS is now Moderate Priority
+11:42 < sam_moore> It's been assigned!
+11:42 < sam_moore> I suppose I should wait for this guy to email me and say "What the hell are you on about?"
+11:42 < sam_moore> (Re: Using Pheme)
+11:42 < sam_moore> They classified it as a "Request for service"
+11:43 < sam_moore> Which I suppose is true, except they don't really have to do anything
+11:43 < jtanx> o.o
+11:44 < jtanx> I hope it goes through
+11:44 < sam_moore> Yes, no one's going to do a user management system
+11:44 < jtanx> Yep
+11:44 < sam_moore> When people complain they have nothing to do though...
+11:44 < sam_moore> That's like a semester of work right there
+12:40 < sam_moore> um... that image you linked
+12:40 < sam_moore> That's not actually running on the BeagleBone is it?
+12:40 < sam_moore> Because on the BeagleBone
+12:40 < sam_moore> It's like 0.7%
+12:41 < sam_moore> Actually 0.3% CPU 1.1% memory
+12:50 < jtanx> no
+12:50 < jtanx> that's because there's a conditional #ifdef
+12:50 < jtanx> beaglebone to sleep
+12:50 < jtanx> I got that condition around the wrong way
+12:50 < jtanx> Initially I thought you wanted to test the absolute maximum sampling rate on the BBB
+12:53 < jtanx> I just updated the repo to really remove that pwm array reference
+12:54 < jtanx> (about the cpu) It's because of this: https://github.com/szmoore/MCTX3420/blob/master/server/sensor.c#L257
+12:55 < jtanx> That ifdef should be removed anyway, just put in an unconditional sleep for 0.1s
+12:55 < jtanx> then remove the individual sleeps from each sensor case
+13:17 < sam_moore> Sure
+13:17 < sam_moore> Light has been shed on the PWM thing
+13:18 < sam_moore> They are using some RC circuit which I believe averages out the PWM to give you a constant signal
+13:18 < sam_moore> I thought it was some kind of IC that took a PWM input
+13:21 < jtanx> oh ok
+13:22 < jtanx> yeah that's what I thought too
+13:22 < jtanx> so no dac I guess
+13:22 < jtanx> (dac ic that is)
+13:24 < sam_moore> I have my doubts that electronics will be able to make this custom DAC
+13:24 < sam_moore> And of course, no DAC means no Pressure control
+13:24 < sam_moore> But oh well
+13:24 < jtanx> ^_^
+13:24 < jtanx> homebrew DAC
+13:25 < jtanx> how will this ever be calibrated
+13:26 < sam_moore> We should probably include a calibration routine in software
+13:27 < sam_moore> I'm looking a bit more into the RT linux stuff
+13:27 < sam_moore> It doesn't look too crazy
+13:27 < sam_moore> Our program pretty much looks the same
+13:27 < sam_moore> With a function at initialisation to set it's priority and stuff
+13:27 < sam_moore> But otherwise, you just use usleep, sleep, pthreads, everything as normal
+13:28 < jtanx> ok
+13:28 < jtanx> as long as it works on the bbb I guess
+13:30 < sam_moore> I think I should port from gettimeofday to clock_gettime too
+13:35 < sam_moore> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
+13:35 < sam_moore> I'll compile us a kernel and see if it works
+14:09 < sam_moore> Yeah, it looks like RT Linux won't work on the BBB
+14:09 < sam_moore> Oh well
+14:17 < jtanx> damn
+15:34 < Callum> Hey guys, sorry i havent been in touch lately. done a bit of work on dilatometer but its not quite complete. Uploaded what iv done but i got a test i tomorrow i should go study for now
+16:29 < jtanx> hahaha
+16:30 < jtanx> interactive sbd
+16:31 < jtanx> hmm dialatometer
+16:45 < jtanx> Justin's idea with the system diagram was pretty good
+16:55 < jtanx> test run: https://mctx.us.to:8043/test/
+16:55 < jtanx> no links yet
+16:55 < jtanx> no descriptions either
+16:55 < jtanx> logout when you're done
+16:55 < jtanx> no auth so type anything you want in login field
+17:24 < Callum> looks pretty good
+18:12 < jtanx> I stuffed up /etc/fstab and now the root filesystem is readonly :(
+18:19 < jtanx> ...and I just wasted time booting off ubuntu 7.04, which doesn't support ext4...
+18:43 -!- Callum_ is now known as Callum
+19:30 < jtanx> I've just enabled personal webspace for everyone
+19:30 < jtanx> check your emails for details
+19:52 < jtanx> :(
+21:11 < sam_moore> Cool
+21:11 < sam_moore> Sorry, I'm trying to finish CITS3003
+21:25 < jtanx> Yep no problem
+21:38 < jtanx> nice: http://cssmenumaker.com
+22:09 < jtanx> weird, getting http 500 when trying to access our github repo
+23:16 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Mon Oct 07 2013
+12:47 < callum> you guys in g19?
+18:44 < jtanx> ha, you can clone a wiki
+18:45 < jtanx> git clone https://github.com/szmoore/MCTX3420.wiki.git
+20:50 < sam_moore> Yeah, I know
+20:51 < sam_moore> I don't really think it's great to be relying on the BeagleBone to serve all these additional requirements
+20:51 < jtanx> Yeah, probably not
+20:52 < jtanx> I've just been playing around with django for my CITS2232 project
+20:52 < jtanx> it's like a python based cms
+20:53 < sam_moore> That might work
+20:53 < jtanx> It's actually not too bad
+20:53 < jtanx> but incredibly annoying to learn how to use
+20:53 < jtanx> it's got its own inbuilt user system
+20:54 < sam_moore> How could we query it from our server though?
+20:54 < jtanx> as in?
+20:54 < jtanx> you can still query directly from the browser
+20:54 < jtanx> from django itself
+20:54 < jtanx> I'm definitely sure there's a json parsing library
+20:55 < jtanx> (python at least should have one)
+20:56 < sam_moore> As in, if we want to "login"
+20:56 < sam_moore> How do we authenticate?
+20:57 < sam_moore> From within the FastCGI process
+20:57 < jtanx> Okay, there's two approaches I guess
+20:58 < jtanx> if you want to continue to use fastcgi to login I guess you could get django to figure out
+20:58 < jtanx> who's logged in
+20:58 < jtanx> If you use django's login system
+20:58 < jtanx> hmm
+21:00 < jtanx> but one thing I haven't done yet is how do you prevent concurrent access in django
+21:01 < jtanx> but say this:
+21:01 < sam_moore> I think binding to an LDAP server is pretty standard for this sort of thing
+21:01 < sam_moore> I think Django can even let you bind to LDAP for using it
+21:01 < jtanx> probably
+21:01 < jtanx> I think class2go was built using django
+21:01 < jtanx> if you've ever used that crappy website
+21:02 < jtanx> say for the fastcgi process we revert to
+21:02 < jtanx> /api/control?lock
+21:02 < jtanx> /api/control?unlock
+21:02 < jtanx> etc
+21:02 < jtanx> but /api/control is only visible to django
+21:02 < sam_moore> Ah, I see
+21:02 < sam_moore> Um...
+21:02 < jtanx> then django can query it
+21:02 < jtanx> and conditionally return the control key?
+21:03 < jtanx> i dunno
+21:03 < sam_moore> I'd be slightly nervous about adding additional systems that have to work together though
+21:03 < jtanx> yeah
+21:03 < jtanx> that's the problem
+21:03 < sam_moore> I mean, if it works, it's fine
+21:03 < sam_moore> If it breaks, suddenly anyone (or noone) can access the real underlying hardware
+21:03 < jtanx> Yeah
+21:04 < jtanx> especially if someone screws up the server config
+21:04 < sam_moore> I think I'd prefer to stick with the current login handler
+21:04 < sam_moore> There's some flexibility with how you actually do the authentication
+21:04 < jtanx> Sure
+21:06 < jtanx> I'm just thinking, how would we implement the 'admin' features
+21:06 < jtanx> you'd then have to have some sort of list distinguishing normal users from admins
+21:06 < jtanx> unless you hardcode admins?...
+21:07 < sam_moore> With LDAP you can store admin as a user field and check it
+21:08 < sam_moore> With /etc/shadow, have 2 files
+21:08 < sam_moore> One for admin, one for regular users
+21:08 < sam_moore> (When I say /etc/shadow I just mean the style of auth, not necessarily actually using *the* /etc/shadow)
+21:08 < sam_moore> In fact
+21:09 < sam_moore> We could possibly do a minimalist user management with python cgi and a custom /etc/shadow style file
+21:10 < jtanx> say what
+21:11 < jtanx> so use the python cgi to modify it
+21:11 < sam_moore> Yeah
+21:11 < jtanx> our c fastcgi to read
+21:11 < sam_moore> Yes
+21:11 < jtanx> that could work
+21:11 < jtanx> have a look at flask
+21:11 < sam_moore> It's also probably possible to easily do a lot of the things Adam wanted
+21:12 < jtanx> flask is like the simpler version of django
+21:12 < sam_moore> At least, you can get python cgi to send emails to people with a temporary password and ask them to change it
+21:12 < jtanx> i think I still have an example too
+21:15 < sam_moore> If you want and it doesn't require rewriting large parts of the FastCGI process
+21:15 < sam_moore> Personally I don't think I have the time
+21:16 < jtanx> well if it's completely separate from the fastcgi process
+21:16 < sam_moore> Sure
+21:17 < jtanx> hmm
+21:18 < sam_moore> Just a simple CGI script might do the job though
+21:18 < jtanx> yeah
+21:18 < jtanx> except nginx doesn't have normal cgi
+21:19 < sam_moore> Wat
+21:19 < jtanx> only fastcgi
+21:19 < sam_moore> Damn
+21:19 < sam_moore> And I guess apache2 only has normal cgi and not fastcgi?
+21:19 < jtanx> there may be mod_fastcgi
+21:19 < jtanx> but
+21:19 < jtanx> before we get ahead of ourselves
+21:20 < jtanx> okay no, nginx doesn't have fastcgi
+21:20 < jtanx> sorry cgi*
+21:20 < jtanx> we could do it in php
+21:21 < jtanx> urgh
+21:21 < sam_moore> urgh indeed...
+21:21 < sam_moore> I dunno
+21:22 < sam_moore> We *did* tell Adam that we wouldn
+21:22 < sam_moore> 't be able to do the user management system
+21:22 < jtanx> haha
+21:23 < sam_moore> I really think getting our program to interface with an LDAP server is reasonable
+21:23 < jtanx> yeah
+21:23 < sam_moore> Ok, I need to fix CITS3003 some more
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+22:53 < jtanx> brainspark: we can probably use django to proxy api requests
+22:53 < jtanx> so it goes like this: user <-> django <-> server api
+22:54 < jtanx> then you don't even have to expose the server api at all
+22:54 < jtanx> although if I ever end up trying this I don't know
+22:55 < jtanx> (by expose I mean that django can conditionally pass on the results from queries to the api)
+22:55 < jtanx> but yeah, it's probably best to leave it how it is right now
+22:55 < jtanx> as I doubt I have the time to implement this
+23:10 < jtanx> it would definitely add overhead too
+23:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Tue Oct 08 2013
+21:16 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Wed Oct 09 2013
+10:56 < jtanx_> welp the usb microscope arrived
+10:56 < jtanx_> it uses uvcvideo too
+12:00 < jtanx_> shit, we have to coordinate one report across the whole cohort
+12:02 < sam_moore> Yeah, shit
+12:03 < sam_moore> This unit has not been run very well
+12:03 < sam_moore> Except the tutorials
+12:06 < sam_moore> If I still cared I
+12:06 < sam_moore> d try and take charge of putting the report together
+12:07 < sam_moore> But I know that if no one else does it we'll all pass anyway since you can't fail an entire class
+12:07 < sam_moore> So terrible
+12:07 < sam_moore> We should just start writing a chapter on the software
+12:09 < sam_moore> I wonder if we could use the wiki format and export it as a pdf somehow
+12:11 < sam_moore> https://github.com/szmoore/MCTX3420/wiki/Hardware:-Pneumatics
+12:11 < sam_moore> Hilarious
+12:41 < jtanx_> ~.~
+12:41 < jtanx_> our final report will be the wiki!
+12:42 < jtanx_> made some progress on the camera
+12:42 < jtanx_> lowering the resolution to 352x288
+12:42 < jtanx_> and it will work with openc
+12:42 < jtanx_> opencv
+12:42 < jtanx_> ffmpeg's fine with 640x480 though
+12:42 < jtanx_> opencv just sucks
+12:57 < jtanx_> good 'ol stream.html
+13:05 < jtanx_> those fatal checks in sensor.c are bad
+13:05 < jtanx_> because half the time adc reads will fail and the whole program just crashes
+13:07 < jtanx_> oh right I saw your email, nevermind
+13:08 < jtanx_> I'm not getting the warnings that you're seeing either
+13:12 < sam_moore> Yeah, those warnings were actually on my laptop though, they don't seem to appear on the BeagleBone
+13:12 < sam_moore> I'm redoing the sensors code a fair bit
+13:12 < sam_moore> You'll probably hate it :P
+13:12 < sam_moore> Well, it's not really redoing the structure of how they work
+13:13 < sam_moore> Just separating the logic of how sensors get read from all that control loop stuf
+13:14 < sam_moore> I'm going to keep with the "one thread per sensor" idea, because that is definitely the simplest
+13:16 < sam_moore> Did you tell Omid that they shouldn't assume anything about the state of the GPIO pins before the software starts?
+13:16 < sam_moore> Which means that if (unlikely, but I don't know what they're doing) having two pins on at once would cause a catastrophic failure...
+13:16 < sam_moore> By murphy's law, it will almost certainly happen
+13:59 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+14:52 < jtanx> oh yah, somehow electronics ordered a non-powered usb hub
+14:52 < jtanx> I'm pretty sure we told them to get a powered usb hub...
+14:57 < sam_moore> Yep, and I remember them saying that is what they were going to get
+14:57 < sam_moore> Dammit, I'm stuck trying to pick the best name for something -_-
+14:57 < sam_moore> The worst place to be stuck
+15:19 < jtanx> ??
+15:19 < jtanx> thesaurus.com
+15:23 < sam_moore> Hahaha
+15:23 < sam_moore> I decided the thing didn't really need to exist
+15:23 < sam_moore> Problem solved
+15:24 < sam_moore> If someone who knows absolutely nothing about programming tries to add sensors to our program they will still be confused
+15:24 < jtanx> Hahaha
+15:24 < sam_moore> But I hope I've made it easier for someone who knows what they're doing
+15:24 < jtanx> Okay
+15:24 < jtanx> what were the compiler warnings that you got
+15:25 < sam_moore> pin_test.c:41:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
+15:25 < sam_moore> pin_test.c:48:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
+15:25 < sam_moore> More on lines 54, 128, 190,204
+15:25 < jtanx> weird
+15:25 < jtanx> I never saw any of those
+15:25 < sam_moore> Also I think the code I just wrote for the Strain sensors gives some as well
+15:25 < sam_moore> Yes, it does
+15:26 < jtanx> did you change GPIO_Export to use int type
+15:26 < jtanx> wait
+15:26 < jtanx> what am I saying
+15:26 < sam_moore> It already uses int type?
+15:26 < sam_moore> But it's something like that
+15:26 < sam_moore> It looks like you're using unsigned char for something
+15:27 < sam_moore> int gpio_num = Strain_To_GPIO(id);
+15:27 < sam_moore> GPIO_Export(gpio_num);
+15:27 < sam_moore> Is the sort of thing that causes the warning
+15:27 < sam_moore> But I have "bool GPIO_Export(int pin)" in bbb_pin.c
+15:27 < jtanx> oh right
+15:27 < sam_moore> So it makes no sense
+15:28 < jtanx> hmm
+15:29 < sam_moore> Ooh
+15:29 < sam_moore> It must be something to do with the "stub" functions
+15:29 < jtanx> Is this on compilation on the BBB
+15:29 < sam_moore> No, BBB was fine last time I checked
+15:29 < jtanx> okay,w ell I'm not getting any warnings
+15:29 < sam_moore> Compiling on my laptop because it's faster
+15:30 < sam_moore> #define GPIO_Export(pin) True_Stub((void*)pin)
+15:30 < sam_moore> That means the int is getting cast to a void*
+15:30 < jtanx> yeah on my computer it's not putting out any warnings
+15:30 < jtanx> int to void* is fine
+15:30 < jtanx> anything to void* is fine
+15:30 < jtanx> actually
+15:30 < jtanx> is your system 64 bit
+15:30 < sam_moore> 64 bit
+15:31 < jtanx> yeah
+15:31 < sam_moore> (You still have 32 bit :P)
+15:31 < jtanx> well that would explain it
+15:31 < sam_moore> Ok, it doesn't matter
+15:31 < sam_moore> The stub function doesn't actually do anything with the value
+15:31 < jtanx> cast int to int64 or whatever it is
+15:32 < sam_moore> That would cause warnings on the BBB though?
+15:32 < jtanx> only for the stub functions
+15:32 < jtanx> and only for 64 bit
+15:32 < jtanx> more ifdefs, yay
+15:32 < sam_moore> ...
+15:32 < jtanx> or we could get rid of the stubs
+15:32 < sam_moore> I'm just going to ignore the warnings
+15:32 < sam_moore> That could also work
+15:32 < sam_moore> It doesn't really matter
+15:32 < jtanx> and just do Wno-unsued-function or someting
+15:32 < jtanx> yeah, oh well
+15:35 < jtanx> One of the suggestions for the dilatometer was to just take a photo at the start and at the end
+15:35 < jtanx> then do comparison
+15:35 < sam_moore> Um, ok
+15:35 < sam_moore> If they just want 2 data points
+15:35 < jtanx> well
+15:35 < jtanx> if we can find something other than opencv
+15:36 < sam_moore> Ah
+15:36 < sam_moore> How slow is it?
+15:36 < jtanx> that may help, because right now opencv only plays nice with 352x288 or some other crap resolution
+15:36 < jtanx> it's not that it's slow
+15:36 < jtanx> is that it only works if the resolution is ~ 350 pixels x 2xx pixels
+15:37 < jtanx> ffmpeg is fine with 640x480 afaik
+15:37 < jtanx> it could probably do higher but haven't tested that
+15:38 < sam_moore> http://libccv.org/
+15:38 < sam_moore> Maybe
+15:39 < jtanx> or what if we framegrabbed with some external softare
+15:39 < jtanx> then used opencv to process the saved image
+15:39 < sam_moore> Yes, I was about to suggest that
+15:39 < sam_moore> I'm assuming the problem with OpenCV is that it doesn't like taking images from cameras directly of that resolution
+15:39 < sam_moore> And not some underlying problem with having large CvMats or something
+15:40 < jtanx> no idea why
+15:40 < jtanx> some obscure setting can probably fix it or something
+15:40 < jtanx> but I'm not about to trawl though opencv documentaiton now
+15:40 < sam_moore> Actually OpenCV works with my 640x480 webcam, so it's probably some low level arm specific problem
+15:40 < sam_moore> Which would probably mean that other image processing libraries would also suck
+15:40 < jtanx> it may be that too
+15:41 < jtanx> I know that with ffmpeg it was spitting warnings at 640x480
+15:41 < jtanx> like non-monotonically increasing timestamp
+15:41 < jtanx> and some other crap
+15:41 < jtanx> I was running guvcview though
+15:42 < jtanx> and it seemed to take 640x480 just fine
+15:42 < jtanx> it was quite slow with x-forwarding and all, but at least it worked
+15:44 < sam_moore> Hmm
+15:44 < sam_moore> I would be inclined to say that taking a bunch of data points at low resolution is probably more useful than taking 2 data points at high resolution
+15:45 < sam_moore> The best solution is to find some way of reading at the higher resolution though
+15:46 < sam_moore> ... I'm worried about what Kieran is going to produce if he writes this dilatometer algorithm
+15:46 < sam_moore> It's going to return an array isn't it...
+15:46 < sam_moore> I have no idea why
+15:47 < jtanx> :3
+15:47 < jtanx> brb ~5 mins while I relocate to a lecture theatre
+15:47 < sam_moore> Ok
+15:47 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+16:13 < sam_moore> Ok, this is both terrible and awesome
+16:13 < sam_moore> But I've written a test "sensor" that is essentially just an external program
+16:17 < sam_moore> So... if anyone complains about not being able to use python... they can use python
+16:17 < sam_moore> And they don't have to reinvent all of our FastCGI stuff
+16:17 < sam_moore> Although apparently that's easy in python anyway
+16:17 < sam_moore> It's the thought that counts
+16:21 < jtanx> :P
+16:21 < jtanx> flup
+16:30 < jtanx> http://zacharyvoase.com/2009/09/08/sendfile/
+16:30 < jtanx> this could be interesting
+16:31 < jtanx> replace static with our fastcgi app
+16:31 < jtanx> http://wiki.nginx.org/XSendfile
+18:07 < jtanx> mmm feature creep
+18:08 < sam_moore> Meh, it was better than dealing with that switch statement
+18:09 < jtanx> yeah
+18:09 < sam_moore> Also it made it really easy to decide where to put mutexes
+18:10 < sam_moore> Given that I would have had to write a "strain.c" and do about the same amount of work anyway, I think the solution is a good one
+18:10 < jtanx> it kind o makes sense though
+18:11 < jtanx> you can't particularly generalise that much to each sensor type
+18:11 < jtanx> so it makes sense to separate out based on what type of sensor it is
+18:11 < sam_moore> Yes
+18:11 < sam_moore> The Piped sensor is definitely feature creep though :P
+18:12 < jtanx> ^-^
+18:12 < sam_moore> Although...
+18:13 < sam_moore> If we wanted to distribute the sensors with a "master slave" system
+18:13 < sam_moore> The code would end up looking alot like that
+18:13 < sam_moore> Except with a network socket instead of a unix domain socket
+18:14 < sam_moore> Also I'm not sure why I called it piped given that it doesn't use a pipe
+18:14 < sam_moore> I suppose it sounds cooler than "uds"
+18:20 < jtanx> So with electronics
+18:20 < jtanx> the reason why they were having issues with getting the psu approved
+18:20 < jtanx> was because they wanted to cut the leads and solder directly to the board
+18:21 < jtanx> Oliver suggested that they use extension connectors
+18:21 < jtanx> and cut the lead on the extension
+18:21 < jtanx> but why they didn't think of that first, I don't know
+18:45 < jtanx> now to watch this week's lecture...
+21:31 -!- 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