Category: Uncategorized

We ran into problems recently getting the NVIDIA 3D Vision Pro glasses to work on a dual-pipe stereo projector (clone mode stereo). The projector takes two DVI inputs, one for the left and one for the right eye at 1920×1080 and 60Hz. These are then displayed frame sequentially at 120Hz. The projector has the standard BNC connector which outputs the stereo sync signal for the glasses (Sync and Ground).

The NVIDIA RF base station (pyramid) has a 2.5mm stereo jack socket which accepts external stereo sync, so we tried feeding the projector sync into that input. Unfortunately, the pyramid seemed to ignore the external sync and wouldn’t activate the glasses…

We had the NVIDIA pyramid working well on another system in active stereo, using the 3-pin VESA sync output from the graphics card, so I decided to test that. This is what I found:

• When running at 120Hz active stereo, the Sync signal is a simple 5V square wave with 50% duty cycle of around 8.33ms high and 8.33ms low, exactly as you would expect.
• The LED on the back of the pyramid lights up blue when it’s using external sync, green otherwise.
• When using active stereo, the Sync light only illuminates when stereo is activated (i.e. when running a stereo application)
• 5V power is always present on the 3-pin VESA stereo connector.
• If the 5V power is removed, it ignores the external SYNC input. Using only SYNC and GND is not enough to get it working.
• Once it has switched on and started accepting external Sync, I tried disconnecting the 5V power: the blue LED stayed lit. This suggests it only checks for presence of 5V at start up.

This is what the Sync LED looks like when the unit is persuaded to accept external sync:

The solution was to make a cable which combines the Sync output from the projector with 5V (taken from USB) and Ground onto a standard 3-pin mini DIN VESA stereo connector (pinout shown below). The picture above shows the cable (white Y-shaped cable) taking Sync via a BNC connector (the T-piece is used to connect another IR emitter in parallel) and the connectors on the right are the 3-pin mini DIN stereo cable, which goes to the 2.5mm jack sync input on the NVIDIA pyramid.

This is the pinout of the VESA Stereo 3-pin mini-DIN socket:

 

 And here’s the corresponding pinout for the NVIDA 3D sync jack:

Caution: the jack plug isn’t a great choice of connector for something carrying GND and 5V, as there is obvious potential for a temporary short when the plug slides in and out of the socket. Avoid connecting/disconnecting the jack when the system is powered up. It’s safer to disconnect the USB and mini-DIN plugs.

We have one of those multi-function scanner/printer/fax/copier machines at work, the Brother MFC-8860DN. After a few years of faithful service, it started displaying “Fuser Error” and refused to print. We needed a new one fairly urgently, so I immediately bought a new HP one as replacement, but I wasn’t quite ready to send the old Brother to the graveyard and decided to try replacing the Fuser.

Having switched off the power, I pulled the back cover off the printer and located the fuser unit. This wasn’t too difficult to get to: there are two panels which pop out, two screws to remove, and two more covers to gain access to the connectors for the heater and sensor cables.

The picture below shows the panels/covers to be removed. The Panels A and B can simply be popped out by bending one of their plastic “hinges” at either the left or right hand side. The cover C is held on by one cross-head screw, and the cover D simply pops off if you push on the spring tab (near the letter D below). Having removed cover D, you will gain access to another cross-head screw. After removing those two screws, and disconnecting four cable connectors, the Fuser can be lifted out of the printer.

The Fuser is basically just a heated roller, so there are only a limited number of things that could go wrong. For example, it could be a loose connection, a burnt out heating element, or a faulty sensor.

At the left hand side there are two fairly thick cables with spade connectors, and the cover has a temperature warning sticker. It seemed fair to assume these were the heater terminals…

Having pulled off the two spade connectors, I measured the resistance and they were open circuit. Concluding that the heating element had burnt out, I ordered a new Fuser unit (Brother LU7941001).

When the new unit arrived, I measured the resistance across the same two terminals and found about 4.5 ohms. So, if you have access to a multimeter, this is a simple way to test if the heater element has burnt out.

When the new unit arrived it was a simple job to reinstall. If you are attempting this job, there are a few final things to be aware of:

1. The new Fuser will arrive with its pressure roller set in the “low nip pressure position”. Basically, before installing, you just need to push up on the two blue tabs to release two spring loaded levers. There are (poorly) illustrated instructions included with the Fuser.
2. Replacing the left hand cover (C) in the picture above is a little bit fiddly. It has two tabs which slots into a couple of holes in the side panel, then needs to be pushed down and rotated backwards to get the screw hole to line up.

