lab11 / powerblade Goto Github PK

After running continuously for several days, @bradjc has noticed that PowerBlade occasionally gives bad data. The data looks fine up until a certain point, then is totally invalid. On next packet it works again. See attached for dump of several incidents.

This seems like it could be a UART transmission issue where bad data is accepted. We might see if a checksum/crc fixes the problem.

bad_powerblade_data.txt

2 pronged devices (various wall warts and chargers) see to have no problem making contact with the Pogos. However, I cannot get the 1ft extension cords (not Branden's) or the powerstrip on the floor in 4901 to power PowerBlades.

Something like this (from a root shell on boot or something)

echo timer > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr0/trigger
echo 10000 > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr0/delay_off
echo 750 > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr0/delay_on
echo none > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr1/trigger
echo none > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr2/trigger
echo none > /sys/devices/ocp.3/gpio-leds.8/leds/beaglebone:green:usr3/trigger

This will turn off 3 LEDs and leave one as a heartbeat that blinks occasionally. Not sure if that won't still be annoying, but it's much better than the default.

Now only if we could do something about the power LED.

Need to come up with a solution to allow PowerBlade reversibility.

The problem, is that a load at 10 W one direction measures identically to a load at 0 W the other direction. Put another way, we don't know which direction we are plugged in. However, it is easy to tell the difference with higher wattage loads (~20 watts and up). For example, a 100 watt load plugged in backwards will read -100 W.

One solution that might work for now, is to keep track in FRAM of which direction you are plugged in. If you ever register multiple readings less than -20 watts (or some number like that) make the decision that you are backwards and reverse the real power logic. This will still allow us to detect a 0 W load, as long as the load has previously drawn greater than 20 W.

The README.md file refers to "flexible tabs" in the design, but the latest part I saw (and the corresponding comments on commits) have pogo pins for contacts instead.

Needs a summon app.

@Jovonni asked:

How are you guys even able to work on this on your own? Can you purchase one?

Thanks for the interest. PowerBlade has been a very fun system to work with. We're graduate students in Lab11 and have been lucky to have the resources to pursue projects like these.

Unfortunately, we are not currently selling PowerBlades. However, all the hardware files are open source and available in this github repo. Theoretically, you could fabricate and assemble some yourself (or alternatively, take part of the design and include it in some other work inspired by PowerBlade). The PCB was designed in Eagle.

Hardware files (we are currently using rev 3_5): https://github.com/lab11/powerblade/tree/master/eagle/powerblade

According to Sam DeBruin:

One of my recent goals has been to determine why PowerBlade doesn’t work on 220v, even though it definitely should. I recently ran a test on the 220v source, and although PowerBlade boots and sends packets, the values for voltage and power are wrong. I determined that the voltage AC wave is actually saturating the amplifiers at 220v, which leads to the error.

I also found the cause. If you do the amplifier math (I use KCL) the voltage measurement circuit is actually wrong. The GND symbol at (-2.3 -1.6) on page 5 should actually be VCC. I can take a picture of my math if you want, but its pretty simple to do the calculation yourself. The GND symbol adds a +Vcc/2 term to the output equation, which leads to saturation at high voltages.

The message: in future revisions change that GND to VCC. i.e. RI2 goes from the common terminal to VCC rather than GND. I would also recommend turning down the gain slightly, although that is less important.

We should fix this before producing any additional PowerBlades.

Gives some very strange readings when an ACme++ is plugged into the PowerBlade.

With multiple powerblades, sometimes it prints 8, sometimes 0, which I believe are both incorrect (assuming it is a count of the repeated advertisements that powerblade sends). After a brief look, it seems like iden_count is a global value that will get incremented by multiple powerblades, leading to what I'm seeing.

@nealjack It looks like line 16 of chroma63800.py should be self.inst.write(':LOAD:MODE CURR'), not self.inst.write(':LOAD:MODE POW').