I got an interesting question on my YouTube channel yesterday asking if my transimpendance ammeter can measure A/C in addition to D/C and if the output of the instrument is A/C.
The answer is yes to all of the above. Good question and a fun little thing to test on the bench on a Saturday morning.

I pushed 185 watts through my custom DC relays last night. They ate up that power like a champ. Likewise, I've also been testing it in the off condition to measure its steady off power consumption. The cards burn 150 nano amps or 1.8uW when off. That's means it's about 80 mega ohms which is OUTSTANDING. This project is really moving along nicely. I have some serious burn in testing to do and then it's time to get the main board encapsulated and do some real life testing. That's going to be fun!

Well, its time to finally get this project "out there". I've been sitting on it for months putting together a bunch of cool little projects for this board and the video above shows off some of the cooler ones. Check out the Kickstarter page for more details as well.

Ever since I saw Kickstarter the first time I've been wanting to give this a shot so I could learn the ins and outs of doing small scale manufacturing from home. Because this is not a product, but a platform or hacker tool I am not super confident there is a substantial enough market for it but I cannot know if I don't try.

The plan if this succeeds is to give all the boards a final value engineering assessment and put the project out to bid. I've already done this with a Florida shop called Tropical Assemblies as well as with Seeedstudio. I'm not super excited with Seeeds PCB quality so I think I'll skip them but the good news is that the local fab shop had similar prices so at least I'll know that I can call and complain if anything goes wrong.

An issue has already cropped up with the Joystick shield. A part I used in the BOM is no longer available anywhere. I'll contact the vendor and verify its availability or lack thereof and reevaluate. I've already got a backup plan but it will require a two sided board which is going to kill the bottom line. No matter, this is more about learning this home manufacturing process then about any profit motivation so we are just going to drive it hard and fix what breaks.

Recently, we at Freeside Atlanta teamed up with the Alchemical Arts Alliance and My Inventor Club to design and build an Offroad Wheelchair so that our friend Robin can get around their events. Together, we've raised about $2,000 for the project.

The design phase is usually the most
difficult part of the projects, and it is often the most expensive
place to make a mistake. Committing the resources to a
poorly-designed project can cause the entire thing to be wasted, so
we designed the Offroad Wheelchair project very carefully.

We started with the constraints – We
need ease of maneuverability, an ability to overcome obstacles and
take fairly steep inclines, longevity to make it through events up to
a week long, and recoverability in case it gets stuck. Also, biggest
two constraints – Budget (~$2000) and time to prototype (2 months)

After weighing the options, we chose
option one for its low noise and high efficiency. Next step -
simulate the design. I used the website Study Physics to figure out the torque requirement to
pull a simulated wheelchair + passenger up a given slope. Then I
simulated it in a spreadsheet starting with the worst-case scenario
so I could play with the numbers. The inputs are in orange and the
rest are calculations.

In other words, the force required to
take a vehicle up a 15 degree slope is a bit more than half of the
force required to lift it all the way off the ground. To find the
torque requirement, the force needs to be distributed around the
wheel, since the wheel radius affects the leverage exerted by the
motor.

Therefore, the minimum torque of the
motors is about 200 pound feet. Is that feasible for an electric
motor? Let’s look at the best motor example I could find -

This means that the system required two
very powerful electric motors, running near peak torque continuously,
and geared down 60x. They exist, but they are about $600 each and
don’t usually match each other’s output exactly. Plus, the motor
controllers are $200-$400 each! That means that this project is
neither feasible nor practical, as the entire budget could be spent
on 2 motors with their respective transmissions and controllers. It
won’t work. But, this is why we simulate. It’s time to drop back
and try again.

The hydraulic modification of an
existing vehicle seems interesting, but also time-consuming. Plus, it
wouldn’t be able to pivot in place like the other two design
options, which is important to delivering the rider to exactly their
target. Not to mention that the drive of the wheels will probably be locked together, so there is nothing stopping the thing from sliding down a slope. It also requires the modification of a ~$1000 platform with
up to $800 in hydraulics and most options aren’t configured for
somebody to easily get into from a wheelchair.

Then, Shane from My Inventor Club sent
me an email about a zero-turn mower that was available in our price
range. Zero-turn mowers use hydrostatic transmissions to convert the
high-rpm, low-torque energy from an engine into low-speed,
high-torque power with hydraulics. The mower we chose is a
Grasshopper 725k. The actual torque isn’t listed in any of the data
sheets, but the horsepower (25) and wheel diameter (22in) are. So now
we just need to find the torque and update our simulation to see if
it will work.

If we know how to find torque then we just need to find
the rpm at the wheels at the top speed, discount it by about 30% for
conversion losses, and that will be near our actual torque.

First, get the top speed to feet per
minute –

Then, turn that to rpm using (the
diameter of the tire) * (pi) to get the ground it covers per
revolution.

Finally, you can do the torque
conversion –

The zero-turn mower is 800lbs, so it is
much heavier. The torque required to haul it up a 15 degree slope is
530 pound-feet, so it might be able to crawl along if it can keep
traction. However, rolling over would be a concern at that angle
anyway. Therefore, the zero-turn is feasible and reasonably meets the
requirements of the project.

