bear24rw

RGB LED Coffee Table

2011-08-26T00:10:00.008-04:00

This summer all the Co-ops at Texas Instruments were challenged with coming up with a project centered around a value line MSP430. My group decided to build an RGB LED coffee table that pulsed visualization to music. We won 1st place!

A write up of the project can be found here

Theo Jansen Matlab Simulation

2010-08-11T22:01:00.016-04:00

My roommate had to do a simulation of a Jansen mechanism for his kinematics class. It sounded interesting so I gave it a try. Here is what I came up with:

Doing a simulation of a mechanical linkage was something I had never done, nor even really thought about. I initially tried to express all the angles as functions of each other but this soon became insane (this could very well be due to the fact that I am in Electrical Engineering and have never taken a kinematics course before so I had no idea what the proper equations would even look like). After trying to simplify gigantic trig equations in wolframalpha.com and getting back stuff that was disgustingly crazy I resorted to my middle school way of solving equations I don't really understand: brute force. (I used to make programs on my TI-83 to brute force single (and even double) variable equations way back in the day)

So there was only three things I really had values for: the length of the legs, the distance between the crank and the pivot, and the angle of the crank. So say the crank is at a certain angle and you know its length, you can find the end point x,y using simple sin and cos. Now the end of the crank (node 0) needs to be connected to node 1. Node 1 is a known length off the pivot, link_9. So basically what I do is rotate link_9 around the pivot until the distance between node 1 and node 0 are extremely close to the length of link_1. I find this really hard to explain still even after trying to do it many times. Basically I brute force the angle of a bar until the tip of the bar is a certain length away from the other bar it needs to connect to (the distance which I know, since I know the length of all the legs).

Even though this method is absolutely confusing to explain in words it is extremely modular and dead simple to implement. The code is basically the same thing over and over again just with different bars and also some angle constraints (you know link_9 will always be between 45 and 135, roughly). Adding new bars is as simple as copy and pasting and changing the names of the variables. I can literally make any mechanism this way without doing a single line of hard coded trig.

I found the paper linked below to be extremely helpful for providing good bar lengths. All the nodes and bars in my code are named the same as those in this paper
http://ujdigispace.uj.ac.za:8080/dspace/bitstream/10210/1738/39/Numerical.pdf

Edit: For some reason the link does not work, to find the paper google: "Numerical kinematic and kinetic analysis of a new class of twelve bar linkage for walking machines"

Quick And Dirty Security Camera

2010-08-11T18:52:00.014-04:00

When you're on the third floor of my house it's often nice to be able to see who is at the door when the doorbell rings. I wrote up this little program that takes a picture from a webcam every second and hosts the past five minutes of pictures on an apache server. The five minute limit was chosen purely because I only wanted to see who was at the door, not record a whole weeks worth and the fact that I wanted to store the pictures in ram and my server only has 1 GB.

A picture of my setup:

main.c

Compile with (note your library and include locations may be different):

So basically:


Make /tmp/cam
Init the camera
Start looping forever
Take a picture
Record the time
Save the picture
Wait for a second
Remove files older then 5 minutes

I have the process priority line commented out because when I had the niceness set at -20 it wouldn't run consistently every second. I didn't really play around with any other niceness' since the program only runs once a second and takes up 10 percent cpu for a brief moment.

The php script just loops through all files in /tmp/cam and just spits them to the screen. list.php just shows all the files in a line. index.php loads list.php in an iframe. When you click on a picture in the list it reloads index.php with the selected picture full scale.

This method has a serious flaw in that loading 300 or so pictures in one go is not quick task (even with /tmp mounted in ram), but it is fast enough for the purpose it serves.

To get the images from /tmp/cam to the apache root directory I simply made a symlink called images which points to /tmp/cam

index.php

list.php

Omegle.com Man In The Middle Attack

2009-11-14T16:48:00.024-05:00

The other day my friend showed me this site Omegle. It's a pretty cool site that anonymously pairs you up with a 'stranger' and you chat 1 on 1 with the ability to disconnect and find a new 'stranger' at any time. It's surprisingly addicting and fun. It claims to be completely anonymous and so to check this I decided to fire up Wireshark and take a look at what information was getting passed to the server. I was surprised to find the method of communication extremely simple and completely unencrypted. When you connect to a person the process looks like this:


You: POST omegle.com/start
Omg: HTTP "123456"             <-- random 6 digit 'username' (a-z A-Z 0-9 _ -)
You: POST omegle.com/events?id=123456
Omg: HTTP [["connected"]]
You: POST omegle.com/send?msg=hello&id=123456
Omg: HTTP win                  <-- funny
You: POST omegle.com/events?id=123456
Omg: HTTP [["gotMessage", "hey"]]     <-- message from other person
...
You: POST omegle.com/disconnect?id=123456 <-- quit the chat

