Quantcast
Channel: The Raspberry Pi Hobbyist
Viewing all 60 articles
Browse latest View live
↧

Problems and Distractions

June 7, 2013, 7:43 am
$
0
0
I haven't been able to post in quite a while - far too many things in real life distracting me.  But now that I have gotten back to hobby time, I am expanding my system with an I2C interfaced GPIO extender.  Everything worked great on the workbench, but refused to work at all once installed.  It appeared that the bi-directional buffer chip that I used to connect the Pi to I2C wasn't working, which made no sense.

I broke down and pulled the interface board down and brought it to the workbench.  Under the magnifier, the problem was immediately obvious.

Soldering is an art.  It takes practice, and I was terribly out of practice when I started this blog (and made this board.)  Bottom line, the SDA and SCL lines were shorted by some over-zealous soldering.  Since I hadn't used I2C, it was never a problem.

I have a feeling I am going to replace this board with a completely re-designed version before too long.
↧
Search

Gotta Know When to Fold 'em

July 13, 2013, 10:52 am
$
0
0
For the past few months, I have burned up a lot of hobby time trying to build an interface to control the Orbit 58874 sprinkler control valve.  These simply connect in-line with standard water hose connectors and cost about $20.  However, they turned out to be quite complicated to control.

The valve connects with two wires.  Sending a 24V pulse in one polarity will cause the valve to latch open.  Sending it in the reserse polarity will cause it to latch closed.  At least in theory.  And, as a wise professor once told me:  "In theory, practice and theory are the same.  But in practice, they sure as hell aren't."

I had a 24V power supply, but it was a little too powerful.  If you leave the valve powered for more than a second, you can burn out the solenoid coil.  After melting one of my H-Bridge motor controllers, burning out several valves, and losing a couple of months, this project was officially no longer fun.

Fortunately, someone else has already gotten this working.  If you are interested in this, check out http://rayshobby.net/ where you can find interfaces to these valves for Raspberry Pi and Arduino.  I may just break down and buy his OpenSprinklerPi interface.

But now it's time to throw in the towel and move on to other projects.



↧
↧

Pulse Width Motor Control

July 13, 2013, 12:23 pm
$
0
0
My last project had me digging through old robotics parts to find an H-Bridge Motor Controller.  I found one that had several TTL chips on the circuit as well and it reminded me of a trick some of you may find useful.

First, lets define pulse width modulation (PWM.)  It refers to the duty cycle (how long the line is high vs how long it is low) of a pulse stream.

A duty cycle of 50% looks like this:


A duty cycle of 25% looks like this:


And 75% looks like this:


What use is this for controlling motors?  If you have ever tried controlling a motor by simply turning it on and off, you quickly realize how little control you have.  Your robot goes from stopped to zooming at full speed with nothing in between.  If, however, you use PWM to power your motor, then it will be on at full power very briefly and then off, repeatedly.  With PWM you can provide much finer motor control and have your robot move at whatever speed you like.  The higher the duty cycle of the pulse stream, the more power your motor will output.

There are several ways to produce PWM signals from the Raspberry Pi.  The simplest is to turn a GPIO pin on and off in a loop with delays controlling the pulse width.  This is very CPU intensive and not always consistent.  You can use libraries or device drivers to produce PWM from the GPIO that will be consistent and will use virtually no CPU.  Or, you can use external hardware to produce PWM.

Here is how I have done it in the past. (I haven't built a robot using a Pi yet, but did it with simpler microcontrollers years ago.)  Use six GPIO pins:

  • Enable (motor is on or off)
  • Direction (forward or reverse)
  • Power 0
  • Power 1
  • Power 2
  • Power 3

The four power bits control the duty cycle of a pulse stream and allow 16 different power levels.  Below is a block diagram of the circuit I used to do this.
I used a 555 chip for the pulse generator, a 74161 counter, and a 7485 comparator.  Other chips can be used to achieve similar results.  I built my own H bridge circuit back then, but I recommend checking out some of the motor controller chips available now, such as the SN754410 chip.



↧

Running From an External Hard Drive

July 23, 2013, 2:51 pm
$
0
0
The SD card of the Raspberry Pi is required for booting.  While you may not be able to boot from an external hard drive, moving the / partition there will significantly speed up the Raspberry Pi.  There are many uses where this configuration particularly useful.  File servers and media servers are good examples.  I need a system like this for a MySQL database server.


There are a number of variations to the process, but basically, the steps are:
o  Install OS on SD Card and boot 
o  Plug in external hard drive
o  Partition and Format hard drive
o  Copy system to hard drive
o  Mount the new system and modify configuration to use the hard drive
I decided not to re-invent the wheel.  The following instructions are just my variations on the instructions provided by Rattus here: 
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=10914&p=129474&hilit=resizefs#p122476  
Note about the sudo command:  All of the following must be done as root.  You must put sudo before each of the commands.  Or, you can follow the (not recommended, bad practice) habit I have and just enter sudo bash to run a shell as root and skip saying sudo all the time.
Load SD Card with Raspbian in the usual way.Update the system software and firmware with the following three commands.  This can take quite a while to complete.
apt-get update
apt-get upgrade
rpi-update
reboot

List the partitions  This should show only the /boot and / partitions on the SD card.
fdisk –l

Plug external hard drive into USB and list the partitions again.  This should show another HD probably at /dev/sda

Modify the partition table for the external drive.   
fdisk /dev/sda
Delete partitions by entering “n” and then the number of the partition to delete.  Delete all the partitions.  Entering “p” will list the partitions. 
At this point, you have a few options.  
a)  Create a single partition and move the root there.  This will leave the swap file on the SD card.
b)  Create a root partition that fills most of the drive and a small swap partition.
c)  Create a partition for the OS, a small swap partition, and a large partition for application data. 

