Reimporting SVN exports.

As a followup to my post regarding SVN exports, I now have an importer. This script re-imports whatever I had exported. You do need to set 3 variables:
SVN_TARGET_REPO, the target repository.
SVN_LOCAL_REPO, this is the new location of your files
SVN_BACKUP, this is the svn export directory

#!/bin/sh
SVN_TARGET_REPO="svn+ssh://LOGIN@SERVER/var/svn/nextretro"
SVN_LOCAL_REPO="/Users/degs/personal/projects.svn/nextretro.new"
SVN_BACKUP="/Users/degs/personal/projects.svn/nextretro/svnbackup"

#create the directory for the target, and checkout revision 0, if no .svn
if [[ ! -e $SVN_LOCAL_REPO/.svn ]]; then
 echo "creating SVN repo"
 mkdir -p $SVN_LOCAL_REPO
 svn co $SVN_TARGET_REPO $SVN_LOCAL_REPO/.
else
 echo "skipping export: $SVN_LOCAL_REPO/.svn" 
fi
#now reimport everything
cd $SVN_BACKUP
for f in $(ls -d * |sort -n); do
    if [[ -d $f ]]; then
     echo "importing rev: $f"
        rsync -r --exclude=.svn --exclude=commit.log $SVN_BACKUP/$f/* $SVN_LOCAL_REPO
        svn add $SVN_LOCAL_REPO/* --force
        COMMITLOG=`cat $SVN_BACKUP/$f/commit.log`
        svn commit $SVN_LOCAL_REPO -m "$COMMITLOG"
        
    fi
done

Switching devices off of different supplies, flyback, and realities of the electron

The microcontroller can only drive about 5mA per pin; however, most non-digital circuits take much more power. Let's say you have a controller that runs off of 3 volts and you want to switch something that requires 5V or 12V. How is this done? The easiest way in a shared GND system is to use a NPN transistor so that when the input line goes "high", the NPN pulls hard to low.
Consider the following schematic:

For this example, let us assume that the power supply is 12v, and you have a BJT that you know very little about except that it's a NPN. The first order of business is to protect the MCU. You want to be sure to not zap your MCU. So we will assign our first value:
R0 1kOhm

R0 will limit the current drawn by the BJT to MCU Vdd/R. If you decrease R, the driving strength of the BJT increases (until saturation); however, you risk over driving your MCU output pin. If you need more driving strength use a Darlington Transistor or a motor driver IC.

R1 and LED0 exist purely to signal that your circuit works. You do not need these in reality. A good value for R1 would also be 1kOhm, and be sure that your LED is connected in the right direction

R2, LED1 and IND0 are where things get interesting. Firstly, let's talk about IND0, the inductor. A relay and a motor are basically inductors, and inductors resist a change in current, ie: they store current in their field. This means that if you change the state of an inductor, there will be a change in voltage based upon the internal resistance of the coil. This is where R2 and LED1 come in. R2 should be about 10ohms, only to increase the resistance for this experiment. R2 should be 0ohms otherwise. LED2 responds as something called a "flyback" diode, so that when the inductor changes state from on to off, it does not cause a voltage spike back into VDD. You dissipate this voltage into LED2 and you can see it flash for an instant. The larger the inductor, the larger this flyback voltage that is produced when the inductor is switched off. This flyback current is the number one cause of stress in college lab classes because it will cause something called "latchup" if the spike makes it back to the MCU.

Exporting SVN to a file hierarchy

Google code is shutting down, and I wanted not migrate the code to GIT on bitbucket because my scripts are all dependent on a version number and not a hash. Furthermore, I have found that GIT does not do well with binary.

The script will make a directory called svnbackup/REVISION so that I can easily import them later.

I pulled my nextretro project, and now I just have to decide where to put it.

#!/bin/bash
#this script exports any SVN repo to a possibly huge directory export
BACKUP_LOCATION='svnbackup'
#get the current repo
REMOTE_URL=$(svn info| grep -vi "Relative" | grep URL)
CURRENT_URL="${REMOTE_URL#*:}"
#get this repo version
REMOTE_VERSION=$(svn info | grep Revision)
CURRENT_VERSION="${REMOTE_VERSION#*:}" # strip out the version number
#create the directory
mkdir -p $BACKUP_LOCATION
svn info > $BACKUP_LOCATION/repo.info
echo "backing up current svn: $REMOTE_URL"
echo "current version: $CURRENT_VERSION"
COUNTER=1
while [  $COUNTER -ne $CURRENT_VERSION ]; do
     echo Exporting revision: $COUNTER
     mkdir -p $BACKUP_LOCATION/$COUNTER
     svn co -r$COUNTER $CURRENT_URL $BACKUP_LOCATION/$COUNTER/.
     svn log --revision $COUNTER > $BACKUP_LOCATION/$COUNTER/commit.log
     let COUNTER=COUNTER+1 
done

Would a Tesla battery system be worth it?

Telsa motors loves good press; however, when it came to the press about their battery technology, I had to scratch my head a bit. I spend most of my time counting electrons, and I have a pretty good feel for battery capability and battery chemistry. For starters, here's the original article: This new Tesla battery will power your home, and maybe the electric grid too.

The premise is a super efficient battery and inverter. You still charge up the batteries from a power source, but you can get power off-peak at a discount rate and save it, or use solar and save it. This is a nobel cause, but you still need to fill the batteries from a source. Batteries have loss, and if you look at the proposal from a purely power perspective, you have a loss due to the cost of conversion; however, you could have a net-gain monetarily if you can purchase power cheaper and reuse it.

The kicker is that I find power to be inexpensive in the USA, when compared to what I paid in Japan (unless you are in Hawai'i). The questions I see are:

1) At what point does it make sense to purchase an expensive battery pack?
2) How large does it have to be to be useful?

To start, here's a summary of energy density in Mega-Joules per Kilogram.

and then you can assume Telsa is using what they know: 20130187591, 20130181511.

In my figure, one needs to remember that energy storage is not conversion! This means that there are losses to different degrees depending on the power source. In the Telsa patents, you have a fast and a slow responding battery and a controller that makes the battery usage general purpose because you use different batteries for sustained load or instantaneous load, which makes sense for both a car or a house. In the case of batteries, you store energy that is saved/recovered as DC power, and then you take a 15% conversion loss to AC for houses.

How much power does the average American home use? 10000kWh per year. To make the math easy, let's day that it's 900kWh per month, so 30kWh per day. Let's say that you only want to save a single hour of power, that's 1kWh.

Ignoring losses of the conversion, the 12v truck battery gives you about 1kWh. If you wanted to save a day's work of power, you'd need 30 of these. So, what Telsa is actually offering is an attempt to scale down power for space. Lithium-Ion batteries being 7x better than lead acid for energy density, that would still be the displacement of about 4 lead acid batteries. The question is if Tesla can get the cost down for the batteries, and the conversion efficiency up. In 30 battery case, that would be $3k in batteries. Tesla would have to hit price point much lower than that; however, would it still be worth it. The cost of power varies greatly; however, let's say that you save 5cents per kWh by charging off peak, and store 5kWh per day at a discount. This results in 25 cents of savings per day. That's $USD 91.25 per year in savings, if your new found cheap power doesn't make you use more of it. (Higher efficiency cars seem to make us use more gas, for example [Knittel, Christopher R. 2011. "Automobiles on Steroids: Product Attribute Trade-Offs and Technological Progress in the Automobile Sector." American Economic Review, 101(7): 3368-99.])

Bottom line, assuming that the lifecycle of the batteries do not exist, and converters are 100% efficient, and you save five cents per kilowatt hour, you'll need the device to come to market at $91.25 if you want to recoup the device cost in a year.

ERROR: Current execution environment is VCO=aoi. Software tree is for environment VCO=ixl

I updated Calibre into order to try to address a warning, and I ended up making a mess. The new error was:

ERROR: Current execution environment is VCO=aoi. Software tree is for environment VCO=ixl

Deep down in the bowels of Calibre I found an environmental variable that I could set to change behavior. We'll see how it works:

export USE_CALIBRE_VCO=ixl

No errors of doom so far, but that doesn't mean that it will work.

virtuoso gives "bindkey uses Alt modifier and will be ignored"

I found that I had to update .cdsenv for my "alt-" macros. I was getting the error of "bindkey uses Alt modifier and will be ignored". I had to add "ui enableMenuShortcuts boolean nil" to my .cdsenv file. My current .cdsenv file follows:

license VLSL_UseNextLicense string "always"

layout          instLibName       string  "cmos14soi"
layout          ySnapSpacing      float   0.001
layout          xSnapSpacing      float   0.001

layoutXL        mfactorNames      string  "m M"
layoutXL lxFingeringNames  string  "fingers finger numFingers numFinger nf"
layoutXL  lxGetSignifDigits int 10

ui      enableMenuShortcuts     boolean nil

VirtualBox Guest additions, echo_success: command not found, consoletype not found, etc.

The VirtualBox guest additions for Debian are advertised as straightforward; however, they are not. The virtualbox.org pages don't really give much information. To make matters worse, the VBoxLinuxAdditions.run file requires script support that is native to RedHat, which gives errors such as: echo_success: command not found.

Here's the how-to for Debian, line by line:

apt-get install build-essential module-assistant
m-a prepare

Now you need to install two files from RedHat from my links below:
/etc/init.d/functions
/sbin/consoletype

Now when you run ./VBoxLinuxAdditions.run after you mount the CDROM, all works well.