Monday, September 7, 2015
Saturday, March 2, 2013
I found that our Samsung BN59-00857A remote worked fine with an existing lircd.conf configuration file for the BN59-00856A. (Actually the 00856 includes a few additional buttons not on the 00857; several of these work for controlling our TV even though they're not on our OEM remote!)
When it came to controlling our GE air conditioner, I didn't find any existing configuration file. The process of getting a working config file together was a little more involved than I expected, so I'm detailing it here and posting the resulting config (also sent it to the LIRC maintainers, but didn't hear anything back).
I knew from running mode2 that raw signals from the AC remote were being received correctly. But I wasn't able to get irrecord to pick up the AC remote signals even when forcing it into raw mode. It turns out that the GE AC remote has an unusually long code length, 48 bits, so maybe that was part of the issue. I'm also not clear on whether my irrecord was going into raw mode correctly; seemed to behave exactly like non-raw mode so maybe there's a problem with the version built for Raspbian?
Anyway, to get a config file, I had to pipe the mode2 raw data to text files and then manually pull the text into a raw conf file and filter out the "pulse" and "space" text (thanks vim). I confirmed that the resulting raw file works for controlling the AC through LIRC. Then I used irrecord -a to retroactively convert the raw codes into a more succinct config file. Looking at the various wall mount ACs GE sells, it seems likely to me that these codes will work for any unit since the controls all look the same. (If you have a heat+cool unit then you'll be missing the "heat" button since my AC doesn't have that.)
Hope it's useful. If you want the raw version of the conf file for some reason, just ping me for it.
# this config file was automatically generated # using lirc-0.9.0-pre1(emulation) on Sat Mar 2 14:09:22 2013 # # contributed by Peter Li # # brand: GE # model no. of remote control: # devices being controlled by this remote: All the GE wall mount air # conditioners look like they have very similar controls, so I would guess this # will work for all. It will probably also work for the Heat/Cool wall models, # other than the missing heat button, but I haven't tried that. # begin remote name GE_AirConditioner bits 48 flags SPACE_ENC eps 30 aeps 100 header 3388 1678 one 430 1257 zero 430 412 ptrail 428 gap 40991 toggle_bit_mask 0x0 begin codes on_stop 0x555AF308598F cool 0x555AF3081D8F fan 0x555AF3085D8B tempup 0x555AF308D987 tempdown 0x555AF308198B timeron 0x555AF308D58B timeroff 0x555AF308958F hi 0x555AF308DD83 mid 0x555AF3083D8D low 0x555AF308BD85 sleep 0x555AF3085583 end codes end remote
Monday, January 21, 2013
Tuesday, January 15, 2013
Saturday, July 28, 2012
Managed to get a pretty decent locating fit for a 3/8" x 5/8" x 5/32" sealed, pre-lubricated ball bearing from VXB. They have a lot of options in this size. I ordered two to choose from, but only one fit into the printed flange piece easily with just my hand pressure even though they were rated for the same maximum OD and tolerance. So I think the current design is close to the edge of hand pressed fitting for the low tolerance of the current SLS 3D printing process.
If you look carefully at the bottom edge of the flange where it contacts the drill adapter, you can see there is a step-wise pattern; this is because I tried to give the surface that contacts the drill adapter a gentle slope to match the slope on the front surface of the drill adapter. It basically works, but the 3D printing leaves this step pattern instead of a smooth slope. Probably not worth the trouble.
Here's the whole thing assembled. Note that the square driver piece is taking on a healthy coffee color due to the plastic material being porous and absorbing bits of coffee grounds. I've had this piece a while now and it's showing no signs of failing, so I think the 3D printed parts are reasonably successful for medium use. It's also kind of nice to know that the plastic part will fail before you kill the KitchenAid motor if you happen to jam things up some how.
Here's a picture of the extra 5/8" OD bearing I bought that didn't quite fit nicely. I also bought a 9/16" OD needle bearing to try, but it seemed better to stick to something with less depth and the 5/8" OD ball bearing was a small enough OD to work.
Sunday, May 20, 2012
Update 2: It seemed like a Wiki was actually more appropriate, so I am retiring the Google Group in favor of a new Wikia page. Please join in!
Update: I created a Kitchenaid DIY Google Group to try to get together some of the handful of people who have been hacking on this. Also posted a listing of known projects.
Substantial updates to the earlier prototype. Here I've added an adapter flange that holds it in place against the Kitchenaid adapter hub. This was also supposed to house a sleeve bearing but I made the dimensions too tight so that will have to wait for next iteration. Also I found some nice, small, cheap, sealed ball bearings from VXB so will probably design for that instead. The coupling between the square hub and the 3/8" drill shaft is essentially the same as before, only shorter to leave room for the flange.
Here's a video of this version in action. Note that now I'm using it to drive the older Hario conical burr grinder model, rather than the Hario Slim. (We have both, one for home and one for my office. Kitchenaid only at home though ;).)
One advantage of the older Hario is that the coupling from the drill adapter to the grinder is simpler. The Hario Slim uses a pentagonal (AKA 5-point) drive in a small nonstandard size (~3/16"). I tried a 3D printed adapter for that but I don't think the Shapeways "Strong, Flexible" material is strong enough. I'm trying a lasercut acrylic piece next.
For the older Hario, the situation is much simpler. The drive has a nonstandard shape (cylindrical with flats on two opposite sides) for hand cranking, but it's also threaded as M6-1 so you can just screw something down on top of it. Actually, you can even just clamp the drill adapter directly down on this, as jeffkobi did in his original design. I wanted to try something simple and off-the-shelf to avoid clamping directly to the grinder, so I looked for M6-1 coupling nuts that would fit into the 3/8" drill adapter, but unfortunately they are all slightly too large. However, a 1/4-20 coupling nut fits snugly into the adapter (you may have to test a few to find one with clearance) and screws smoothly onto the grinder drive for the first few turns. I don't have any MechE, so can't really tell you the relative benefit of either clamping directly to the drive or screwing an unmatched thread onto it, but as long as I include some washers so that the 1/4-20 is only riding the M6 threads a little way I think this might be a little nicer. An M6@1/4-20 adapter nut or just an M6 with a smaller outer diameter would be ideal but I haven't found such a product.
The previous hub coupling has already worn out, so it's still not clear whether these 3D printed parts are viable. The first thing to go was the set screw holes; on the failed piece the screws get pushed back through their threads so the coupling no longer grips the 3/8" shaft. But I think the mistake there was to tap the holes and use nylon set screws before switching to steel set screws. On the new piece I just screwed steel set screws through the untapped hole so the fit is tighter and it seems to be holding up better so far. Probably a clamping adapter design would be better, although it would be a tight fit and I'm not sure how well 3D printed plastic would handle that kind of stress.
Sunday, April 15, 2012
Update: here's a video of it in action with the drill adapter clamped directly onto a Hario Slim Burr Grinder. Actually works pretty well as is, so I will put the piece on Thingiverse soon. Lots of refinements planned though.
A while back I had a brief flirtation with the idea of DIY Kitchenaid attachments, but never really got going on the project. Then recently, jeffkobi posted a nice Instructable on how to attach a Kyocera manual burr coffee grinder to your Kitchenaid and it rekindled my interest (not least because I own the same model burr grinder).
I really liked jeffkobi's idea of using an inexpensive Milescraft 90 degree drill adapter as the intermediary between the mixer and the grinder. So I've been trying to develop some simple 3D printable pieces to make it easier to couple the drill adapter to the Kitchenaid attachment hub. This is a work in progress and is going to take at least one more iteration to refine, but I'm pretty happy with how it looks so far, so here's some teasers.
Thursday, March 15, 2012
Friday, September 2, 2011
Building multithreaded Matlab mex files with Theron
This was pretty straightforward on the Mac, somewhat tricky but not terrible on Linux. I don't have any working C++ compiler with Matlab on Windows thanks to absolutely abysmal support from Microsoft and Mathworks (essentially Mathworks only supports Microsoft and Microsoft's compilers are impossible to get installed correctly). But the notes below may help you get things working on Windows anyway and I added some Windows specific notes at the very bottom. Before trying to get Theron working, I encourage you to write a simple C++ mex program (maybe a single-threaded version of your planned algorithm) and get it built on Matlab first, to confirm that your system is correctly set up for mex.
I'm fairly confident most Mac users can get this working. On Linux I have only tested on 2010 and 2011 64-bit versions of Matlab, and there are reasons to fear that earlier versions may have more trouble working. Fair warning.
Preamble: What follows are my (long-winded) musings on the current (Sep. 2011) state of concurrent programming in Matlab. For a specific guide to using the Theron C++ library for Actors concurrency in Matlab, see the following post.
Matlab is a standard programming environment for scientific calculations. In our lab, we use it for a lot of analysis, especially prototyping new analyses. Eventually, some of the performance critical stuff gets ported over to Java, but we still have plenty of things we need to run that are Matlab-only and need to be fast.
As personal computers add more and more cores without improving clock speeds much, there is more and more need for parallelized (AKA concurrent, multithreaded) software. Matlab is not a very popular language for supercomputing, but high-performance clusters also of course demand parallelized software. Matlab has some support for multithreading internally, so depending on which Matlab internal functions you use, you may see significant multicore use on your machine. But there is currently no support for explicitly writing multithreaded programs in vanilla Matlab.