I am using the third option.  The following instructions are fairly easy to change to use one of the other options.  While still in the fdisk program, do these steps.

- Create the root partition:  I made mine 16GB.  Enter “n” to create a partition, “p” to select primary partition and then “1” to select partition number one.  Select the default start sector.  Enter +16G to specify the size.  
- Create the swap partition:  Enter “n” to create a partition, “p” to select primary partition and then “2” to select partition number two.  Select the default start sector.  Enter +2G to specify the size.  Enter “t” to set the type of a partition.  Enter “2” and then “82” to make this one a swap partition. 
- Create the data partition:  Enter “n” to create a partition, “p” to select primary partition and then “3” to select partition number three.  Select the default start sector and default end sector to fill up the rest of the disk.  
- Enter “p” to list the partitions and verify things are like you expect. 
- Enter “w” to write the new partition table and exit.

Create (format) the data partition with an EXTv4 file system.  This command takes a few minutes to finish.  There is no need to format the first partition since we are going to do a raw copy of an existing file system over it anyway. 
mkfs.ext4 /dev/sda3
Initialize the swap partition 
mkswap /dev/sda2

Copy the second partition of the SD card to the first partition of your hard disk (mmcblk0p2 may not be correct for you see the output of fdisk earlier.)  This also takes a while.
dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=32M conv=noerror,sync

Check the file system for errors.  Press “y” if any errors are found.
e2fsck -f /dev/sda1

The file system that was copied still looks like a small one to the system.  Do the following to re-size the file system to fill the partition.
resize2fs /dev/sda1

Use your editor of choice (I  use vi) to modify the boot configuration to use the new root partition.  First make a backup copy.
cp /boot/cmdline.txt /boot/cmdline.orig
vi /boot/cmdline.txt
Change  /dev/mmcblk0p2 / to be   /dev/sda1

Change the mount configuration file on the new root.  It has to be mounted first. 
mount /dev/sda1 /mnt
vi /mnt/etc/fstab
Change the root device  /dev/mmcblk0p2 /   to be  /dev/sda1
Add /dev/sda2  as  a swap partition by adding this line.
/dev/sda2    none      swap    sw           0       0

Finally, stop the system from using the swap file that it normally uses. 
rm /etc/rc2.d/ S02dphys-swapfile

Flush the disk and reboot.sync
reboot

The Pi should now be running from the external hard drive.  If it fails, use another machine to 
copy /boot/cmdline.orig   to  /boot/cmdline.txt  and then reboot again.

One problem that some people have run into is controllers that take too long to complete the USB discovery.  This can be compensated for by adding delays in the /boot/cmdline.txt file with the bootdelay and rootdelayoptions.
↧

Solid State Relays

January 14, 2014, 9:53 am
$
0
0
I find solid state relays (SSR) very convenient, especially for controlling AC power lines.  They typically include opto-isolation and zero crossing detection (explained later.)  Also, they can be controlled with as little as 3V.  This means that you can connect them directly to a GPIO pin. However, I still prefer to put a transistor in between to prevent drawing too much current from the GPIO.

All these features do come at a price.  The typical SSR that I use costs about $10.  PC board mounted SSRs that handle small current can be as little as $1 each.  The 40amp SSRs that I used to control the heater for my hot tub cost about $25.  (I will describe that project in a later post.)