We can look into supplementing the power of
the motors with a winch if the vehicle gets stuck somewhere that the
torque/traction can’t overcome and reduce engine noise, but we're in the ballpark now. So, we’ve settled on a design –
a retrofit of a zero-turn mower with a winch. It will be faster and
more cost-effective to retrofit a used device that has been
engineered to a similar task than to design and build something new
from scratch. However, this platform could serve as a prototype for
some future design, so we can work out the issues through iterative
prototyping.

Until then, we’ll do the most
effective and cost-effective Offroad Wheelchair that our constraints
allow and document it so others can duplicate and improve the idea.

Check in on the Offroad Wheelchair page for links and info, including the simulation spreadsheet that I used (you get to point out my mistakes!) and the first video of the mower that we selected.

If you've been following along on my journey to learn electronics design, you'll know I've been working on a motorcycle power supply. It's getting pretty close to finished and its time to do testing. The last series of blogs were about a constant current load testing device. I needed that to test the power supply under different load conditions. This installment is about the opposite end of that spectrum, what happens when the circuit is "off". Because lots of motorcycles tend to be parked for months without being ridden I need to verify that my device does not contribute to early battery failure. To do that I need to measure the current consumed when it is plugged in but off. We are talking about very small currents though so very high precision measurements are required.

Normally, you can use a digital multimeter for this purpose but for measuring small currents this not as straightforward as it seems. Ammeters are connected in series with a circuit and while a perfect ammeter would neither add or subtract anything to the circuit, it would just observe, in the real world ammeters are not perfect. Standard multimeters use a current shunt, or a resistor in series, and measure the voltage drop across that resistor. These designs unfortunately introduce something called burden voltage. This is the voltage dropped across the resistor used for measurement. This can be kept at a minimum by using small resistors but it cannot be avoided with a shunt ammeter. When you try to measure small currents with a DMM you can sometimes get grossly under reported currents caused by the burden voltage of the measurement circuit. 1

An alternate method is to use a feedback ammeter which measures the voltage dropped across the shunt and adds that much voltage back into the circuit. This sounds fancy but in fact is not that complicated once explained. That is my intention today.

Feedback Ammeter

The basic schematic above is the text book model of a feedback ammeter. A current goes into the inverting input (the current is represented here as a voltage in series with a resister which is the text book definition of a current) of an op amp and a voltage whose size is proportional to the input current comes out of the op amp's output as Vout. The burden voltage in this circuit would be the voltage difference between the inverting and non-inverting op amp inputs. Because of how op amps work though, this is almost zero.

This schematic makes it look so easy and I despite my best efforts to build it true to this diagram I failed to find success. The secret sauce is how you power the op amp. In order for me to make it work, I needed a floating power supply and I needed it referenced such that half of the floating power supply's potential was above GND and half was below GND. The wikipedia page 2 offered the tidbit about the floating power supply. With that I was able to get a voltage measurement that was proportional to the current input but there was a DC offset that changed with the voltage applied to the op amps. Dave Jones' uCurrent device's schematic 3 offered the final missing piece which was the referencing the power supply to half the potential. Once I got that figure the circuit was a winner!

The project is finished. The units have been built and sent off for use. Much was learned. Here are some insights.

First, don't design a PCB for the lowest cost. That just increases your costs later. I made the the board narrower than was convenient to save $20 and I ended up wanting to put the entire thing a case so I could mount the banana adapters off the PCB where they could be farther apart. Not necessary but preferred for me.

Second, putting artwork in copper on your PCB not only works but looks great when you are finished. Take a look at the second photo below. That Freeside logo looks awesome!

Third, assembly of through hole components is NOT easier than surface mount parts. It was a bit of a pain to build them all. TH components don't stay in place when you flip it over to solder.

Greetings fellow Raspberry Pi enthusiasts. I have something pretty cool to share with you today. I've been wanting to use the Raspberry Pi for a media center since I first heard about it. When Newark finally told me I could order the Pi I jumped at it chance and then promptly left town on a family vacation. My nephew Isaiah, who I met up with in Alaska while we were on vacation, discussed the media center project and how to implement it. Upon his suggestion we settled on running VLC. I had assumed we would have to get some webserver up and running and figure out how to slave VLC to our wishes but that is largely built in already. It is called the VLC Web Interface (or VLC http interface). That made this project all the more simple.

Below is the process to install it. This process assumes you have a freshly flashed Raspbian Wheezy (7/15) image that has NEVER BEEN BOOTED BEFORE. This made the most sense for us as we assumed you would plop this guy down somewhere and not use it for anything else.

Take a freshly flashed Raspbian Wheezy imaged SDCARD and put it in your Rπ

Make sure your WIFI adapter is NOT plugged in.

Plug in keyboard

Plug in Ethernet cable connected to the Internet

Plug in Rπ

Raspbian will boot up to the setup screen

expand_rootfs

configure_keyboard

