Portland State Aerospace Society

Orbital gear concept.JPG

Wed, 07 Mar 2012 18:53:37 -0800

2012-04-27 - Atom FC kernel

Fri, 27 Apr 2012 16:52:51 -0700

The Atom flight computer currently runs Debian via Compact Flash, and boots the kernel via GRUB from Compact Flash; it currently ignores the kernel in onboard flash. Networking and USB storage both work, so you shouldn't need to remove the Compact Flash card.

To build a new kernel, grab the appropriate /boot/config-* file from the FC, put it in .config in a kernel tree, optionally change the configuration further, and run "make deb-pkg" to create a new Debian package. Then copy that Debian package to the flight computer and install it with dpkg -i.

2012-05-15 - Avionics meeting

Wed, 16 May 2012 00:20:53 -0700

Lots going on tonight: Richard P. found what looks like a good SPS with enable, Richard A. is done picking out sane parts for the LTC, James is working on the battery board, K and Andrew discussed the ADIS IMU adapter, etc. Theo couldn't make it, but hopes to come Friday.

GPS Carrier Board

Nathan is hammering away at the GPS carrier board. He got a first go of the board laid out.

Issues: - Mounting hole distances on the LNA - plated mounting holes for the LNA and the Crescent board - Find connector for USB, work on placement to avoid coax

Battery Box

Dave finished the new 4 cell battery box. The upshot is: thicker walls, no top (stronger), less material near the plate screws so we can screws, PCB for both the front etc. Now James has the info he needs to layout the battery board. We're sending it off to Pat to get FDM'd. Yay!

Flight computer GPIO

Background

We tried to get the GPIO on the ADventech PCM-3363 PCI-104 Atom flight computer to work sanely. We more or less won, kind of. The GPIO is from a NXP PCA9555 16 bit SMBUS-to-GPIO chip. Of the 16 GPIO pins, only the lower 8 pins go to a connector on the PCM-3363 board. The upper 8 pins either don't go anywhere, or are connected to the "melt down the FC" device, so we shouldn't mess with those bits.

According to the PCA9555 datasheet, it should exist somewhere between 0x20 - 0x27. Running i2cdetect -y 0 we found a device at address 0x20. And yes indeed, that's the PCA9555 we're looking for. To manually set the PCA9555 registers, you can use the i2Cset/i2cget commands (BEFORE you load the driver, see below). Also:

NOTE THAT THE PCA9555 SETTINGS STICK PAST REBOOT. ONLY A POWEROFF WILL RESET THE VALUES.

Magic SMBus Command	What it does
`i2cget -y 0 0x20 0`	Read the state of the pins (0x00 - 0xff).
`i2cset -y 0 0x20 2 0xff`	Sets the output register to all high (0x00 sets the output register (not pins!) low).
`i2cget -y 0 0x20 2`	Read the output register.
`i2cset -y 0 0x20 6 0x00`	Sets the direction of the pins to all outputs (0xff makes them all inputs)
`i2cget -y 0 0x20 6`	Read the direction register.

Linux driver

Jamey built a new kernel that includes the GPIO-PCA953x driver (which includes support for the PCA9555 and a bunch of other similar chips).

The command echo pca9555 0x20 > /sys/bus/i2c/devices/i2c-0/new_device which makes the driver pretend it discovered a PCA9555 at address 0x20.

cd /sys/class/gpio
for pin in `seq 240 255`; do echo $pin > export; done
for pin in `seq 240 247`; do echo out > gpio$pin/direction; done
for pin in `seq 240 247`; do echo 1 > gpio$pin/value; done

Stupidity all around

So what did we discover?

The PCA9555 on the FC has stiff pull-up resistors. Tying the floating pins to ground using a 1kohm resistor gave us ~ 886 mV, which means there's the equivalent of a 4.7 Kohm pull-up resistor. Aaarrrrggghhhhh why?
Although the PCA9555 defaults to 0xff in the output register, when we turned the direction register to all outputs, we'd get all low. This means something (the BIOS?) is setting the output register to 0x00 before the GPIO driver even loads. Weird. Toggling the "active_low" bit didn't help this. Since the driver doesn't allow us to set the output register before turning the direction to outputs, this means no matter what we do, the GPIO pins toggle from "inputs with 4.7K pull-ups" to "outputs set at low".

1+2 above totally suck, because it means that we can't sanely control the GPIO - as soon as we set them to outputs, the values flip. Luckily, we have two different solutions:

Before the GPIO driver loads, use the i2cset command to manually set the output register to 0xff. That way when we set the direction to output, we still get 0xff just like the "input with pullups" had before.
Desolder the pull-up resistors on the back of the board near the PCA9555 and add pull-down resistors other places. Now, when we set the direction to outputs, it's already low so again, no flipping state.