There is an important point you need to know about when using SSRs - the AC and DC versions are not interchangeable.  When switching AC current, the relay should only turn on or off when the voltage is at zero during the AC cycle.  This is what "zero crossing detection" does and it prevents a large surge from entering the device you are controlling.  I have used a DC SSR to control a lamp and blown the bulb due to the lack of zero crossing detection.  Also, if you use an AC SSR to control a DC load, it will turn on just fine, but it will never turn off since the SSR never detects the load voltage crossing zero.  This has confused many a hobbyist and now you won't be one of them.
↧
↧

Fail-Safe Circuit Using Discrete Logic Chips

January 15, 2014, 12:16 pm
$
0
0
When controlling a device that can present a danger to people or property, it is important to include adequate safeguards, in both software and hardware.  I now have a Raspberry Pi controlling the heater and circulation pump on my hot tub because the existing controller failed.  If the heater is left turned on indefinitely or if it is turned on without the circulation pump running, then bad things can happen.  It could produce scalding hot water or even a possible steam explosion.  Therefore, I have built in multiple safeguards in both software and in hardware.

The system has two temperature probes:  one in the water and one directly on the outlet pipe from the heater.  If the software detects the heater temperature above a certain point it will enter a failure mode and turn the heater off.  The software also assures that the circulation pump runs whenever the heater is on.  The hardware interface uses discrete logic chips to add an additional layer of protection.  An “and gate” is used to prevent the heater relay from being enabled if the pump is not also enabled.

Another more complex circuit solves another problem.  The software or the computer hardware could fail, leaving the heater turned on indefinitely.  A “clock failure detection” circuit is used to handle this issue.  For the heater relay to remain turned on, a GPIO pin must be pulsed regularly.  If this “heartbeat” is not detected, then the failsafe circuit shown below will turn the relay off. 

555 in astable mode which produces a pulse every 2.079 seconds.
Here are the components used:
  • A clock source, provided by a 555 chip configured in astable mode, produces a pulse approximately once every two seconds.  Many sources on-line describe how to use this very common chip.  My configuration is shown here.
  • An AND Gate, which does exactly what its name implies.
  • An inverter, which changes a hi signal to low and a low signal to high.
  • Four D-flops, which can be thought of as a single bit memory device.  A D-flop will store the value on its data input line when the clock line is pulsed.  It can also be set to one or cleared to zero using the PRESET and CLEAR inputs.  These are active low, which means they should normally be kept high and briefly set to low to activate the preset or clear function.  The Q pin is the output.  An inverse of this is also provided but is not used in this circuit.

Here is the complete block diagram of the fail-safe circuit.

Fail-safe circuit


I used TTL (5V) chips because I have a stock of these from long ago. 
  • 555 – Monostable/Astable timer
  • 7404 – Inverter (six on one chip)
  • 7408 – two input AND Gate (four on one chip)
  • 7474 – D-Flop (two on one chip)


Today it may be more appropriate to use CMOS (3V) chips and equivalents to the TTL chips I used can easily be found.
↧

Interface to Wireless Driveway Sensor

January 21, 2014, 7:10 am
$
0
0
I have a driveway that is over 300 feet long and it is nice to have some advance notice that someone is driving or walking in.  Previously, I have used a very expensive IR beam-break detector.  It gave a lot of false alarms and eventually failed due to a lightning strike.  It also required that I run a very long cable that could survive outdoors, which added more expense.  It’s time to switch to a wireless sensor.

I found this inexpensive one at Harbor Freight ($17 with coupon.)  It is a simple, stand-alone alarm with a receiver that just flashes some LEDs and emits a tone.  It claims to work up to 400 feet and I verified that it works to at least 350 feet, which is good enough for my application.  I created the circuit described below to interface this to my Raspberry Pi based home alarm system.

The receiver can use 3 C-batteries or a 6V adapter (not included) and I found that it would work fine on 5V.  The simplest way to get a wired signal out of the receiver is to connect to one of the LEDs.  This picture shows how I soldered a wire to the positive side of the LED.

This will provide a very brief pulse of 5V, but I need to simulate a normally open switch that connects to ground when triggered.  Also, that signal needs to lasts for at least a second to guarantee that the Raspberry Pi will see it when polling the GPIO states.

I use a 555 timer IC in monostable configuration to provide the longer pulse.  The 555 is triggered by a low pulse, so I also need an inverter.  I chose a 7404 IC because I have a stock of these reclaimed from salvage many years ago.  The output of the 555 is a high pulse that lasts 2.2 seconds with the capacitor and resistor values in this circuit.  This is used to control an NPN transistor that will provide a connection to ground as the signal output.


