Random projects

I've had a broken Symmetricom ND-4 wall mount NTP clock display sitting around for ages. For some reason, this turned into one of those projects where I decided I really wanted to get it working. It was such a simple device that it seemed stupid that I couldn't fix it.  

Poking around showed that the power supply seemed fine, but the Realtek RTL8019AS Ethernet chip was obviously faulty (AKA, it got hot!).

I tried replacing it, first with a pull from a different board, and then with a new one (I have a hot-air rework station and reflow oven). This didn't fix it, and some more research / probing of the (Rabbit 2000) processor showed that there were more issues - the UART was obviously trying to send something, but the baud-rate was nothing sensible, etc.

Eventually, I gave up trying to repair the processor board and it just sat in the corner of my workshop, gathering dust. But it kept bugging me, and so I decided to give it another whirl.

The display itself is a 7 segment LED driven by a MAX7219 ("Serially Interfaced, 8-Digit, LED Display Driver") with 4" high digits. This is a very common LED display driver, and there is a nice Python library for driving it, so....

Ferraris are notorious for having high idle / standby current draw, and they end up with all sorts of weird and hard to troubleshoot issues if their battery voltage drops too low. They also often have radios and similar which need (expensive) reset codes, or alarm systems that decide to forget their fobs. They are also often stored for the winter (being high power rear wheel drive cars, usually with summer tires, driving them in the winter is often, um, exciting!).

This makes storing them on a battery charger or tender critical - unfortunately, many people have either lost their Ferrari branded charger, or never had one. The charger which Ferrari supplies with most of their vehicles is the lowest end CTEK charger, with a special connector - this connector plugs into a special jack (usually in the trunk or passenger footwell), which disables the starter motor (to prevent the embarrassing "driving down the road with the charger still connected" issue :-)) - more info on the charger connector.

The following contains some information on how I make these cables - I make other cables for mission-critical purposes, and so I've gotten into the habit of seriously over-engineering cables - while I could just slap the proprietary Ferrari connector on the end of the CTEK leads, instead I solder and crimp the contacts, moisture-proof the connectors (by blocking the unused pin and the rear with foam, and then fill the body with hot-glue), install 4 layers of heat-shrink, etc.

Each one takes me multiple hours to make, so here are instructions/picture in case you'd like to make your own. 

To improve quality I created a template on a laser cutter:

To improve the connector strength (and decrease resistance), I apply flux to the contact, then fill with solder, before inserting the wire (and backfilling with solder)

It is really important to use the correct crimping tool for these contacts - I have tested the pullout strength using just solder, solder and an incorrect crimp, and solder and the correct crimp. The correct crimp makes a huge difference. The solder and (correct) crimp also provided the lowest electrical resistance by far (tested using the four-wire Kelvin technique). These contacts really need the S16RCM1450 or S16RCM16 crimp heads (available from DigiKey or Mouser) and Souriau crimp handles - the set is somewhat expensive (at ~$400), but the quality of the crimp is well worth it.

To help with moisture protection, I cut and insert a small piece of foam into the unused contact spot

And then insert the contacts

Getting them fully inserted is sometimes tricky, and so I strip a bit extra from the negative lead and then tin and heat-shink it just behind the connector - if I don't do this, the insulation around the wire stops it seating properly. I then use a Molex-tyle pin remover to check that each pin is securely clipped in,

Once the pins are all inserted I do an initial test.

It then gets a good glob of waterproofing / strain-relief sealant on the contacts / wiring

Some more foam gets wrapped around the wires towards where the end of the strain relief boot goes, and (temporarily) held in place with some more sealant

And now for the tricky bit. I add a bunch more sealant to the strain-relief boot, and then quickly screw it all together, before the sealant has a chance to set.

And then screw on the strain-relief clamp

Actually, this bit might be the trickiest, or at least the one with the most chance of cursing; right at the beginning of the process, I've (hopefully!) remembered to put on all of the extra water-proofing heatshrink.

It gets (usually) 3 layers of heatshrink to build it up

And them some final sealant in the back of the boot

And then a final layer of heatshrink over all of this to finalize the seal.

And the cable is all done, just needs a final test and label

Done

Photo album: http://photos.kumari.net/Projects/CTEK-Ferrari-Cable-Instructions/ and older page with more details: https://www.kumari.net/index.php/cars/ferrari-battery-charger-cable

I recently attended ICANN 59 in Johannesburg, South Africa.
While there I picked up a fidget spinner. It worked reasonably well, but it was not very well balanced and so shook somewhat while spinning. This bugged me (probably more than it should have!), and so I decided to do something about it.

If I held it vertically and gave it a quick spin, it would fairly much always stop with the light green arm point up. This means that the other two arms needed some material removed. I estimated how much would ned to be removed by adding hot-glue to the lighter arm to balance that, and then remove roughtly half that from each arm.

