Pictures that were promised earlier

Saturday 23 January 2010 at 9:11 pm (for those not following, my RTL8187 wireless card came with these:)

Something else for a change - RTL8187 USB devices in Kismet on OS X

Saturday 23 January 2010 at 8:56 pm Firstly, the StackBook project is no further than it was. StackOS needs a rewrite to make it behave better (you learn how to do these things after it's too late). I still haven't found a suitable hinge either... must get to that.

Anyway, I decided to get my hands on a RTL8187 USB card and a "9"dbi antenna (9 is in quotes because I know a manufacturer who makes a similar one, and they claim it is a 7) to go with it. Entertainingly, this card comes with a pressed BackTrack 3 CD... and Chinese instructions for such. I will post some pictures later. Pictures are here.

The card works fine with the RTL8187 drivers in KisMac. And it works with Kismet on Debian running on my EEE 701SD. Kismet on OS X, however, does not support this device. To fix that, I have created rtl8187_tuntap. This is a daemon that drives the USB card using KisMac's userspace USB driver framework, and passes the packets out over a tap interface.

At the moment it uses IOKit to talk to the card over USB. It should theoretically be possible to port it to use libusb and make it crossplatform (the ObjC code doesnt do anything particularly nonportable - and the CoreFoundation stuff could be replaced). On Linux, this is not terribly useful, as there already exists monitor mode drivers for these cards. But on Windows, the possibility is there. Yes, you heard me - monitor mode on Windows - but it is not a high priority. Go and install Linux.

To get it to run, build it with XCode, and ensure the UsbVendorsRTL8187.plist file is in with the built binary. It's in the Build/Debug folder. Cd into the directory and run it as root (sudo ./rtl8187tuntap).

If you don't have the OS X tun/tap installed, install it.

If all goes right, you should see an iteration of all your USB devices, and then:

2010-01-23 20:32:11.167 rtl8187tuntap[2050:e07] Start capture
2010-01-23 20:32:14.751 rtl8187tuntap[2050:e07] Capture started
2010-01-23 20:32:14.893 rtl8187tuntap[2050:e07] Now recieving frames


At this point, it then is reading packets and reporting them out via tap0.

Now for the Kismet side: You need at least revision 3010 of the SVN development sources. Compile and configure it with the source interface tap0 (it will autodetect the source type).

To Do

• Why doesn't signal strength work? It is being reported in the header...


• Write as a Kismet plugin.


• Implement channel hopping - at the moment you can change channel by writing a number to /tmp/rtl8187_channel - and i suggest using cat > not echo as the pipe can only be opened once (must fix that). This will come with it being a kismet plugin.


• Clean up the log outputs...


• Tun/Tap on Mac OS X does not have an option to change the DLT (data link type) - and as a result no other software besides Kismet will behave right because it is told that the header format is a standard ethernet packet. I am told that Dragorn attempted to correct this, but the developers were not interested.

Now for the important bit: Download rtl8187tuntap v4.

Any bugs etc - leave me a comment.

StackBook Part 8 - Keyboard

Wednesday 30 September 2009 at 01:01 am

After a lot of point-to-point soldering on both boards, I have the main LCD working on the soldered StackBook board. That is - after finding the hanging wire :)

After coding a basic shell and an IRC client...