This circuit uses three wires to connect to the wireless receiver to provide power and read the LED state.  Put it all into a project box with some screw terminals and it is ready to connect.  I will find out over the next several days how reliable this motion detector is.  I am sure it will trigger when any deer come by it.  I am hoping that it doesn't produce a lot of false alarms.  Otherwise I will probably end up disconnecting it.


Here is the interface circuit connected to the receiver.  The white wire on the receiver is the antenna.




And here it is all put together.
↧

Stupid Simple Tip #1

February 16, 2014, 9:13 pm
$
0
0
A rubber band and a pair of pliers make an quick and easy clamp for holding components while soldering.


↧
Search

Stupid Simple Tip #2

February 16, 2014, 9:16 pm
$
0
0
The body of an old ball point pen can be easily made into a standoff of any size.  And it's hard to beat the price.


↧
↧

Stupid Simple Tip #3

February 19, 2014, 10:46 am
$
0
0
The ribbon cable connector used for floppy disk drives on PCs can be used as a GPIO connector.


They are larger than than the Pi GPIO connector (34 vs 26 pins) so they overlap some.  These are cheap (free if you have old PCs to scavenge from.)  One problem - they won't fit in a case made for the Pi, but I have used them in cases that I built that held the Pi as well as other hardware.  If you do use this cheapskate trick, I recommend trimming the unused lines from the ribbon cable to prevent confusion.  It is also a good idea to plug the unused holes on the connector so that you don't accidentally plug it in wrong.
↧

Stepper Motors

February 20, 2014, 9:54 am
$
0
0
Stepper motors are unlike ordinary motors.  A simple motor will spin when current is applied to the coils.  Reverse the polarity of the current, and the motor spins in the opposite direction.  Stepper motors, however, contain multiple coils which can be energized individually to provide precise "stepping" of the motor.

This precise control makes them perfect for a variety of applications.  They are commonly used in floppy drives, hard drives and CD/DVD drives to precisely control the speed that the disc turns as well as where the read/write heads are positioned.  They are also used in scanners to position the scanning optics and in ink jet printers to move the paper and position the print head.  Any application that requires precise positioning is likely to use stepper motors.

For more details on the many varieties of stepper motors, see the following pages:

http://en.wikipedia.org/wiki/Stepper_motor

http://www.engineersgarage.com/articles/stepper-motors

Quick Start for Beginners - http://www.freescale.com/files/microcontrollers/doc/app_note/AN2974.pdf

Stepper Motor Basics - http://www.solarbotics.net/library/pdflib/pdf/motorbas.pdf

There are two basic methods for controlling a stepper motor.  One is to use an IC specifically designed as a stepper motor controller.  The other option is to use a microprocessor (the Raspberry Pi, in this case) to directly control the individual coils of the stepper motor.  This is the method that I demonstrate in the following video.




The code for the program used in this demo follows.


↧

Server Box with Utilization Displays

March 6, 2014, 2:02 pm
$
0
0
A while back I built a server with the system root moved to an external hard drive.
Blog Post - Running From an External Hard Drive

That system has now failed. I shouldn't be surprised since it was built with very used parts. I decided to rebuild it and put it into a nice enclosure this time, rather than just having parts all stuck together. I also decided to add LED bar graphs to show CPU and I/O utilization.



The first step was to build the LED interface. This was accomplished using two 10-segment LED bar graphs and a GPIO extender. The GPIO extender is needed in order to drive all 20 LEDs. I used a MCP23017 I2C GPIO extender which provides 16 GPIO bits. Another 4 GPIO bits were taken directly from the Raspberry Pi.

The LED board is shown here before the GPIO lines were attached.



The next step was to attached the LED board and a Raspberry Pi to the top of the case.  The LED board is attached using epoxy with the LEDs showing through holes cut in the plastic case.  The Pi is attached using
plastic offsets and machine screws.

Notice that the analog video output connector has been removed from the Pi.  The case was just a little to tight a fit for it to work with that in the way.

A power connector will supply 5V to the LED board and to the USB hub and will use the power supply that was included with the hub.  The Pi is powered through the GPIO pins.

A hard drive salvaged from an old laptop is placed in the bottom of the case.  It is connected using an IDE to
USB adapter.  The USB cable is fed out of the case and then back in to the USB hub.  This part is a little odd, but is the only way I could get it to fit in a case this small.







Here, the power connector has been  mounted, the USB hub has been added, and all other connections have been made.  It's time to squeeze it all inside this plastic enclosure.












Here are a couple of pictures of the completed server.


















Below is a video which shows how the utilization LEDs look in action.


↧

Stupid Simple Tip #4