The printer then needs to be told that the Fuser has been replaced, and I found out how to do this here. Enter the maintenance menu by pressing MENU * 2 8 6 4 with exactly the right timing (about 1 second per button push). It took me several attempts to get this to work. Another way is to hold MENU while you power on the machine. From maintenance mode you then:

1. Select option 88 which is ‘Part Replacement’
2. Scroll to ‘Fuser’
3. Press OK or Start.
4. Select option 99 to exit the menu and restart

Having done this, the printer was back in operation again!

I have an old Shuttle PC (SB75G2… I think) which I seldom use, and decided to recycle it to drive a small CNC mill that I’m building. The first step was to wipe off Windows XP and install LinuxCNC (which is built on Ubuntu). The PC runs great but, unfortunately, neither the built in Ethernet or Wireless card worked out of the box.

This really surprised me, as  network and driver support in Ubuntu seems to have improved a lot since the early days, but there are clearly still some gaps in the range of supported devices.

The wireless module is a PN15, and a quick search didn’t turn up many hits, but eventually I found a solution, so thought I’d write it up here in case it helps someone else in the same position.

The wireless module is connected internally via USB, so first I tried lsusb and got the following back:

$ lsusb
$ Bus 001 Device 002: ID 124a:4023 AirVast

This led me to a forum post which said it was supported by the p54usb module built into the kernel, but it needed proprietary firmware downloading. If you have a network connection of some kind, you can do this apparently (haven’t tried yet):

$ sudo -i
# apt-get install linux-firmware-nonfree
# modprobe -r p54usb
# modprobe p54usb

In my case, I didn’t have any network at all, but instead found these instructions pointing to a download link to a firmware file:  https://wiki.debian.org/prism54

Mine turned out to be a first generation device with the ISL3886, so I downloaded the firmware as follows:

$ wget https://daemonizer.de/prism54/prism54-fw/fw-usb/2.13.1.0.lm86.arm --no-check-certificate

Then I copied that file over to the Shuttle with a USB stick, and moved it into the firmware folder, and reinserted the module to load the firmware:

$ sudo -i
# mv 2.13.1.0.lm86.arm /lib/firmware/isl3886usb
# modprobe -r p54usb
# modprobe p54usb

Having done this, the wireless came up and I was finally able to connect. As I write this, the PC is busily updating itself…

Our Modus recently developed an alarming fault, where the dipped headlights or full beam flash on briefly when using the indicator stalk, or going over a bump in the road… not good! It could be pretty dangerous if someone thinks you’re flashing to let them out at a junction. This is the second time this has happened to us, so I thought I’d explain the cause and how I fixed it.

Basically, the problem was caused by a wire snapping off where it enters a connector inside the indicator stalk housing. Every time you move the indicator stalk, it flexes the wiring and after a few years it breaks due to fatigue on the wire. Here’s the offending wire, which you can see has broken free of the connector:

These are insulation displacement connectors, where the wire is pushed down between two blades. These pierce the insulation and make contact with the wire. Obviously, they also act as a nice point of stress to encourage the cable to fracture as it is flexed.

This is low-voltage logic wiring, and doesn’t carry much current judging by those tiny wires. It probably connects to some kind of digital controller and  uses MOSFETs to switch the lights.

Anyway, this is the second time this has happened on the same car, with about 2 years between occurrences. The first time, it was the right-most pin (as shown above). That previous repair is still good, but this time the wire next to it has failed.

Update: in June 2015 the right indicator stopped working. Again, this was due to a broken wire (the third one from the right this time). This was fixed in exactly the same way, as described below. Since I first posted this in April 2014, that’s just over a year gone by since the last repair.

You might find that several wires have broken simultaneously on your Modus (as Moss mentions in the comments below). The good news is that all of them are wired “straight through” so that pin 1 is connected to pin 1, pin 2-2, pin 3-3 etc. for all ten wires, so you should be able to reconstruct the correct order!

To begin with, I disconnected the battery as a precaution before carefully disassembling the housing round the steering column. Pop out the lower light grey plastic panel around the steering column (pull the top section towards yourself) to make it easier to access. There are two Torx T20 screws beneath the steering wheel housing, and the rest is snap fittings. The lower section of the housing can be lifted free (you may need to move the steering height adjustment lever to remove it).

Here’s a view of the steering height adjust release lever on the 2006 Modus. I had to release this lever before I could lift the housing off:

The upper section of the steering housing doesn’t need to be fully removed, but can be lifted out of the way. The indicator stalk module unclips and slides out of the steering column (that part at least is  a surprisingly nice piece of design).

To fix the broken wire, I soldered in a short length (about an inch) of new cable to extend the broken wire so it will be under less stress, and insulated with heat-shrink tubing:

If you are considering doing this job, it’s probably worth adding that you need access to a soldering iron and some heat-shrink tubing (the wires are quite small, and would be hard to join by crimping I think).

Note that the distal end of the wire (which will go into the connector) is the original wire, to ensure it is the proper gauge for the connector. I gently picked out the remains of the broken cable from the connector with a pin, and pushed in a fresh piece. I then tested all pins for continuity, and all was good.

Again, if you are planning on doing this, be aware that the connector is fairly small and it’s fiddly to get the wires in (these connectors are not designed to be repairable – just intended for a single use / factory fit). It is possible though, if you have patience 🙂

Here’s a shot of the front side of the repaired connector. Note the black heat-shrink tubing on the repaired wires:

Here’s a close up of the rear of the repaired connector, showing the wires pushed in between the blades of the IDC connector:

This is what it looks like when re-installed inside the indicator stalk module. Note that the central part (with the PCB and connector) is mobile, and moves when the stalk is used.

Here’s another shot of the internals of the indicator stalk assembly and wiring:

Finally, here are some images showing the indicator and headlamp stalk units completely removed, showing the wiring loom between them:

And here’s a close-up image showing the connector on the headlamp stalk unit fitted:

Having reassembled it, I did a complete test of all the lights and it all works fine again. Well, until next time at least!

Further investigation of the connectors…

So far the “zero cost” fix above has worked for me… but I was curious about the type of connector used, and whether the whole assembly could be replaced with new parts. Looking at the photo above, I noticed the connector has “JSTDF” printed on it, which made me suspect this is a JST connector. After a bit of searching on their web-site, I found the KR connector and CK connector, which look similar:

These are 2mm pitch IDC connectors, and the 10 pin version would be 22mm long. I haven’t actually checked if this is compatible, as our Modus is working fine and I’m reluctant to take it apart again just to measure the pitch/size of the connector!

Anyway, the JST datasheet says that the housings are “Compatible with the PH crimp style connector”  which is interesting, because crimp connectors and tools are cheap and easy to use, so it might be possible to make a new 10 way cable using these. Again, I’ve not checked if these are compatible but RS have the PH connectors and even have ready made cable assemblies. Here are some direct links to the components on the RS web-site:

• JST PHR Series 10 way housing (RS 8201462)
• JSR Crimp contacts (RS 8201456)
• JST Cable assembly 300mm length (RS 8201412)

If these connectors are compatible, this would be another possible fix to consider!

To make the nano text editor nicer to use for development, you can change the tab size to 4 spaces, set it to convert tabs to spaces, make it always display line and character numbers and enable multiple file buffers. Since I always forget how, here are the settings that go in the ~/.nanorc file:

set tabsize 4
set tabstospaces
set const
set multibuffer

The multiple file buffer feature is really useful, as you can load multiple files with CTRL+R and quickly switch between them with ESC follow by > or <.

Sometimes you need hard tabs (in a Makefile for example). To achieve this, the -I flag can be used to ignore the .nanorc file for Makefiles:

nano -I Makefile

At the weekend we passed the amazing Rudston Monolith, which is almost 26ft in height and dates back to the late Neolithic period (“possibly circa 2000 B.C.” according to the placque).

Here’s another view next to the church. This is a really beautiful spot at this time of year, with the daffodils in flower.

I don’t think I’m alone on this issue… it seems almost impossible to build a working kernel driver on the Pi. After much trial and error, and on the verge of giving up completely, I finally succeeded!

I started with cross compilation on Ubuntu but couldn’t get it to work initially, it kept giving “Invalid module format”. Compiling directly on the Pi, again I was only able to obtain “Invalid module format” errors and, finally, a module that loaded but crashed the OS. The .config and Module.symvers seem correct, but it just would not build a working module. It makes me suspect some compiler toolchain difference between the kernel and the tools used to build the module.

Finally, cross compilation worked. Here is the magical recipe which  worked for me under Ubuntu, cross compiling for 3.10.33+ (mostly in case I need it again myself). First, set up the environment variables and download tools as described here.

git clone --depth 1 git://github.com/raspberrypi/linux.git
cd linux
cp your/raspi/config .config
wget https://github.com/raspberrypi/firmware/raw/master/extra/Module.symvers
ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig
ARCH=arm CROSS_COMPILE=${CCPREFIX} make menuconfig
# Save.. Exit..
ARCH=arm CROSS_COMPILE=${CCPREFIX} make modules_prepare
# Note: can specify -j9 for 8 core compile..

Well, now that it finally works, I’m not updating the Pi again until I’ve finished my driver 😉

Incidentally, here’s an easy way to find Module.symvers: https://github.com/raspberrypi/firmware/commits/master/extra/Module.symvers