(sorry for the short posts, there'll be more later).

StackBook Part 7 - Keyboard

Wednesday 30 September 2009 at 12:55 am (this post is disproportionately short for the amount of time this took)

Ok, so after soldering a 4-pin connector onto the Stackbook's board, I interfaced a PS/2 keyboard to it.

The keyboard was this one from DealExtreme.



So let's open it up...



After this, I stripped it down and replaced the PS/2 connector with an IDC header.

A PS/2 driver was written using an interrupt pin for the clock, however, for some reason it didn't behave right - much much messing around was had with this.

Using a combination of:
http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF and
http://code.google.com/p/ps2keypolled/source/browse/trunk/ps2keypolled.c

a polling-based driver was written instead.

.

StackBook Part 6 - Ethernet

Monday 07 September 2009 at 8:31 pm I got about half way through soldering a small bit of board to the bottom of the graphical LCD so I could plug a 16-pin header in it (I wasn't in the mood for extensive point-to-point soldering...).

So instead I tried something easier - the ethernet module. I soldered up the SPI pins, and plugged the ethernet module into the board... but I couldn't seem to make it behave. Initially I had the module's chip select tied high, but still no luck. The module would come up, and the computer would recognise the ethernet cable as plugged in, but it wasn't showing up at that IP - or generating any traffic. So I wired it to the AVR's CS line - I figured the AVR may have a problem with not being able to see that something is on the CS line.

Sometimes after programming, lights would come on, sometimes it wouldn't - and after replugging the power cable it'd come sometimes as well. But I still couldn't send any traffic. Anyway, I read somewhere else that this arrangement sometimes does not produce a long enough reset pulse for the ethernet module and that it should be connected to a normal pin. So I put it on one, and pulled the line low for 10ms upon startup (much longer than necessary). The module then had lights every time it was turned on, which was a bit better than before. But still no data.

I decided to look through the header files, and eventually found spi.h in the Utility folder of the ethernet library... apparently using the hardware SPI does require setting pins. A few changes later, and it worked!

A bit more messing round, and I had this going:



Ethernet controlled character LCD :D

Now I just need to wire up the GLCD board, and once the keyboard arrives, get some IRC'ing going :D

Tip - Data recovery from a disk image

Wednesday 02 September 2009 at 9:46 pm If you have a disk image of a corrupted drive that you're trying to recover from, you may find when you double-click it, it won't mount due to filesystem corruption. It is then detached from the /dev node it had because of this, and you can't use it. But suppose you want to use something like Prosoft Engineering's Data Rescue II on it.

If you attempt to use hdiutil to attach it from Terminal, this is what you get:

$ hdiutil attach Macintosh\ HD.dmg
hdiutil: attach failed - no mountable file systems

The right way to do this is this - the "nomount" option stops it from attempting to mount, so instead it just attaches and doesn't fail.

$ hdiutil attach -readonly -nomount Macintosh\ HD.dmg
/dev/disk2

(-readonly is not required but may be useful).

Now you can recover from it.

StackBook Part 5 - Power Supply

Tuesday 01 September 2009 at 10:36 pm I'm going to need 3.3v for the ethernet module, so I may as well build the power supply.



It's a rather simple design - two low-drop-out linear regulators - a LM3940IT-3.3 and a LM2940CT-5.0. Essentially, the voltage comes in via the DC socket, or terminal block, and is dropped down to 5v by the LM2940. The 3.3v regulator is then powered off the 5v regulator to provide 3.3v. This is done because the 3.3v regulator can only handle 7.5v on it's input terminals as an absolute maximum, but the 5v regulator is rated up to 26v - otherwise this would exclude powering it from standard 12v sources. Since the 3.3v regulator is a low drop out regulator, it can provide 3.3v with Vin down to 4.5v.

Yes, the board is upside down because I initially thought it would go on the left, forgetting the layout of the board.

No, that battery pack is not the final design. It's just the closest DC source with a 2.1mm plug (I need to find where the ends of my plugpacks all went - I have a quite suitable switchmode 3/4.5/5/6/7v plugpack which should supply quite nicely at 6v.

Next up is I guess getting the graphical LCD onto this board (you can see the 16-pin connector at the top there - that is the start of it).

StackBook Update

Monday 31 August 2009 at 9:05 pm Alright, a quick update on where the StackBook is at.

The Screen:
Have cut up the tracks on a small piece of protoboard that I still need to cut down to the right size. This will adapt the screen to two 10-pin headers (power/control lines, data lines). Need to also add the two more headers to the main board.

The main board:
Add (a socket for a) crystal oscillator already!

The Ethernet module:
I have the 3.3v regulator and I've taken another look at the pinout. I need some pin headers here to socket this thing in - I don't want to solder it down. Jaycar doesn't have them, apparently Aztronics do, but I have to get out there some time.

The Keyboard:
Spent 15 minutes searching the web, then found that my usual supplier of stuff from Hong Kong has this, so I ordered it. Should be OK once I remove the case - by the dimensions looks fullsize, but I can of course make the laptop shorter. Don't want to make it too small though - and i should leave enough room to fit some interesting stuff in. Just wish I could make it a little smaller as the screen is not huge. Oh well, guess I'll have to figure something.

The case
Probably perspex. Need to find some laptop screen hinges somewhere.

Power:
Hmmm. At the moment, it's using USB power through a 10-pin ISP socket. Should add a DC jack with a LM7805LD (I've got one somewhere here...), and feed 6v into it. Need to at some point get a 5v boost converter and make this thing run off 18650s... and work out charging etc. One of the A-D pins (spare from the LCD) can be connected to the raw battery input to get the voltage (which since it is lower than Vin is fine) for battery metering.

Sockets:
Probably 10-pin ISP headers (for both chips), power, a serial port, ethernet, and maybe a "misc port" with some wires / I2C bus on it. First person to suggest IEC bus gets something thrown at them :)