March 16, 2014, 6:08 am
$
0
0
Murphy was an optimist. I have repeatedly had problems with USB cables.  USB cables are held in place only by the friction of the connector.  Repeated insertions and removals WILL wear out a USB connector.  Anyone with an old laptop has probably encountered this problem.

Another problem is in systems that get moved around a lot or are subjected to a lot of vibrations.  Here is what I did to eliminate this problem in a recent project.  Zip ties are wonderfully useful.



↧
↧

Automated Home Brewing

March 20, 2014, 7:42 pm
$
0
0
Brewing Controller User Interface
I have been a “home brewer” in the electronic hobbyist sense for decades, but I am also a “home brewer” of beer.  I mentioned this in my post on Reading Temperature With Thermistors.

I now use digital temperature sensors (typically the DS18B20) read over an I2C bus.  Adafruit has a good tutorial on how this is done located at http://learn.adafruit.com/adafruits-raspberry-pi-lesson-11-ds18b20-temperature-sensing/overview

It is fairly common to control a refrigerator and heater to keep a constant (or slowly changing) temperature during the fermenting process, especially with lagers.  I have done this using the Raspberry Pi, thermistors, and an A/D convertor.  Now, I decided to get a lot more ambitious.

I won’t go into all the details of the brewing process since there are many resources on the web to provide that.  For a quick look at this process, see the article on my photo blog.  I wanted to be able to control at least the following items for one of the simpler methods of brewing (called partial mash.) 

  • Valve to a tank of propane
  • Grill ignitor to light the burner
  • Sensor to detect if the burner actually did light
  • Temperature sensor for the wort (the brew of water, malt extract, and hops)
  • Pump for circulating water through the wort chiller

What I needed to do this:

  • A relay to output 12V to control the propane valve
  • Another relay to output much higher amperage of 12V to run the pump
  • A relay connected in place of the button on the grill ignitor
  • A connection for one or more DS18B20 temperature sensors

The hardware is described below.  I also wrote software for the Raspberry Pi (in C, my language of choice) to manage this hardware and the brewing logic.  C# .Net provides the user interface on a Windows laptop. That is the image at the top of this post. The laptop and the Pi communicate via socket calls over wifi.

There were three major problems that had to be overcome once I started testing.  One is that I tried using a DS18B20 to detect the flame.  Well, the maximum for that sensor is 125°C and I did not use a high temperature version.  The flame is VERY hot (duh!) and the sensor eventually melted, shorting 5V to ground and shutting down the Pi.  Fortunately it was not damaged.  I doubt changing to a high temperature version will help, but I will try that next.  Another option is to do what every furnace, stove, and hot water heater does for its pilot light – use a thermocouple to detect the heat.  I may have to investigate this to see if I can devise a simple interface for one.

The second problem was that the wiring for the ignitor kept shorting out and creating a spark too far from the flame to light it.  Additional insulation and a change in how it was mounted solved this problem.

The third problem was that the EMI created by the ignitor caused massive interference on the I2C bus that made it unusable.  This was corrected by re-wiring my temperature probes with well shielded cables.  I used shielded audio cables commonly used for microphones.  I am also a musician so I had some of this already.  If you have to buy a small reel you may find that it is rather expensive.  Cat-5 cable may also work well.  That is what I use for my hot tub controller, but it is not subjected to the massive EMI of this system.

I disabled the flame detection logic. This is a critical safety feature and must be corrected for this system to be trusted. However, this did allow me to successfully use this system to brew.

This is a good place to state that working with flammable gas and boiling liquids can be hazardous.  I take no responsibility for your use of the advice provided in this post. BE CAREFUL!  And drink responsibly.

Hardware

Control of all of the above components is pretty straight-forward.  Search my blog or the web and you will find how to control relays.  The Adafruit link above will show you how to connect the I2C temperature sensors.

I used audio connectors since they are cheap and readily available.  ¼ inch mono for the relays and stereo for the I2C bus.  Using an audio connector for the I2C bus gives the added benefit of being able to use pre-made splitters and extension cables and these tend to be well shielded and relatively inexpensive.


The 5V line from the GPIO connection is only used for the I2C bus.  I already required 12V (which is actually 13.8V) for the valve and pump.  However, the relays I used were controlled with 5V.  This voltage does not need to be accurate, so I made a simple voltage divider using three 100Ω resistors.  Two 100Ω resistors are used for R1 and one 100Ω resistor is used for R2.  This divides the input voltage by 3 to provide 4.6V, which is adequate to control the relays.





The final interface box looks like this. The red and black power connector you see is called an Anderson Power Pole.  I chose to use this since I already have 12V supplies for my HAM radio equipment.  (I think maybe I have too many hobbies.)





