Date: Mon, 12 Dec 2005 02:58:46 -0600 (CST)
Subject:
X-UID: 111
Content-Type: IMAGE/JPEG; name="img2440.jpg"
Content-Type: IMAGE/JPEG; name="img2441.jpg"
Content-Type: IMAGE/JPEG; name="img2455.jpg"
Content-Type: IMAGE/JPEG; name="img2444.jpg"
Content-Type: IMAGE/JPEG; name="img2445.jpg"
Content-Type: IMAGE/JPEG; name="img2446.jpg"
Content-Type: IMAGE/JPEG; name="img2449.jpg"
Content-Type: IMAGE/JPEG; name="img2453.jpg"

The two RS-232 to TTL serial level converter boards made last week were 
coated with silicone sealant on one side. While not electronics grade, it 
had a very mild non-acetic smell while curing so is probably safe enough.

Most consumer silicone products cure with acetic acid as a byproduct. This 
is corrosive to electronics. The acetoxy silicones have excellent 
mechanical properties which is why they are used in construction. They are 
also much cheaper than other varieties. As a general rule, the less smell, 
the less corrosion and the higher the cost.

The packaging to the Loctite product I am using says it cures in 24 hours. 
That is obviously not the case when the silicone layer is thick and 
ambient humidity is low. Silicones cure with moisture. I've been tempted 
to accelerate the process with a plastic container, damp towel and lamp. 
But I also know that rushing the drying or curing of paint or polymers can 
lead to unexpected bad results.

A datasheet from Henkel-Loctite says that one product was cured for one 
week at 40% humidity. So it looks like my experience is not far off the 
mark. For some reason, it looks like all of Loctite's electronics grade 
silicone products are made in Germany.

Everything is together now in the electronics enclosure. I've only tested 
the cooling fan. I can ssh into geode1 (computer on top - it controls the 
motors) and issue commands to turn it on and off. A function test of 
everything else will have to be done.

There were some issues trying to build gpsd. This is a service daemon for 
GPS receivers. Its build system uses automake, autoconf and libtool. Perl 
is also involved. This makes it tricky to cross-build. While the computer 
boards I am using are x86 compatible, the C library is uC-libC, not the 
standard GNU C library. So every native binary that runs on the robot 
computer boards must be built with the cross-toolchain. In the end, it was 
easiest to take the output from a non-cross build and hand edit the 
commands (old UNIX trick for tricky build systems). This is inelegant but 
didn't take very long.

The other issue is the broken DMA (direct memory access) on the computer 
boards. Others have run into this. The disk controller DMA doesn't work. 
It's not fatal. But booting takes many times longer than it should. When 
using the slow 32 MB compact flash card, no DMA is possible. The card as 
IDE device doesn't support it. But with the 512 MB ultra 2 cards, they are 
"ultra 2" because they support DMA. That makes them faster. It also 
reveals buggy DMA support in the Geode CPU from National Semiconductor. 
The irony is that this system would actually be faster with the cheaper 
and lower specification compact flash cards.

Earlier, I found that the computer board would lockup when grabbing frames 
from two webcams at the same time. It didn't matter that they were on two 
separate USB controllers. This is probably a DMA issue too.

The upshot of this is that much of the systems design was a lot of trouble 
for little or no performance benefit. The hacked PCI card providing four 
extra USB ports provides the same performance as the single USB port 
already on the computer board (assuming USB 1.1 devices like the webcams - 
there was instability with hi-speed USB 2.0 so don't know if that works). 
The more expensive SanDisk Ultra 2 compact flash cards are no faster and 
in some cases slower than lower specification memory cards.