Select Page
Kit Log #043: Fail or flail? Question marks

Kit Log #043: Fail or flail? Question marks

One of the tasks on the giant todo list was to fix the Super Bright Lights board. One of its traces is touching a pad, which is an error. It should be a quick thing to fix.

These boards were made in a program called pcb, a part of a suite of tools known as gEDA. It is not a very well known electronics design tool. There is a new fork of pcb called pcb-rnd. There are a few slight changes. Installing pcb-rnd on Mac is straight forward. Installing the other tools in gEDA is not. Specifically, we were looking to install gschem, the schematic editor. We tried brew, fink, but nothing was really working (broken dependencies).

Opening the board in gerbv, we can spot that the error does exist in the file, too. (That’s good news)

After some time re-orientating and remembering how to use pcb, here is the fix in pcb-rnd:

Then flip the board just to check nothing else moved:

Hey wait a second, there are question marks all over the board! The reference designators are all wiped out. Maybe something happened with the netlist, or some sort of properties file. We couldn’t figure out or remember how to edit the refdes in the new pcb-rnd. We can’t exactly send this board out knowing that there will be question marks printed all over it…

Here’s the errors that were given, justifying the new question marks on the board:

Anyway, we have an old version of pcb on one of our older computers, and we can make the fix using that. However, going forward, it will be wise if we switch from gEDA to Eagle or KiCAD, since the support for gEDA is very minimal at this point in time.

Tech Log #001: Foam board electronics unit

Tech Log #001: Foam board electronics unit

Today we continued work from yesterday and completed the foam board electronics unit. This contains all the electronics that go in to a Bowie robot. They are on a foam core board to make it an easier test platform, and something we can quickly test with instead of opening up a robot. After this was finished, we proceeded to run some test code. The tests did not work because the Xbees were not communicating. None of the LEDs for the Xbee were lighting up on the brain board. To debug if this was a hardware issue, we could not see the port when plugging them in to an adapter board into the computer. A workaround was to install the FTDI driver, restart computer, then run XCTU. We did finally see that the Xbees exchanged a NI (node identifier) packet. Voltage on the brain board was checked on the Xbee and it seemed fine. Further debugging will be necessary, further tweaking of the code will be necessary. This was never encountered before, and with the electronics been left out in the open, we cannot rule out ESD damage for sure. Aside from this it appears all dc motors, servos, and super bright LEDs are functional.