Modified Grill Ignitor

The ignitor can be found in many hardware stores as a replacement for repairing gas grills.  The cheaper versions of these use a spring and a piezoelectric voltage generator to create the spark.  These are not suitable for this application.  You must get the more expensive type that uses a battery.  I removed the push button and made my own connection that runs to the relay in the interface box.

I still have a few kinks to work out in this system, but I am sure that this automation will make the process of brewing much easier and more consistent.  This is definitely the most enjoyable project that I have done so far with the Raspberry Pi, and that is not just because I end up with great beer.

The system set up for brewing

The temperature sensor is a water-proof high temperature DS18B20 covered in food grade shrink tubing.  These are available at Adafruit.com







Here, the system is set up for chilling the wort.  
The cooler has water and 10 pounds of ice cubes.
↧

CPU and I/O Utilization Display - Details

March 30, 2014, 12:17 pm
$
0
0
In the  post Server Box With Utilization Displays I showed a system which displays CPU and I/O utilization in real time.  If you are using the Raspberry Pi in GUI mode, then there are numerous tools to display this type of data on your screen, such as gnome-system-monitor or Conky.

However, when the system is used in an embedded mode (sometimes called head-less because it uses no monitor) you need alternative methods for tracking this information.  I sometimes will open an SSH connection and use shell utilities to provide this information.  Some of the options are: top, mpstat, iostat, and sar. 

I really wanted the “lots of blinking lights” effect for my server, so I developed the software below to provide that. The basic concept is to periodically (once per second, or more) read files in the /proc and /sys file systems to collect data and then update banks of LEDs appropriately.

CPU Utilization

The file /proc/stat provides a lot of information about the system, including CPU utilization.  The first line is a total for all CPUs in the system.  This is followed by lines for each individual CPU.  For the Raspberry Pi, reading the first line is all that is needed.  There are four values that we will be interested in:

  • User mode CPU time – this is the time the CPU spends running programs that are in user mode at standard execution priority.
  • Nice mode CPU time – this is the time the CPU spends running programs that are in user mode at a priority other than standard.  See the nice command for more info on this.
  • Kernel mode time – this is the time the CPU spends running in kernel mode.  This is the protected mode that the operating system uses.  This will include things such as device drivers and system API calls as well as the core OS itself.
  • Idle mode CPU time – this is the time the CPU spends doing nothing.

These values will be constantly updated, so the utilization program must track the changes over time.  It will store the values each time it computes CPU utilization and compute the change for each.  The CPU percentage utilization will be 100 x (user + nice + kernel) / (user + nice + kernel + idle)

I/O Utilization

The file /sys/block/DEVICENAME/stat provides information about the specified DEVICENAME.  The device sda is my external hard drive but you may want to use mmcblk0, the SD card.  I decided to keep this simple and only track the number of sectors read and written.  Like the CPU data, this data is constantly updated, so the change over time is what is tracked.  One difficulty with I/O utilization is that the program has no way of knowing what value 100% should be.  I provide a function to set this value, but you can simply let the program track it dynamically.  100% percent will always be the maximum usage seen so far.

Displaying the Utilization

The next challenge is to display this data.  If your system has an LCD display, you could just show the percentages directly.  Alternatively, you could make this data available via a web interface.  I chose to use 10-LED bar graphs controlled via GPIO.  You could use a single LED that lights up when a threshold is passed.  You could use 10 separate LEDs, but the multi-segment LEDs are easier to connect and take up less space.  A good compromise might be three LEDs to indicate low, medium, high and very high utilization.  The software below supports 10-segment LED displays.  I will leave the other options as an exercise for the reader.

Software

The software I am using can be obtained from google code using the git command.

git clone https://code.google.com/p/raspberrypi-utilization-display/

See the included README file for further instructions.

If you just want to browse the source code, you can do that at this address:
https://code.google.com/p/raspberrypi-utilization-display/source/browse/

This is still a very rough version of the software but should still prove useful to some.  In the future I hope to add a configuration file that will define the update rate, the number of LEDs to use, and what GPIO pins the LEDs are connected to.
↧
Search

Schematic for Analog Interface

April 4, 2014, 8:36 pm
$
0
0
A commenter asked for the schematic of the analog interface I made using an MPC3008.  I seldom include schematics with my posts for several reasons.  I don’t expect anyone to duplicate exactly what I have done, so if I post anything, it is just partial drawings of the most important concepts.  But the biggest reason is that I almost never create true schematics and I am too busy to do it just for the blog.  Something that I do frequently do is a simple drawing that helps me lay out the components onto the perf board.  Then I use that as my guide when I build the device.  These are seldom complete enough to be useful to others.  In this case, however, the entire circuit is shown.