Other stuff
Needs a stupidly loud buzzer. Or rather, doesn't. Though it will be getting more LEDs - and I probably should move the blue power one when I have a keyboard.
Also, soft poweron... I wonder how low power I can make the AVR...

Video Converters

Thursday 27 August 2009 at 10:40 pm ... or how to get a C64 onto a 22" monitor.



I bought this video to VGA converter from DealExtreme for usage with the C64. In short, it works quite well - there's not much visible flickering, everything looks alright. No rolling picture or other horrible problems caused by the C64's video output rate. Only issue is there is some interlacing on the image - but I haven't found this to be a problem in gameplay, it's only slightly evident in text mode.

There is a bit of colour fringing though - quite bad in the blue area - but I'm not incredibly sure to what extent it is just the C64's video output hardware making a messy signal - as there is some similar fringing on a TV. As I said before - many corners were cut in the C64's video hardware.



Compare that to the iREZ ReelEyes video capture card image, which seems to have a little less, but still some fringing...



I'd say that this thing's worth the money though.

Edit: Probably should clarify about the colour fringing: it only happens when dark colours and bright colours are right next to each other. In the blue texture there's alternating blue and black lines for dithering and that sets it off badly - this is a worst case scenario. Normally you don't see it (look at the light tile area) - but this sets it off badly. I'll take more pictures later.

StackBook Part 4.1 - More More screen.

Tuesday 25 August 2009 at 10:55 pm Rule #2 of electronics according to gm: Just because it works (or appears to) doesn't mean it's right.

I was experiencing problems with the third segment of the display - namely anything drawn on it going onto the other two and general pixel corruption caused by the third panel not being activated in the correct sequence. Remember last time, when CS1 and CS2 had to be swapped to make the graphics appear the right way round? It wasn't because they were wired up wrong. This is the chip select sequence:

__inline__ void ks0108::SelectChip(uint8_t chip) {
//static uint8_t prevchip;
if(chipSelect[chip] & 1)
fastWriteHigh(CSEL1);
else
fastWriteLow(CSEL1);

if(chipSelect[chip] & 2)
fastWriteHigh(CSEL2);
else
fastWriteLow(CSEL2);
}

Can you see what this assumes about the LCD, and why it would work with CS1 and CS2 swapped if this assumption was wrong?

This display has active-low CS lines - in other words the chip is selected when the enable line is grounded. In the previous case where we were only driving the left 128 pixels, when chip 1 was supposed to have been selected, chip 2 was, and vice versa. However, attempting to use 3 chips with this results in something different - chip 1 is off when selected, chips 2 and 3 are on - very very bad. Hence why the stuff for chip 3 was being drawn over the other two. So after fixing the fastWriteHigh/Low problem and adding an if statement to turn chip 3 on and off, it worked.

I'll release the modified ks0108 code when I've got it cleaned up a bit - it's a little hackish at the moment - and I've probably broken stuff in the code for other setups. But anyway, I can now draw to the whole 192x64 LCD.