Select keyboard that works for you (default is UK which is hard to use with a US keyboard) Images of this process are at the bottom of this post (its sort of long and tedious).

change_locale

change_timezone

ssh

enable SSH Server (not necessary but useful since its headless)

boot_behavior

So NO. You want to disable booting to the desktop

Reboot

Login as root. Type "root" at the login prompt.

Enter the commands below. (downloads and executes an installer script written by my nephew)

Click Y if you want GPIO25 (pin 22) to go HIGH (3.3V) when VLC is playing. Pin 22 is positive and Pin 6 is GND. The numbering system is strange because it starts at 1. You want the third pins from the top and bottom on the outside. Refer to the photo below. SSR available at Amazon.com

Would you like to install rtl8188cus WIFI drivers [y/n]?

This is the driver for the WIFI adapter I selected. Available at Amazon.comThis driver installer was acquired from the Rπ forum and used with permission.

At this point the install actually begins. VLC takes a long time to download and install. Then, if you selected the WIFI drivers it will ask you a bunch of VERY IMPORTANT questions and PROMPT YOU WHEN IT IS SAFE TO INSERT YOUR WIFI ADAPTER. Please read and follow along. I found that if it pauses for a long time while it prompts you to wait for the adapter to blink and connect a quick re-plugging in of the adapter gets the system running again. The WIFI driver script ends asking you if you would like to upgrade your entire Rπ. I say no.

Unplug your ethernet cable (if you are using wifi).

Reboot.

Boot up screen will tell you what the new IP address is on Wifi. make a note of it. You can then use this address to talk to your Rπ from local devices on the network. You can setup a static IP if you desire by going to /etc/networks/interfaces and changing the

You can now find you VLC running at http://*ip address*/. If you want to see if from the actual Rπ you need to go to http://localhost:8080 but we went through the effort of updating the IPTABLES to forward port 80 to port 8080. The /home/pi folder is the default place it looks for music.

The GPIO stuff works by running a script that checks the VLC status stream and turns the pin on or off as necessary. I did this with one long shell command the executes every 300ms. There are no doubt many ways to do this, but I always liked AWK and | so that's how I did it (its below). You can find all scripts we wrote to make this work in the /root folder.

One thing I should mention is that depending on your network speed, you may want to increase the buffering cache so you do not get skips during streaming playback. This is done by modifying the /etc/init.d/rc.local. Add the two caching arguments you see below (to the line starting vlc you'll find it in there somewhere)

I've been working on an Arduino compatible Mini USB Host board. Well, I've had it done for a while now. I've slowly been compiling a bunch of projects for it so I can give it a cool Kickstarter one of these days. To that end, I designed a dedicated shield for controlling a Roomba vacuum with a Wii remote controller so that it might make the entirety of the project more compelling.

I'd already written the firmware and tested it with a chopped and spliced up cable a few months ago. It worked well for a while but one day the entire thing shot craps. My belief is that the on board voltage regulators could not handle the 16V the Roomba outputs (too much voltage to drop with an LDO without good cooling). So, for the dedicated board I decided to put a TO-220 7805 regulator with a heatsink on it. That should protect the main board from damage. I also had the idea of using optocouplers to isolate the Roomba signals from the shield. Optocouplers are ICs that contain an internal LED that turns on when a voltage is applied. That light shines on a photo detector which creates a voltage on the base of BJT opening a channel for current to run. This means two circuits can communicate without having any conductors between them. They isolate distinct circuits in effect. This seemed unnecessary but the board just had enough room and the datasheet gave the impression it would work (foreshadowing).

I built it up and put it together and I got nothing. The multimeter tests I conducted gave me no guidance either. I put voltage on one side of the optocoupler and I get a voltage out on the other side, or so I though. I put it on the oscilloscope and once again learned the value of good tools. The scope showed me that the clear problem was that the optocoupler is slow to respond. It can handle changes at human speeds but not a the speeds I was signalling. The initial speed was something like 300mS to drop off to 0V. That is glacial! The datasheet suggested 3µs was the expected value so I clear did something wrong. I read it closely and saw the RL needs to be 100Ω for that to work like that.

Time for a little rework.

I bodged up the board and got the voltage dropoff speeds into the 25µs range and was hopeful. I plugged it in and ended up with a Roomba that was, well, drunk. It moved slow and listed to one side. No dice.

I grabbed another board from the bag and built up a fresh one wiring around the optocoupler.

It's been a difficult journey, but we finally got the first flight of our DIY Drones Hexacopter. A special thank you goes out to the whole UAV team at Freeside Atlanta for donating their time, money, and resources to this project.

Slade, who did several hours of last-mile troubleshooting to get the UAV in the air, is flying it by hand. Check out the video on Youtube, which shows us testing the pitch, yaw, and roll of the unit and finally getting flight. We were pretty surprised at how smoothly it flies.

Stay tuned, as we'll be setting up and configuring the UAV controls so that it can follow GPS waypoint flight paths. We're also going to be posting another video that explains how everything works, how we did the troubleshooting on the initial flight, and some new in-flight footage.