This is what I created for the analog interface.  The 7-pin header connects to my main circuit board where I have two SPI ports – one with CE0 connected and the other with CE1.  The 3-pin header allows me to select the reference voltage for the MCP3008.  The blocks along the bottom are screw terminals.  See the post Analog Interface for a picture of how this looked when built.

I will probably be pulling this old board out again to experiment with a thermocouple that I just received.  I need it for the flame detection on my Home Brewing Automation setup.

↧

Interface to the Internet of Things with SkyNet

April 25, 2014, 8:47 pm
$
0
0
The Internet of Things (IoT) refers to the many servers that store data uploaded from various devices (things) connected to the Internet, which can range from weather stations, to home appliances, or a farm animal with a biochip transponder.  Even dancing robotic quad choppers.

There are many services that provide IoT support.  After experimenting with some, I settled on the SkyNet.im IoT server.  It provides several simple ways to allow machine to machine communications, including MQTT, REST, and WebSockets.  There are Python and JavaScript libraries to support it.  The API for SkyNet is fairly simple, as is using the REST protocol.  With thecurl utility, you can interface to SkyNet from shell commands.

First you need to install the curl program and since I will also be calling this from a C program, I also need the development support.

sudo apt-get install curl libcurl4-gnutls-dev

To create a new device on Skynet, issue the following command (changing the parameters as you see fit)

curl -X POST -d "type=raspberry-pi-example&myvariable=12345" http://skynet.im/devices

SkyNet returns a UUID and a security token.  Save this info.  The device id is used to identify the new device and the security token allows a little security so that only someone with the token can update the data for this device.  If you really need to maintain security for the device, be sure to always update it using HTTPS.  If you use HTTP, then the session is not encrypted and someone could intercept the token and use it themselves.  Also, be aware that anyone can read your data.

To update the data for the device, issue this command.  (All one line.)

curl -X PUT -d "token=PUT-YOUR-TOKEN-HERE&myvariable=5678online=true" http://skynet.im/devices/PUT-YOUR-UUID-HERE

To view the data for a device, issue this command.

curl –X GET http://skynet.im/devices/PUT-YOUR-UUID-HERE

The function listed below provides a simple interface to SkyNet, in C, using libcurl.




↧
↧

Flame Sensor Update

April 28, 2014, 6:33 pm
$
0
0
This is a follow up to the post on Automated Home Brewing.  There were several good ideas in the comments to that post about how to create a flame sensor.  Some require an analog input, which I describe in this post.  I have experimented now with a few methods for detecting a flame and here is what I found.

Plasma Conductance

Cool Fact - flame is a plasma and will conduct current.  I tried using two wires stuck into the flame.  The flame has a fair amount of resistance.  One of the wires was connected to 5V.  The other was connected to a voltmeter.  There were dozens of mV present when the flame was on and zero when it was not.
I think this could be used with an analog input as a flame sensor.

Thermocouple 

Thermocouple
I got a type K thermocouple and tested that directly with a voltmeter.  It only show a couple of mV with a flame on the tip.  I added a simple 100X amplification circuit and connected that to the analog input.  Now I see a range around 300-400mV and see a clear increase when the flame is on it.  One problem I saw is that the sensor has a fair amount of mass, mostly stainless steel.  Once it heats up, it takes a while for it to cool off.  As long as there is a distinct increase when the flame comes on, this could also be used for the flame sensor.
100X Amplification Circuit for Thermocouple

Digital IR Flame Detector

IR Flame Detector

Sensors are available that detect the IR signature of a flame.  Most of these provide analog output only, but I found some that also include a digital output.  This is provided by a built in level compare circuit with an adjustable level.  Because this method is so simple to interface with, this is what I decided to use.  One big problem quickly became apparent - the sensor is triggered by incandescent lights and sunlight.   It worked fine under florescent lights.




I was successful in using this configuration for brewing.  The IR sensor works, but has the false trigger problem.  It works for me but won't work in many environments.  My plan is to rebuild the brewing interface with analog input capability and try one of the other methods.

IR sensor mounted on a small block of wood and placed under the flame.




↧

Improved Home Brewing Controller

October 29, 2014, 9:27 am
$
0
0
This post is an update to my Automated Home Brewing post. See that post for more details on the project. After adding some new features haphazardly, I had an ugly conglomeration of old and new parts. It worked, but it wasn't pretty, and I sure didn't want to show it on this blog. So, I decided to build a whole new interface and include the new items:
  • thermocouple interface for flame detection
  • relay control for refrigerator
  • relay control for heater (these two are used for controlling lagering temperature during fermentation)
  • digital input for counting the bubble rate in the airlock during fermentation.
  • battery level monitor, since I usually run this on a small 12V battery