I couldn't figure out how the weights were held in the arms (it looked like a press-fit, but was very tight) and so I decided to try and mill some material off the outside of the arm. After removing some material on my little Sherline mill, it became clear that this wasn't going to provide nearly enough benefit (the body of the spinner seems to be aluminum, and the weights seemed much heavier) and so I decided that I needed to get the counterweights themselves out. I heated the arms up with a heat gun and managed to press the weights out.

Unfortunately, I didn't have my higher precision scale handy, but even using a lower precision one it was clear that the weights were different.

I put each weight in a Sherline lathe, removed bits of material and kept checking to see if this had fixed it. 

After removing much more material than I would have expected, I got it nicely balanced.

Of course, if something is worth doing, it's worth over-doing, and so I decided to replace all of the weights with larger, brass ones (I also enjoy turning brass). So, I turned down some brass rod to (slightly over) dimension, parted it off, and made small cuts to balance them.

I then turned small decorative cuts into the face, which also happen to improve the feel. The new weights are significantly heavier than the old - 41g versus 27g, heading to noticeably longer spin times.

Finally, the bearing felt somewhat rough, so I cleaned it in an ultrasonic cleaner, with some L & R #566 Ultrasonic Non-Ammoniated Watch Cleaning Solution, rinsed it in L & R Ultrasonic Watch Rinsing Solution and oiled the bearings with some Moebius 8000/4 oil. The Moebius turned out to be somewhat too thin, so I replaced it with

It is now much improved. All of this was way more work than it justified, but, hey, that's not the point!

Whenever you read a (good) cryptography book they discuss the difficulty in generating truly random numbers. The standard "random" numbers thay you get from things like the C rand() function is actually a psudo-random number -- it is deterministically generated by applying a function (often a hash) to an input seed. The seed usually generated from some external source, such as the interval between packets arriving on the Ethernet interface, keyboard timing, etc. The better pusudo-random number generators (PNRG) continue to feed external entropy data into the system to try and increase the randomness of the data.

While it may be hard to do, lots of cryptography requires very good (unpredicatable) random data -- as a recent example, take the recent CVE-2008-0166 vulnerability. The short version (longer, better written version here) is that valgrind (a debugging tool that, amongst other thing, checks to make sure that you are not reading garbage from uninitialized memory) was complaining that OpenSSL was reading some uninitialzed memeory and using that data. Someone got annoyed with the warning and without completly undertanding the function that was doing this, simply commented it out (actually, he did try and figure out the reason, checked with the OpenSSL list, etc), and so stopped valgrind complaining. Unfortunatly, the uninitialized data that valgrind was complaining about was used as entropy to the PRNG function and so the amount of entropy was decreased (and you thought it took work to decrease entropy!). The proctial upshot of this is that the PRNG was no longer as random and SSH keys generated form this ended up being predictable -- there were only 32,768 different keys that would be generated. Thils means that you could simply generate all of the possible keys and try them sequentially until the system let you in -- and hilarity ensued. The importance of true randomness (and the difficulty in generating it) for various applications even lead the Rand Corporation to publish a book full of randomness -- for only USD $90 you too can purchase "A Million Random Digits with 100,000 Normal Deviates"

In order to make the output of your PRNG as random as possible, you should pour more entropy into the pool -- there are various hardware devices for doing this, such as thermal noise, avalanche (or Zener breakdown) noise from a diode, shot noise, etc.

Intel used to make a motherboard chipset (i810) that included a good hardware number generator, but unfortunately have taken this out of newer chipsets. There have been some cute random number generation systems, such as SGI's lavarnd, which basically involved pointing a webcam at a lava lamp. A similar project (that stole the name) is LavaRnd which uses the chaotic noise from a CCD in darkness, but the ultimate source (and the one that all of hte textbooks use) is radioactive decay.

While all of the textbooks mention radioactive half-live as a great source of entropy, you don't often see this implemented -- so, this seemed like a fun project to do.

The basic plan is to take an old Geiger counter and point it at a source of radiation -- like the small Americium 241 pellet in an ionising smoke detector. I will then take the (audio) output of the Geiger counter and feed it to an interface that will connect to the serial port on a PC and watch the interval between "clicks". If the most recent interval is greater than the previous interval I'll count that as a 1, if less I will count it as a 0, and if equal, I'll just drop the current interval.

I have some Gieger counters that were originally designed for civil defence (back during the heady days when Russian nuclear attack was imminent) and just need to design an RS-232 interface. I m currently planning on using an OpAmp as a high impedance amplifier and driving an opto-isolator that will be connected to the CTS pin.

Oh! No page on PRNGs would be complete without mentioning the Blum Blum Shub PRNG -- I don't have anything useful so say about it, but, with a name like that, how could I NOT mention it?! In fact, I am going to try squirrel away a reference to it on every page  from now on...