Now the Renault Modus isn’t a bad little car really, but it has at least one appalling design flaw: changing any of the front bulbs generally involves removing the whole front of the car!

Anyway, I recently had to change one of the sidelights, and read online that it’s possible to do this by removing  part of the front grille. I couldn’t find any pictures, so I decided to take some photos as I did the job in the hope it might help someone else in the same position!

To start with, here’s a picture of the side light from the front. The bulb (circled below) is a 501 (W5W) which is 12V and 5W.

When you lift the bonnet, there’s a rubber seal along the front edge. This is clipped into place at both ends with a plastic clip, and can be gently popped out as shown below, to reveal a plastic tab (centre of photo below):

If you lift (and jiggle) this tab, you can pull out a long plastic shaft as shown below. Once removed, this releases the front grille.

Having completely removed this, the grille can be popped out of the front panel as shown below with the plastic locking shaft. This needs care, to avoid breaking the tabs. Before removal I also popped out the four round plastic clips to free the top edge of the front panel so that I could see the rear of the grill, and this gives a bit more flexibility, but probably isn’t essential. To remove the grille, I pulled the lower edge of the grill forward and up (pivoting around the upper clips).

After you have removed the panel (hopefully without breaking any of the retaining tabs…) you will be left with a hole like this:

If you look inside here, you can see a rotary cover for the side light. Unscrew this and it will reveal a black plastic cylinder. This simply pulls out and you will find the bulb pushed in the end.

Pull the bulb out of the holder and replace. Remember to refit the cover and test all the bulbs before reassembly.

This is quite a quick job and is much, much simpler than replacing the headlights, but that’s a story for another day!

I wanted to move an existing Subversion repository to Google Code, preserving all the history. This is possible, but (as with most things) turned out to be  more complicated than expected.

To start with, you need to dump the existing repository. If you can’t log into the server directly, it’s possible to do this for a remote server using the svnrdump command:

svnrdump dump https://svnserver.com/trunk > remote.dump

This will probably contain the full history of several projects, so the next step is to filter out the specific project you need. Unfortunately, svndumpfilter won’t read the dump output from svnrdump (it doesn’t seem to like the file version).

One workaround is to temporarily create a local repository, load the dump file to that repository, and then dump it back out again. The new dump file is then accepted by svndumpfilter. Not very convenient, but it works:

svnadmin create temp
svnadmin load temp < remote.dump
svnadmin dump temp > local.dump

Then (theoretically) you can filter out the specific project path from the dump file using svndumpfilter. Again, this caused me some problems because it leaves lots of empty commits (i.e. log messages related to other projects, with no file changes).

svndumpfilter --drop-empty-revs --renumber-revs include /your/path/ < input.dump > output.dump

There is apparently a newer version of svndumpfilter which accepts a new option –drop-all-empty-revs. However, updating SVN didn’t get me this version, and I couldn’t be bothered to build it from source.

The solution was to use the much more capable svndumpsanitizer. Unlike svndumpfilter, this actually seems to work, and is a single C file with no exotic dependencies, so very simple to build.

svndumpsanitizer --infile input.dump --drop-empty --outfile output.dump --include /your/path

I did find one bug with svndumpsanitizer: it doesn’t work if your dump file contains a partial set of revisions. For example: I had a dump file which started from revision 88, and this caused it to index out of bounds of an array and output nonsensical revision numbers like 1638472. I only discovered this by adding an assertion in svndumpsanitizer to check array bounds. After that, I fed it a complete dump file containing all revisions, and it worked fine.

In my case, I also wanted to replace the username in the commit messages. This can be done using svndumptool as follows:

svndumptool.py transform-revprop svn:author OldAuthor NewAuthor input.dump output.dump

Then you need to create a local repository and load the dump file.

svnadmin create repo
svnadmin load repo < final.dump

If this doesn’t work, you might need to manually create some of the higher level folders (e.g. trunk) before loading the dump.

svn mkdir file:///full/path/to/repo/trunk

At this point you need to create your Google Code repo. Then you can use Administer… Source… Reset this project’s repository. to ensure it’s empty.

Finally, you can initialise the remote repo and sync the local repo to the remote Google Code repo.

svnsync init https://project.googlecode.com/svn/ file:///full/path/to/repo/ --username username@googlemail.com

svnsync sync https://project.googlecode.com/svn/ file:///full/path/to/repo/ --username username@googlemail.com

If all goes to plan, you should now have a copy of your project on Google Code, with full history available. If not, you can reset the repo on Google, filter the dump files again, and retry.

This took  quite a bit of trial and error and searching to find, so I hope it helps save you (and me) some pain in future.