I also kept all the original controls:
  • relay for propane valve
  • relay for igniter
  • 1-wire bus for multiple temperature inputs
  • relay for circulation pump
The item that I struggled with the most was how to make a reliable flame sensor. This is covered in the Flame Sensor Update post. Note - the drawing for the amplifier circuit in that post has the resistor values reversed. Here is the corrected drawing.

The gain formula for a LM358 non-inverting circuit is

               gain = 1 + R2/R1

In this case, R1 = 1K and R2 = 200K, resulting in a gain of 201. This means that a thermocouple output of 5mv will produce an output of just over 1V. Using a gain of 500 would allow for better resolution of the temperature, but 200 is adequate for this purpose. I don't care about the actual temperature. I just need to see if the value is increasing to verify that the flame actually lighted.





I decided to build the interface on a circuit board that would plug directly into the GPIO pins on the Raspberry Pi and mount it with a Pi permanently in a project box. Here is the completed circuit board, in its enclosure, installed on the Raspberry Pi










Here is the project box with the Pi mounted inside. There are holes cut for the USB, network, and HDMI connections. I like this arrangement a lot and will use it again in the future.












Finally, this is the completed system with all the connectors labelled.








The "bubble detector" input was a last minute addition. I haven't actually built the detector yet but the design is straight forward. It will use an infrared LED and detector (sometimes called an IR gate) to see when a section of the airlock changes from water to air. Water is mostly opaque to IR light.

The pulses from the bubble detector will be very short and difficult to accurately count using a simple polling loop. I expect that it will need to be done using GPIO interrupts. I will post the code when I get that working.

Monitoring the "bubble rate" won't really produce any useful numeric data. It is only good for determining when the fermentation has completed. This is important since fermentation can stop early for various reasons and steps must be taken to correct the problem.

Finally, a warning: Working with flammable gas and boiling liquids can be hazardous. I take no responsibility for your use of the advice provided in this post.
BE CAREFUL!  And drink responsibly.



↧

Debouncing GPIO Input

November 16, 2014, 4:29 pm
$
0
0
Reading the state of a GPIO pin is very simple.  There are several methods to do this.  But what if you need to detect a very short pulse on a GPIO line or you need to respond very quickly to a state change without using a lot of the CPU to poll the state of the pin? This is exactly what interrupts are designed for.  I will cover how to use interrupts in a future post.  This post will show you how to deal with a common problem that must be addressed before interrupts will work correctly.

When the contacts of a mechanical switch close, they will almost always bounce a little.  This causes multiple spikes up and down on the connected line until the contact is firmly made.  The result is a series of pulses when a single state change was expected. This is, for obvious reasons, called "bouncing" and must be corrected either with hardware or software.

If that wasn't clear enough, maybe a picture will help. Imagine a push-button connected to a GPIO line. When the button is not pressed, a pull-up resistor holds the GPIO at 3.3 volts so that it reads a value of 1.  When the button is pressed, the line is connected to ground and the GPIO will read 0.  But on closer inspection, something else really happens. As this graph shows, the bouncing of the voltage level causes spurious state changes to the GPIO input. If you use an interrupt to increment a counter when the state changes on the GPIO, then a single button press can result in the counter incrementing two, three, or more times when the programmer is expecting only a single increment.

This can be dealt with in software, but that method tends to be unreliable in many instances. It is much better to correct for the bouncing using a simple hardware circuit.  This is called debouncing and one simple solution is shown below.

By connecting a capacitor as shown here, the result is a "smoothing" of the voltage curve. Before the button is pressed, the capacitor is fully charged and the GPIO will read 1. When the button is pressed, the capacitor will start draining through R2 at a rate determined by the size of the C1 and the R2.  The voltage on the GPIO pin will smoothly curve down from 3.3V to 0V and the GPIO will sense a single state change.

The values for C1 and R2 will determine how quickly the state changes.  If they are too small, then there could still be some bouncing.  If they are too large, then the circuit may respond too slowly for the application needed.  This could result in state changes being missed. You may need to experiment to find the proper values for a specific application. The values shown in this circuit are a good place to start.

A digital circuit that is also commonly used for debouncing is called the set/reset latch and can be constructed from two nand gates. To learn more about this option and everything else you might want to know about debouncing, read this paper.   A Guide to Debouncing

Now that you input is properly debounced, you can go on to using it to reliably drive an interrupt.

↧
Viewing all 60 articles
Browse latest View live
Search