More power board features

[Jeremy Morse]

Hi,

Now in the power board firmware repo two new things:
* The piezo can be driven
* There's a little more debug information on power board boot

The piezo works in almost exactly the same way as the previous power
board, heavily inspired by Rich's code. The only missing feature is
configuration of the volume, as I couldn't immediately work out how that
was achieved.

Right now a buffer of 32 samples can be sent to the power board for it
to play, stored in a ringbuffer. If it's full, the power board responds
with a USB stall -- this is catchable and non-fatal. Hopefully this can
be wrapped in the sr-robot software.

For the debug information, the power board will now set the status LED
to orange when it starts, and green when USB is configured.
Unfortunately linux configures USB immediately, so the LED turns green
almost as soon as the odroid boots, with or without the USB stick. This
at least allows people to identify when there's no connection between
the odroid and power board.

On USB reset, the status LED goes orange again and all the outputs on
the power board are disabled. This happens when the USB stick is
removed: alas, there's a latency of about two seconds for the stick to
be removed and the power to go off, as it appears to take that long for
linux to reboot and reset USB. And then it immediately configures the
power board.

This isn't ideal, but is a reasonable improvement in usability.

--
Thanks,
Jeremy

[Jeremy Morse]

Hi,

I've now also implemented the per-output current limits that were
discussed before. The IIRs that measure the current consumption run at
1Khz, and decay over 32 samples -- the whole-board current limit takes
100 samples, so surges on outputs should trip the output current limit
before the board.

I've tested the low power outputs, and with a current limit of 10A they
seemed to trip at about 9.2A, according to the whole-board current
reading. This is probably because (as mentioned in the
'current-readings' thread) there's a ripple on top of the current in my
test setup: I imagine I'm getting unlucky and reading over-the-average
readings from the ripple [0].

I couldn't trip the 20A current limit on the high power outputs because
the battery I'm using droops too much -- It correctly tripped when I set
the limit to 18A though.

When the limit is tripped, the output is turned off and the status LED
on. Any attempt to set the output on is blocked until the board is
reset, either through power off, usb reset, or going into protection mode.

Unfortunately however, this isn't ready to ship yet: with the latest
firmware revision, if you repeatedly make USB requests (reading
voltage/current) then it quickly stalls USB in a permanent fashion. The
libopencm3 state machine appears to get into an invalid state (it
expects to be idle, then receives an output packet from the host). If
you disable the call to output_poll() in the main loop, this goes away.

I've no idea why this is after a few hours, and updating to a later
version of libopencm3 seems to break usb enumeration. I'd be tempted to
say it's a timing issue, however adding more usbd_poll() calls
everywhere doesn't fix anything. So for the moment, I'm stumped.

[0] The motor board duty is at about 42% at that point, so I'd expect
the peak-to-trough amplitude of the ripple to be almost the greatest.

--
Thanks,
Jeremy

[Jeremy Morse]

Hi,

After a pleasant break away,

On 20/12/14 15:38, Jeremy Morse wrote:
> Unfortunately however, this isn't ready to ship yet: with the latest
> firmware revision, if you repeatedly make USB requests (reading
> voltage/current) then it quickly stalls USB in a permanent fashion. The
> libopencm3 state machine appears to get into an invalid state (it
> expects to be idle, then receives an output packet from the host). If
> you disable the call to output_poll() in the main loop, this goes away.
>
> I've no idea why this is after a few hours, and updating to a later
> version of libopencm3 seems to break usb enumeration. I'd be tempted to
> say it's a timing issue, however adding more usbd_poll() calls
> everywhere doesn't fix anything. So for the moment, I'm stumped.

This transpired to be a difference in my testing procedure: when one
attaches the power board directly to the root hub in my laptop (USB3 /
intel xhci) this fault presents itself. When there's a USB hub between
the laptop and the power board, it does not.

This seems to be the usual "compatibility? what compatibility?"
situation. xhci [0] is supposed to support USB full speed devices
completely, succeeds in operating the power board when not under load,
but stops working when loaded. Using a USB hub causes a different
transaction translator to translate down from high-speed USB to full
speed, and that works consistently. I'm really inclined to blame the
host controller / software for this (I don't have a non-USB3 machine
handy, sadly).

I also don't have an odroid handy to see if the same thing happens with
the host controller there. Worst case scenario, we tell people they have
to use the usb hubs to connect SR devices.

~

Anyhoo, I decided it'd be worth testing that the current limit triggered
when a power board output was short circuited. To test this, I attached
a power board to a battery (outside!), turned on the output terminals,
attached a camcon to a terminal (L2) with some long wires connected,
then struck the ends of the wires together. This is on the principal
that if something went wrong, the battery wouldn't be shorted for long.

The net effect was that the current limit did not trip: instead the
output-on LED dimmed for a bit. Short circuiting the terminal for entire
seconds at a time caused the LED to turn off. No other outputs were
affected. This was definitely the over-current / thermal limit detection
on the output driver kicking in. The output turned back on immediately
after the short was removed. There seems to be no damage to the power
board or terminal, it happily powers a motor board, although I don't
have a load to test it with right now.

I'm mildly disappointed that the current sense didn't register the short
(but please the power board is safe). I imagine the output driver
responds much faster than software can, so there's little chance of
registering the current. We could possibly detect the output rail being
off when it should be turned on, but there's no circuitry for that right
now.

[0] Which appears to be massively over engineered

--
Thanks,
Jeremy