Which solution we'll take is dependent on the active high / active low requirements for the SPS units we're switching on and off.

2012-05-08 - Avionics update, more battery hacking

Wed, 09 May 2012 01:42:38 -0700

Avionics Updates

Updates to the battery pack case (Dave, Andrew)
- Distance between D blocks set at "2 holes"
- Charge board is too big to fit on end of battery board. Let's just not worry about trying to mount it to the back. It does fit on the top of the avionics module, so that's probably the best place for it.
- Dave to do: remove holes from sides, remove front panel for PCB, insert holes for PCB screws, thin foam and thicken plastic, add ribbing for bolt heads, add filets
Nathan has the GPS carrier board schematic done.
Richard has a great redesign for the launch tower computer (LTC). Still looking for a cheap linux board for it.

Battery Hacking

Jamey and Andrew wrote to the flash of the BQ3060. Successful? Hard to say. We certainly wrote to the flash, but since i2cget doesn't have a multibyte read command (eeeeyururrgh) we can't read the everything we wrote. Here's our attempt to write to flash. We calculated the following bytes to write:

C.7.1 Registers (Subclass 64) (Page 142)
- C.7.1.1 Operation Cfg A (Offset 0)
  - High: rrrrrr-11 = 0x03
  - Low : rr-1-01-r-00 = 0x28
- C.7.1.2 Operation Cfg B (Offset 2)
  - High: rrr-0-0-1-0-0 = 0x04
  - Low : 0-1-0-0-0-0-0-1 = 0x41 // LSB = BCAST is the bit we care about
- C.7.1.3 Operation Cfg C (Offset 4)
  - High: rrrrrrrr = 0x00
  - Low : r0rrr100 = 0x04
- C.7.1.4 Permanent Fail Cfg (Offset 6)
  - High: 00000000 = 0x00
  - Low : 00000000 = 0x00
- C.7.1.5 Non-Removable Cfg (Offset 8)
  - High: 00000000 = 0x00
  - Low : 00000000 = 0x00

And then we ran these commands

i2cset -y 0 0x0b 0x77 64 w
i2cget -y 0 0x0b 0x78 w // confirm it's 0x0228
i2cset -y 0 0x0b 0x78 0x03 0x28 0x04 0x41 0x00 0x04 0x00 0x00 0x00 0x00 s
i2cget -y 0 0x0b 0x78 w // now should be 0x0328

We get 0x020a from the first i2cget. OK, so the chip isn't set to the exact defaults. That's OK. After running the flash writes, we then get 0x030a. OK, that's weird, we wrote the first byte but not the second? Can't really explain that.

Other things:

BQ3060 doesn't seem to come up when in sleep mode, even if the charger is turned on. This needs more exploration (try charge when it's asleep.
Wrote /usr/local/sbin/charge which manually turns on charging from the BQ24275 charger chip.

Andrew notes: If BCAST is set, then "ChargingVoltage and ChargingCurrent broadcasts are sent to the Smart-Charger device address (0x12) every 10 to 60 seconds." That makes sense, because the BQ24725 data sheet says the chip should be at 0x12. But... but... our charger chip is at address 0x09. And for that matter, why does the BQ3060 manual say it should be at 0x16 when it's really at 0x0B? Something weird is going on here.

2012-04-27 - Avionics hack day (FC, BQ3060, power measurements)

Sat, 28 Apr 2012 15:01:24 -0700

Power Measurements

Agilent E3646A power supply set to 14.7V
FC would go between 850 mA (USB peripherals unplugged, monitor blanking) and about 1.2 A (everything plugged in, monitor on, cores burning, etc).
- Exercising the cores made very little difference 0 only about 50 mA - which was surprising.
- TODO: How much does the CAN board draw?
- TODO: How efficient is that PCI-104 SPS?

GPS board

Turns out the GPS board can be directly connected to the FC's USB port. Yay!
TODO: Does the Hemisphere Crescent GPS board actually having working USB? How does that work exactly? ttyUSB0, or some weird thing?
TODO: Will the GPS actually go into a low power mode if it's suspended?
Nathan agreed to start laying out the simple GPS + LNA carrier board.

New LTC

Went over the old LTC with Richard - we missed a lot of features the first time around.
Discussed the RocketReady signal - do we really need? The argument is that with it, the LTC can't go insane and launch the rocket (after the LTC interconnects are attached).

FC "breakout" board

Instead of just connecting to the horrible connectors on the FC, we're looking at bringing most of the connections of the FC to a custom PCI-104 form factor "breakout board" that fits in the FC stack. That way we can essentially glue/tape everything down on the FC, and have polarized and locking connectors on the breakout board. Keith is working on this. Its nickname is the "medusa" board, because of all the wires going in and out of it.