Seeing this immediately sparked some thought. Can I request events for other users? Can I send messages to other users? Can I disconnect other users? It seemed all you needed to do was post the command with the user id you wanted to receive events for. As it turns out its almost even better. If you post for events using someone elses user id it will "implode" their chat:

Whats better is that the other person is still connected and they have no idea that their 'stranger' has been imploded. Now you can keep talking to the other person and they have no idea what just happened.

There is one major problem with this however. According to:

http://omegle.com/count

there are on average only about 3k users online at a given time, but the number of possible user ids are

(26+26+10+1+1)^6 = 68,719,476,736

That is a terrible chance of you finding someone quickly. I actually started making a brute forcer (omegle_brute_force.py) but quickly realized that this was an ill fated attempted.

So if you cant find the users, why not have the users come to you? I realized that Omegle would be prime for a classic man in the middle attack. The idea is super simple. I would connect to two strangers just like normal, but instead of me talking to them they would talk to each other through me. As long as I don't inject any messages or anything weird they should have no idea that I'm even there. Here is how the program looks:

As you can see I am having a legit connection to both client 1 and client 2, but I am transparently passing their messages right through me to the other person.

Doing this was kinda tricky. Whenever you POST for events it blocks until the read is fulfilled. This means that with a single threaded program each person would have to take turns talking since the program would block every time I polled for their messages. Even most two threaded setups have the same problem. The solution I came up with I feel works pretty well. There are four total threads:

1) Sending to client 1
2) Receiving from client 1
3) Sending to client 2
4) Receiving from client 2

Every time the receive thread gets a message it queues it into a stack, so that the sending thread can retrieve the message at its leisure. The result? It doesn't matter if a POST blocks because the sender thread can still work through the queue and the other threads can still send and receive messages.

A classic man in the middle attack:

This has some interesting possibilities. I can send messages to one of the clients at the others behalf and the person will have no idea that I sent it. Also what about connecting more then 2 people together? There is no reason I couldn't connect multiple people together in a chat and maybe even append a user tag to each of their messages.

Omegle is a pretty interesting site, and you gotta hand it to Leif K-Brooks for (apparently) single handedly making such a propular site at only 18. I hope that he can implement some needed security to Omegle to prevent this kind of attack in the future.

Download my programs here [mirror].

omegle_man_in_middle.py - program described above
omegle_brute_force.py - attempts to guess user ids and post for events
omegle_class.py - generic class for interacting with omegle
omegle_connect_view.py - connect to omegle and posts for events
omegle_multi_connect.py - connects to multiple people at once. proof of concept that multi connections can be made
omegle_send.py - send messages using a user id

EDIT:

Found another omegle man in the middle attack written in perl [here]

PS3 Eye Driver Patch

2009-11-08T17:54:00.046-05:00

Update: A lot has happened since this was posted. The main line kernel now includes most of these fixes!

I've had a PS3 Eye lying around for a while but I hadn't gotten around to using it because when it first came out there were no drivers for it so it sat in my closet for almost a year. I decided to check out the current state of the PS3 Eye in Linux and was happy to find that there is now support in the 2.6.31 kernel.

What I was disappointed to find out though was that there was no ability to select frame rate or control a lot of the image quality. Lucky there is patch that allows selection of frames rates all the way up to 125 fps and some image quality controls. I patched my driver and tried it out but found that the color of the image was way off and none of the given controls could fix this.

I decided to do some research and add support for brightness, contrast, hue, and auto white balance.

With Kaswy's Patch

With my patch

I'm going to just supply the whole .c file instead of a patch since they are almost the same size. Applying the patch is almost the same as Kaswy's

To apply:

Install necessary packages:


$ sudo apt-get install kernel-package libncurses5-dev wget bzip2 build-essential linux-source

Extract kernel source code:


$ sudo su

$ cd /usr/src

$ tar --bzip2 -xvf linux-source-2.6.(your version).tar.bz2

$ ln -s linux-source-2.6.(your version) linux

Replace driver:


$ cd linux

$ wget ucfilespace.uc.edu/~thrunml/ov534.c

$ rm drivers/media/video/gspca/ov534.c

$ mv ov534.c drivers/media/video/gspca/

Recompile driver:


$ cp /usr/src/linux-headers-$(uname -r)/Module.symvers /usr/src/linux

$ make oldconfig

$ make modules_prepare

$ make SUBDIRS=drivers/media/video/gspca modules

Install new driver:


$ cp drivers/media/video/gspca/gspca_ov534.ko /lib/modules/$(uname -r)/kernel/drivers/media/video/gspca

$ depmod

Check to make sure it installed:


$ modinfo gspca-ov534

filename:       /lib/modules/2.6.31-14-generic/kernel/drivers/media/video/gspca/gspca_ov534.ko

license:        GPL

description:    GSPCA/OV534 USB Camera Driver(kaswy mod for MT use V0.5 / bear24rw patch V0.1)

author:         Antonio Ospite 

srcversion:     1F87820D2B0705822B61A16

alias:          usb:v1415p2000d*dc*dsc*dp*ic*isc*ip*

depends:        gspca_main

vermagic:       2.6.31.4 SMP mod_unload modversions 

parm:           videomode: = xx //Set the videomode(see doc) (int)

parm:           autogain: = [0|1] //Autogain (agc,aec,awb) (bool)

parm:           gain: = [0..63] //main gain (int)

parm:           awb: = [0|1] //Auto White Balance (bool)

parm:           exposure: = [0..255] //Exposure (int)

parm:           brightness: = [0..255] //Brightness (int)

parm:           contrast: = [0..255] //Contrast (int)

parm:           redblc: = [0..255] //Red Balance (int)

parm:           blueblc: = [0..255] //Blue Balance (int)

parm:           hue: = [0..255] //Hue (int)

parm:           sharpness: = [0..63] //Sharpness (int)

parm:           vflip: = [0|1] //Vertical flip (bool)

parm:           hflip: = [0|1] //Horizontal mirror (bool)

Now we can remove the one currently in use and load our new one:


$ modprobe -r gspca-ov534

$ modprobe gspca-ov534 videomode=10

The available video modes are:


00: 640x480@15

01: 640x480@30

02: 640x480@40

03: 640x480@50

04: 640x480@60

10: 320x240@30

11: 320x240@40

12: 320x240@50

13: 320x240@60

14: 320x240@75

15: 320x240@100

16: 320x240@125

You can adjust the image using guvcview


$ sudo apt-get install guvcview

$ guvcview

Hopefully the main line driver gets patched soon with these enhancements.

LED Matrix

2009-10-01T12:36:00.034-04:00

Last year in one of my classes we were required to make an 'artefact' or something that reflects the interests of the class. Most people make posters and the past two quarters that's what my class did too. Posters however are static, usually boring, and don't reflect that fact that everyone in the class is an EE major. We decided posters are for noobs and decided to go off the wall a little and make an LED matrix display. Lucky one of my friends John Wathen already had this beautiful 16x24 Green SMD LED matrix that he built back in high school.

What we didn't have however was a driver for it. The driver we choose to design was highly inspired from this one. The basic idea is that you use shift registers to sink the columns and a line driver of some sort to source the rows (we chose to use a Darlington array).

There where a lot of changes from the Instructables design that that we had to make however. The matrix in the Instructables was a lot smaller than ours and used 8 IO lines to drive each row. Since our matrix has 16 rows this was completely infeasible using just an ATMega168. To solve this issue we choose to use a 4:16 de-mux to control all sixteen rows with only 4 IO pins. The de-mux combined with two 8 channel Darlington arrays provided the perfect interface to control all 16 rows. To sink the columns we choose to string three 8 Output shift registers. Each shift register is rated to handle the current of the 8 LEDs that could possibly be on at one time.

Some other features that we included on the driver board were 3 green LEDs, 3 push buttons, ISP header, TTL header. When all was said and done we ended up the the schematic shown below.

I know, you are probably looking at that and thinking, "Why are all the shift register outputs criss-crossed??". The reason for doing this is because the output pins on the chip are not exactly in a row so to assist in board layout the pins had to be crossed and mixed up so that the board layout would be nice. It's much easier to change the order of the columns in the program then it is on the board layout (in my opinion). We didn't want to etch a double sided board so a lot of effort went into laying as much of the circuit out on a single side. There were a few paths that could not be routed and were just jumped with wire (you'll see in picture below).

Notice how there are a bunch of air-wires (yellow lines) that I couldn't figure out how to route, they are manually jumped when the board is put together.

To etch the board we printed out the board layout 1:1 scale on glossy photo paper, it was than ironed onto a piece of copper clad. The idea is that the toner will stick to the copper clad and when the board is dipped in acid the acid will eat away at everything but the traces, since they are coved by the toner. I'm definitely not an expert in this area so ask John Wathen more about the process, he is basically a pro.

Etching the board in acid

Checking to see if its ready to be scrubbed

Dirty traces

Scrubbing off the rest of the toner

The beautiful result, nice and shiny
Now, let me just tell you that we did this in a public bathroom at school. So there were three guys in a bathroom with latex gloves, a camera, and tub of some green liquid. Trust me we got some weird looks.

The next step was to drill all the holes. I don't remember exactly how many there were (John might) but there were a lot.

After all the holes were drilled John soldered it all up.

And the result!

Now that the board was finished it was the moment of truth.

Adam Steele lent me his programmer. Plugged it into my Xbuntu box, apt-get installed the avr tool-kit and the programmer was immediately recognized (NICE!). Flashed a simple program to flash the status LEDs and low and behold, IT WORKED! Next up, everything else. I started by modifying the program that the Intructables provided but quickly got frustrated by the way it worked. It treated each column as a bit in a byte and the rows as a byte, this made it extremely hard to visualize outputs to the display. Also I was using a de-mux and had 24 columns which the code did not easy support. So what do you do in this situation? REWRITE.

An outline of how the new code works:

The value for each pixel is stored in a 2D array 16x24, want to set the top left pixel? buffer[0][0] = 1; simple as that, much easier than dealing with it as an array of bytes. Okay, so it takes up more memory but IMO it is completely worth every bit (pun intended).

The code starts by initializing the ports (pull-ups, in/out, etc) then it initializes timer1. To be completely honest the fill value for the timer was chosen by adjusting value, flashing, seeing if the refresh rate was noticeable. We ended up with OCR1A = 0x012C; as a good value.

The code then falls into an While(1) where it sequentially calls functions to draw stuff on the screen, for example:

All the high level functions (tunnel, spiral, shift, etc..) write to 'buffer'. When the timer interrupt goes off it calls the function shift_int() which reorders the columns into 'buffer_2' and then shifts them out to the shift registers. It then calls shift_mux() which jumps to the next row. So essentially we have a double buffered display.

Once all the low level code was done it was all fun and games. It was really nice being at the point were all you had to work with is a 2D array. We ended up with the high level functions:

It is so incredibly easy to make new functions when you are just manipulating a 2D array.

A warning before you watch the videos, they were taken with a crappy point n shoot camera so they look incredibly choppy. In real life the display is incredibly fluid and smooth. The videos do it zero justice.

Eagle Files & Source Code [Mirror]
If you re-use the design or source (which I encourage you to do) please give credit where credit is due. Also note that the entire code was literally written in a one night programming marathon since we were extremely pressed (read: it was due the next day), so there are still many bugs. Also I take no responsibility for any damage if you use my design and code (had to put a disclaimer ;))

Any questions regarding the design or the source code should be directed at me bear24rw . gmail.com
Any questions regarding the construction of the board should be directed at John Wathen jmwathen . gmail.com

RFID Door Unlocker

2008-12-26T13:08:00.008-05:00

Todays world is all about efficiency, this includes getting into your dorm room. Inspired by other door unlocking projects found around the Internet, especially the MIT one that is practically famous, I decided it was time to outfit my own door with an RFID unlocker.

Our dorms offer the unique benefit of having full length mirrors on the doors so I figured that suction cups would be the best way to go as they were easy to apply, remove and are non marking.

Being that I already had a Basic Stamp, Parallax's RFID reader seemed to be the obvious choice as it was the cheapest reader I could find and already had example code written for it.

My initial plan involved just a servo, standoffs, and suction cups...

Modeled in Autodesk Inventor...

After some of the parts came in I set up a quick prototype to make sure the servo was even strong enough to flip the latch and that I could read the tag through the door. To attach the servo horn to the latch I tied a piece of string to the horn and taped it to the top of the latch, this is how it done in the final version as well. The reason for using string is so that you could still easily unlock the door with the key, it would just put slack in the string. The only fault with this method is that you cannot use the RFID tag to lock the door.

I quickly realized that I had given no thought as to how I was going to mount all the electronics. As a result the servo remained like that on my door for weeks. As I was cleaning my desk one day I found this box and instantly realized that it was perfect for the door unlocker.

Another quick mockup in Invetor to see if everything fit, and it did perectly..

Ordered some 6-32 screws and nuts from McMaster and started assembly.

The servo fits perfectly height wise, it sits against the bottom of the base when closed. Now that I had the servo and RFID reader mounted I needed to get some holes drilled for the suction cups and basic stamp. Due to my ~~procrastination~~ studying the project sat on my desk for a week.

I finally got around to drilling the holes and mounting the whole thing...

I used paper under the basic stamp to insulate it from the metal box.

The assembly did not go without problems, however.

The first major problem was when I went to reassemble the box after I put on the suction cups. I didn't take into consideration that the nuts would get in the way of the box closing. As you can see in the pictures I had to snip spaces in the box where the nuts were so the box would be able to close all the way.

The second major problem was a weird one. The RFID reader was originally going to be mounted on the inside of the box. This box was perfect because the front was plastic and didn't interfere with the reader. The problem was, when I closed everything up in the box the range of the reader was almost cut in half and I couldn't read the tag through the door. However, if I pulled the box apart (like it is being shown in the above pictures) the tag could be read through the door. My best guess is electrical noise is causing this but I honestly did not want to spend any longer on this project, and there seemed little alternatives. I ended up just mounting the reader on the outside of the box. It does not really make any difference other then looks.Here is how it looks when it is all up and running.

The basic stamp program can be downloaded here