HAL's Hangout

Rain Barrels - Part V(b) - We've Got A Leak

2010-06-19T08:27:00.002-05:00

Checked the barrels early this morning. The water level looked to be almost exactly where it was last night. While I was pondering what the odds were that the rain had stopped exactly when I'd taken that last picture, I heard it:

~Thwup~

Then, about fifteen seconds later:

~Thwup~

Yep, it was the sound of water falling onto a piece of cardboard. I took a quick look and it seems to be coming from one of the bushings where I used the Extreme glue. I'm going to have to pump the water to below the hose level and then slather some Goop on - hopefully that will do the trick.

Rain Barrels - Part V(a)

2010-06-19T00:20:00.003-05:00

It's been about three and a half hours since I took the last set of pictures. It hasn't been raining much anymore (the occasional bout of drizzle) but I thought I'd go take a look at the barrels just before I went to bed. This is what I found:
I thought the Sharpie had worn off until I noticed that the interconnect was now under water. If you look on the left hand side, you can still see the Sharpie line from earlier, it's now well below the surface!

A quick check in the other two barrels and it looks like the water levels are up in all three of them (obviously, it'd need to be up in the middle one)!

So, if there are any leaks, it looks like they're slower than the rate that water is going into the barrel right now. The grey fuzz that's floating on the water is plastic shavings from cutting holes in one of the other two barrels - it must have migrated over through the hose.

I'm hoping it's coincidence that the water is at the level of the spigot, and not that the spigot is leaking or open right now. It's too dark to check, I'll look at it in the morning.

Like I said, the rain hasn't been coming down in sheets or anything - more just a gloomy drizzle than anything. If the water has risen that much in less than four hours from that kind of rain, I'm pretty sure the overflow is going to get some exercise when it rains hard!

Rain Barrels - Part V

2010-06-18T21:22:00.007-05:00

It rained all day again today. There was a bit of a lull this evening where it had slowed down to a drizzle, so I took advantage of it and went out to get some work done.

First thing was to move the barrels into a mock-up of where they were going to go. That showed me that I'd cut the interconnect hoses too long - easy enough to fix. With the hoses shorter, I slathered some Goop on the exposed ends and stuck the hoses on, then tightened the pipe clamps.Then out came the hacksaw and shears and I cut the downspout about five feet off the ground. I slid the lower section down a bit but kept it on the side of the house in case something doesn't work and we need to go back to the old stuff quickly. I screwed a plastic formable elbow (think of the bendy part in a bendy straw) to the downspout, then bent it and screwed the piece that used to direct the water away from the house to it. Not pretty, but it's been working for, oh, 40 minutes so far.

After the downspout was done, Mrs. HAL helped me shuffle the barrels into position. The ground was making sucking squishing sounds each time we stepped and when we were done, the barrels weren't exactly level. By this point I was wet and what seemed like every mosquito in the world was flying around me, waiting for their opportunity to bite so I didn't really care that the barrels weren't perfectly level.So, with the hoses on and the barrels in place, Mrs. HAL and I hauled over the two garbage cans we put out last night to collect water off the garage roof. We poured them into the centre barrel just to see what would happen. We were rewarded with happy gurgling in stereo - the water was flowing into the outer two barrels:
While I had the camera out, I grabbed a picture of the middle barrel:
It sounds silly, but it was great to see water moving between the barrels.

The next thing to take care of was connecting the overflow hose. Unfortunately, the hoses that come with the barrels aren't very long, so I used the overflow "T" from one of the outside barrels, some electrical tape, and a nitrile glove to connect the two hoses together - this made it just long enough to reach the front yard:
Having the overflow hose out on the front lawn (even if it's just a little ways out) will help lessen the swampiness at the back and side of the house. With luck, more than moss and weeds will grow there someday...

The wet conditions made it impossible to check for leaks so I grabbed a Sharpie and drew where the water level was when we finished up today:

If everything works the way it should (and if it keeps raining) the water level should be way up in all the barrels tomorrow morning. If not, I'll have to fill the barrels up well past the hoses and watch them for a few days. If, of course, it rains like stink tonight and the barrels are exactly the same tomorrow, then I'll know there's a problem. Here's where the water was at in the middle barrel when we finished today:
And a picture of the whole setup. You can see the overflow and interconnect hoses:
Assuming there are no leaks in the system, we've got a usable rain barrel setup right now. It doesn't have any fancy stuff, but we can still pull water out of it for a watering can or bucket. The only things I need to do are get some longer overflow hose so I can put all the parts back where they should be, and close up some of the other holes in the barrel (where the pump is going, etc.) so mosquitoes can't get in (or out).

The next job is to finish up and test the electronics, then figure out how to get them outside and safe from the elements.

This has been an enjoyable project so far.

(I probably should have waited to see if there were any leaks before I said that, but what the heck.)

Rain Barrels - Part IV

2010-06-17T20:51:00.006-05:00

Made some progress on the barrels this evening. It rained on and off all day and into the evening so I sat down to work on the electronics side of things for a bit. First things first, activate the relay with the PIC.

The relay I'm using is a JVN1A-4.5V-F from Panasonic. It's rated for 4.5V, will activate as low as 3.8V, and is safe up to somewhere around 6.75V. When activated, the coil pulls about 44mA. Since the PIC won't be doing much other than flashing an LED and turning on and off the pump, I decided that instead of using a MOSFET to turn the relay on, I would just tie three of the PICs output lines together. The 16F887 can source or sink 25mA on each I/O pin, to a maximum of 90mA for all pins on all ports combined. The code running on the PIC just turned the relay on and off every two seconds. Here's the code:

@ device pic16F887, hs_osc, wdt_off, lvp_off, protect_off
define OSC 4
TRISD = 000000 'Set PORTD to outputs

PORTD = 000000 'Clear PORTD
X var byte 'Scratch variable for counting, etc.
X = 0 'Clear the X var Init:

' Flash the LED to show the PIC is alive
for X = 0 to 3
toggle PORTD.3

pause 500
next X

MainLoop:

PORTD = PORTD ^ 000111 'XOR the lowest 3 bits on PORTD to toggle the relay

pause 2000

goto MainLoop

END 'This just here to shut compiler up

I hooked the power up, and it came to life. I ran it for a few minutes on a 9V battery and it ran without a hiccup. It sounded like the relay was doing its thing, not too bad for a first test. I should really jot down the schematic...

Around the time the relay started clicking, I noticed that the rain had stopped and there was even a hint of blue sky poking through. I decided to take advantage of the break in the rain and got my stuff together to try and finish up the barrels. I threw the back door open and stepped out into a giant cloud of mosquitoes.Arms flailing, I ran to the garage and took a look at the work from yesterday. I think I'm a convert to Goop - the joints done with it look a lot better than the ones done with the Extreme glue. The hoses turned out well, I plugged one end and tried to blow air through and they seem to be airtight. The Goop looks like it did a good job (pardon the bad focus):
And the Goop did a great job on the bushings where they met the barrel:
I hauled the barrels outside and grabbed two of the 3/4" m-m nipples and put some teflon tape on one side:
Then they were screwed into the bushings in the centre barrel:
With both of them screwed in, the centre barrel had two convenient spots for the hoses to connect to (on the right and left - the spigot is in the middle):
Now, on to the hoses. some teflon tape on the threaded end:
And then the hoses were carefully screwed into the bushings on the outer two barrels:

So now I have two barrels with a hose hanging off them and one barrel with two ports for the hoses to connect to. Things are starting to come together.

Unfortunately, by this time the mosquitoes were getting unbearable. I hauled the three barrels and hoses out to the side of the house where they'll be living, then beat a hasty retreat back into the house. I intend to finish the work on the hoses when I get home from work tomorrow, but if it's raining I'll work on the electronics some more.

Rain Barrels - Part III

2010-06-16T20:45:00.009-05:00

It was pretty hot out today but I was excited about working on the rain barrels. I put on my big hat and went outside, hoping to get a lot accomplished. Boy, was I wrong...

Before I started working, I headed out to Canadian Tire to pick up some more glue. I picked up another tube of the EXTREME stuff, and on a whim I grabbed a tube of Plumbing Goop:
It claimed it glues anything to anything, so I picked it up as backup.

First thing I noticed when I got all the parts and tools together was that the glue I'd used yesterday seemed to have done the trick. This was great - I was a little concerned that I was going to find that the glue had crumbled off and the bushings were going to be sitting in the bottom of the barrel.

I then rummaged through my bag of parts and noticed I had a lot of extra 3/4" male-male nipples. Suddenly it hit me - the 3/4" nipples were what the hose was supposed to connect to. That meant... the bushings I'd put in yesterday were in backwards.
Gaah!

So, out came the knife and after a bit of swearing I got the parts out. A bit of cleaning, a bit of sanding, and they went back in (the right way):
I know it's not the prettiest adhesive job, but I'm not doing this for style points. Notice how there's an internal thread there now? That's where the 3/4" nipple goes.

I drilled the hole for the interconnecting hose in the third rain barrel, then cleaned the hole and used the Goop (I'd run out of the Extreme glue again by this point) when putting the bushing in. It's quite a bit different from the other two, but it'll hold water and that's all I'm really concerned about:
By this point I'd been working for about 90 minutes and was just slightly ahead of where I'd finished yesterday. Plus, everything now needed 24 hours of sit time for the adhesive to cure. Not much else I could do except work on the interconnect hoses.

The hoses will have a 3/4" nipple at each end that screws into the bushings that I've put into the barrels. I cut the hoses to an (approximately) equal length of about "meeeehhhh" long (I definitely eyeballed it... maybe about two feet?) using a big X-ACTO knife. Then, some Goop went onto half the threads of the nipple, and it was hand-tightened into the hose (the threads are just big enough to grab the hose). Once tightened, I put a pipe clamp on the hose and cinched it up, just to give that extra bit of security. Since the hose is basically going to be screwed into the barrel, I can only set up one side at a time, unless I want to be turning a barrel over and over to thread the other side of the hose on. Here's the parts (minus the Goop) for one side of one interconnect hose:
"But HAL," you may find yourself asking, "Why don't you just use the proper part that has the little grabby part at one end and the threads at the other end?"

That's an excellent question. Simple answer - Mrs. HAL and I spent an hour and a half in two different stores trying to find the parts, and we did... but not for 1" hose. If I was using 3/4" hose, no problem. 1.25" hose, no problem. But with the parts we could find, the only thing we could do with 1" hose was find bushings and couplings and nipples that would convert it to something smaller or bigger. If everything leaks, I'll try more glue. If everything still leaks, I'll drill the holes to fit 1.25" parts and get new hose. But let's not get ahead of ourselves...

I then put the rest of the other hardware that came with the barrels in (the spigot and overflow on the other grey barrel) to get that out of the way, then put all three barrels into the garage. It's supposed to rain again shortly, and I want to make sure the glue gets a good chance to dry.

So now I have three barrels with their interconnect ports (I like saying it that way a lot more than "three barrels with their 1" to 3/4" reducer bushings") in and glue drying, interconnect hoses with one connector in and glue drying, and all of the other barrel parts put in. Everything should be dry by tomorrow afternoon, so if it's not pouring, I'll move the barrels to their positions by the downspout and do the rest of the work on the interconnect hoses.

One of the things that's been occupying my mind is how to build a reliable water level meter. I'm pretty sure that part of it will be conductor pairs that dip into the water at different levels, but I don't want to completely rely on that - what if some slime or something bridges the gap and makes the system think it's full of water when it's not? I definitely want two different ways to tell the water level. I thought I had an old mercury switch lying around somewhere, but now that I think about it, I'm pretty sure I got rid of it when there was a hazardous waste day in the neighbourhood a few years back. A good old-fashioned float switch would do the trick, but I'm trying to do this on the cheap. I'll see what I've got lying around that I could build one from.

So not a lot accomplished today - I spent a lot of time re-doing stuff I did yesterday. Not the end of the world (and I'm glad I caught it now as opposed to when I was trying to hook it all up in a few days), but a little embarrassing. Once the glue dries I plan to test and make sure there aren't any leaks. The weather forecast is not looking too good for tomorrow or Friday, and rain will make checking for leaks pretty much impossible. Hopefully it'll have the decency to hold off!

Rain Barrels - Part II

2010-06-15T23:15:00.009-05:00

Had a little bit of time to work on the barrels today. But first, here's a photo of one of the two barrels we got this past weekend (the barrel from last year is quite different) before I really started messing with it:
The large hole in the back near the top is where the overflow outlet goes. The barrels come with a lid that has a hole in the middle where a good-fitting mesh basket goes to keep leaves and other garbage out of the barrel (and, possibly more importantly, keeps the barrel from becoming a mosquito farm).In Part I, I mentioned drilling out the holes in the sides where the interconnect hoses would go. I used a 1.25" hole saw. To provide a place for the hoses to clamp on to, I bought some 1" to 3/4" adapters (at about a dollar each, I figured out they'd be a good place to start):
They threaded nicely into the 1.25" holes. Here you can see the positions of the two holes for the interconnecting hoses as well as the smaller hole where the spigot goes in the front of the barrel:
It's a little tight sticking my arms, head, and shoulders into the barrel, but once in there it's easy enough to tighten the parts from the inside.

With the fit of the parts confirmed, I removed them, then cleaned up the walls around the inside and outside of the holes before scuffing them up with sandpaper. I looked around in my big drawer of glue and this looked like the best thing I had to use as an adhesive/gasket/sealant:
I have no idea if this stuff will do the trick, but it says "Extreme" so it must be good. Smells, looks, and acts like silicone. I laid it on nice and thick on the inside, coating the threads before tightening the adapters in place. After it was tightened, I put a coat on the outside too. It got in the threads a bit, but that's okay - if everything works the way I'm hoping, I won't actually need the threads anymore.
Here's the inside (notice the abundance of goopiness now):
And the outside:
At this point I ran out of glue. So, I screwed the spigot on:
And attached the overflow:
Since I cut two holes in it for the interconnecting hoses, this is going to be the middle barrel - the other two will sit on either side of it. It will also be the one that the water drains into from the downspout and is pumped out of.

The glue will be ready to go tomorrow afternoon, I'm hoping to hook some hoses up to it and see if it leaks like a sieve. Here's a partial list of what I need to do (in no particular order):

Battery/electronics enclosure
Solar panel placement and mounting
Figure out an elegant (and cheap) way to detect the water level in the tank
Electronics design/breadboard
Test running the motor with the relay
Build a mount to hold the pump off the bottom of the barrel
Set up the other two barrels

More to follow!

Rain Barrels - Part I

2010-06-13T22:17:00.004-05:00

Wow... I've got to do a better job of keeping track of the things I'm playing around with.

I guess the new thing right now is that Mrs. HAL and I are working on setting up a little compost bin and some rain barrels so we can water the lawn. Mrs. HAL took the lead on the compost bin, and I've come up with a giant, overcomplicated plan for the rain barrels.

We bought a rain barrel from Canadian Tire last year but never actually used it. This year, we bought two more barrels from the Manitoba Eco Network (that was very frustrating, but that's a story for another day) and I started scribbling down a few ideas.

Some research on rain barrels seems to indicate that a lot of people have great ideas for getting the water into the barrels, but how you get the water back out of the barrel is, well... boring. Putting the barrels up on stands to use gravity to get the water out with a little more pressure, or just dunking the watering can into the barrel to fill it.

Don't get me wrong - our lawn is half dead because it pains me to pour drinking water on it to make it grow - but I'm also lazy enough that making three trips to the barrels (the downspouts are on the far side of the back yard from the gate) or waiting for the water to dribble out will ensure that the barrels will stay full of rainwater because I'll never use them.

So I looked around the house to see what I had lying around. A deep-cycle battery, a couple of 5.5W solar panels, some hose, some microcontrollers... a plan began to form:

Three barrels will be connected 6" from the bottom by 1" hoses. The hoses will carry the water between the barrels to make sure the water level stays equal between them. Hopefully any extra gunk that manages to get into the system will sit at the bottom, below the hoses. The centre barrel will be where the downspout drains into so there are two paths for water to flow into and out of, making it less likely that the water from the downspout will overwhelm the system (since the hoses are only 1"). The centre barrel will also have the overflow hole at the top connected, the overflow will go below the fence and out to the front yard which slopes down to the street. A pump will be used to pull the water from the centre barrel (which will also empty the other two through the low hoses) and run it out a garden hose. The pump will run off the deep-cycle battery, which will in turn be charged by the solar panels. The pump will be controlled by a relay that is activated by a microcontroller when the following conditions are met:

The main power is turned on,
There is enough water in the centre barrel,
The battery is sufficiently charged, and
The button to start the pump has been pressed.

Like I said, it's going to be a giant, overcomplicated plan.

A couple of two-litre pop bottles and some air hose were pressed into service for a small scale mock-up and things looked good. Mrs. HAL and I made a trip to Princess Auto about a week ago to pick up a 12V bilge pump (2000GPH, whoo!) and tested it that weekend. While the pressure was a little low, it made up for it in volume (again, 2000GPH, whoo!). Today we went to Princess Auto again to pick up all the hose couplers and adapters we'd need to get it all working. I must admit, I know very little about this stuff but it was very interesting looking at all the various different parts available (and the various different substances they're made of).

This evening I drilled out the holes 6 inches from the bottom of the barrels for the hoses. I'm not going to tighten everything up until I know for sure that things look right. I'm not sure when I'll get time to work on it next, but hopefully we'll have something in place for when the next big rain comes along.

I'll try to remember to take some photos next time I'm working on it.

Been A Little While...

2009-12-22T20:31:00.005-06:00

Happy Holidays, everyone!

Well, it's been pretty hectic around here, haven't had much time to do anything lately.

Every once in a while when I had a few minutes I'd hop onto the second Plug and play around with it. I moved the filesystem over to a 16GB SDHC card and tried to get the webcam working on it. Didn't have much luck. It was odd, the camera (QuickCam Pro 3000) worked fine on the original plug, but I couldn't get it working on the new one. It would be recognized, but as soon as I tried to start up anything that actually USED the camera, it would just... fail. Whenever I'd get a few minutes, I'd compile a new kernel, or play around with the last one I'd built - no luck. USB sticks and external drives worked, but no go with the camera.

I put the camera back on the original plug and it still worked like a charm. Finally, I found a little snippet somewhere (I wish I'd kept the URL), but the SheevaPlug doesn't put out the full 500mA on its USB port. It's enough to run most devices (like the aforementioned USB keys and disks), and it was enough for the camera to be identified, but when the camera was switched on, it was starved for current. Interestingly, I'd never actually hooked the camera directly to the original Plug, I'd always connected it through the powered USB hub! I should've clued in to this earlier, what with the USB disk copy problems I'd had on the original Plug...

A quick trip to the store to pick up a powered USB hub and the problem was solved.

Since then, I've got the following working:

- An FTDI USB to serial converter
- Motion software (to use the webcam)
- A PIC board connected to the serial port that responds to queries from the Plug and passes the temperature back, and
- A heartbeat script that gets and forwards the temperature reading to me in an email.

Next up is wireless networking, but that's probably going to have to wait until the new year.

SheevaPlug FTP Server

2009-10-12T18:44:00.004-05:00

So now I've got a SheevaPlug that's running nicely and has 8GB of external USB storage. This is pretty neat, but still not all that useful. Time to figure out possible uses for this Plug. One of the important uses for me is as an FTP server. Again, the standard disclaimer is in effect - I'm no expert so follow these directions at your own peril!

I mentioned in earlier posts that I've got an Axis 207W network camera. One of the things the camera can do is detect motion in its field of view and then dump images or video to an FTP server for review later. I think the SheevaPlug makes a great FTP server for this purpose. It's small and doesn't use much power. Also, if you've got a camera set up for security purposes and someone breaks in, they're probably not going to figure out what the Plug is (it kind of looks like it could be a timer or something instead of a computer).

I like ProFTPd – it's pretty easy to install and I haven't had any problems with it. Of course, FTP itself isn't the most secure thing in the world, but it's a protocol that the camera speaks.

There's an excellent document on setting up ProFTPd at http://ubuntuforums.org/showthread.php?t=79588 – you may want to check it out.

To set ProFTPd up:

sudo apt-get install proftpd

test@debian:~$ sudo apt-get install proftpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libmysqlclient15off libpq5 mysql-common proftpd-basic proftpd-mod-ldap
proftpd-mod-mysql proftpd-mod-pgsql
Suggested packages:
proftpd-doc
The following NEW packages will be installed:
libmysqlclient15off libpq5 mysql-common proftpd proftpd-basic
proftpd-mod-ldap proftpd-mod-mysql proftpd-mod-pgsql
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 3648kB of archives.
After this operation, 7692kB of additional disk space will be used.
Do you want to continue [Y/n]?

8MB space required. At this point, you should still have tons of space left on your Plug's internal flash storage. As ProFTPd installs, you'll be presented with a configuration screen asking if you want to run it standalone or from inetd – I used inetd.

Now, edit the /etc/shells file and add the following line:

/bin/false

Here's what my /etc/shells file looks like now:

# /etc/shells: valid login shells
/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/dash
/bin/bash
/bin/rbash
/bin/false

Now, you'll need to create a directory for the FTP server. Might as well create it on that external USB space you configured earlier, right?

sudo mkdir /mnt/usb/DATA/FTP

test@debian:~$ sudo mkdir /mnt/usb/DATA/FTP
test@debian:~$

Create download and upload directories:

sudo mkdir /mnt/usb/DATA/FTP/download
sudo mkdir /mnt/usb/DATA/FTP/upload

test@debian:~$ sudo mkdir /mnt/usb/DATA/FTP/download
test@debian:~$ sudo mkdir /mnt/usb/DATA/FTP/upload
test@debian:~$

Create a user to be used only for FTP (in this case, named userftp). Change “passwordfoo” to whatever password you want to use for the account. Note that the path /mnt/usb/DATA/FTP is located on the attached USB disk – if you have a different path to your USB disk, you'll want to change your line to match your path:

sudo useradd userftp -p passwordfoo -d /mnt/usb/DATA/FTP -s /bin/false

test@debian:~$ sudo useradd userftp -p passwordfoo -d /mnt/usb/DATA/FTP -s /bin/false
test@debian:~$

Now, change the password – like I said, I'm not getting into security here, but having your password in plaintext anywhere is a dumb idea!

sudo passwd userftp

test@debian:~$ sudo passwd userftp
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
test@debian:~$

Now that the directories and account have been created, give the account the proper access to the directories:

sudo chmod 755 /mnt/usb/DATA/FTP
sudo chmod 755 /mnt/usb/DATA/FTP/download
sudo chmod 777 /mnt/usb/DATA/FTP/upload

test@debian:~$ sudo chmod 755 /mnt/usb/DATA/FTP
test@debian:~$ sudo chmod 755 /mnt/usb/DATA/FTP/download
test@debian:~$ sudo chmod 777 /mnt/usb/DATA/FTP/upload
test@debian:~$

Now edit the /etc/proftpd/proftpd.conf file. Here's mine, you'll want to change the ServerName (in this case, Sparky) information. Again, this works for me, it may not work for you. For example, if your application will work with it, you may want to also change the port from 21 to something else for security reasons. I'm leaving it at 21 to keep my Axis camera happy:

#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes reload proftpd after modifications.
#

# Includes DSO modules
Include /etc/proftpd/modules.conf

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 off
# If set on you can experience a longer connection delay in many cases.
IdentLookups off

ServerName "Sparky"
ServerType standalone
DeferWelcome on

MultilineRFC2228 on
DefaultServer on
ShowSymlinks off

TimeoutNoTransfer 600
TimeoutStalled 100
TimeoutIdle 2200

DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"

DenyFilter \*.*/

# Use this to jail all users in their homes
DefaultRoot /mnt/usb/DATA/FTP

# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
# RequireValidShell off

# Port 21 is the standard FTP port.
Port 21

# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
# PassivePorts 49152 65534

# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
# MasqueradeAddress 1.2.3.4

# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours

# DynMasqRefresh 28800

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at.
User nobody
Group nogroup

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022 022
# Normally, we want files to be overwriteable.
AllowOverwrite on

# Uncomment this if you are using NIS or LDAP via NSS to retrieve passwords:
# PersistentPasswd off

# This is required to use both PAM-based authentication and local passwords
# AuthOrder mod_auth_pam.c* mod_auth_unix.c

# Be warned: use of this directive impacts CPU average load!
# Uncomment this if you like to see progress and transfer rate with ftpwho
# in downloads. That is not needed for uploads rates.
#
# UseSendFile off

TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log

QuotaEngine off

Ratios off

# Delay engine reduces impact of the so-called Timing Attack described in
# http://security.lss.hr/index.php?page=details&ID=LSS-2004-10-02
# It is on by default.

DelayEngine on

ControlsEngine off
ControlsMaxClients 2
ControlsLog /var/log/proftpd/controls.log
ControlsInterval 5
ControlsSocket /var/run/proftpd/proftpd.sock

AdminControlsEngine off

#
# Alternative authentication frameworks
#
#Include /etc/proftpd/ldap.conf
#Include /etc/proftpd/sql.conf

#
# This is used for FTPS connections
#
#Include /etc/proftpd/tls.conf

# A basic anonymous configuration, no upload directories.

#
# User ftp
# Group nogroup
# # We want clients to be able to login with "anonymous" as well as "ftp"
# UserAlias anonymous ftp
# # Cosmetic changes, all files belongs to ftp user
# DirFakeUser on ftp
# DirFakeGroup on ftp
#
# RequireValidShell off
#
# # Limit the maximum number of anonymous logins
# MaxClients 10
#
# # We want 'welcome.msg' displayed at login, and '.message' displayed
# # in each newly chdired directory.
# DisplayLogin welcome.msg
# DisplayChdir .message
#
# # Limit WRITE everywhere in the anonymous chroot
#
#
# DenyAll
#
#
#
# # Uncomment this if you're brave.
# #
# # # Umask 022 is a good standard umask to prevent new files and dirs
# # # (second parm) from being group and world writable.
# # Umask 022 022
# #
# # DenyAll
# #
# #
# # AllowAll
# #
# #
#
#

Once you've edited the file to where you want it, restart the ProFTPd service:

sudo /etc/init.d/proftpd restart

test@debian:/etc/proftpd$ sudo /etc/init.d/proftpd restart
* Stopping ftp server proftpd [ OK ]
* Starting ftp server proftpd [ OK ]
test@debian:/etc/proftpd$

Now, try connecting to the FTP server. I used Windows Explorer and was able to connect and see both the download and upload folders.

Using your FTP program of choice, try copying a file to and from the FTP server (if the permissions are set up correctly, you should only be able to copy data to the “upload” folder).

If everything seems to be working, then congratulations – you've got an FTP server set up – and the best part is that it's not using up valuable space on your Plug's internal Flash.

If you ever want to move to a bigger or different USB device, all you need to do to make things work is to copy or re-create the file structure and permissions from the current USB device to another one (but that's a discussion for later).

I set up the Axis camera to use the FTP server and performance-wise, it's fine. The camera is saving MPEG-4 video when it detects motion, and the 8GB USB stick connected to the SheevaPlug looks like it will hold between 11 and 12 hours of video. Not too bad for something so small!

Adding External USB Storage To The Plug

2009-10-11T02:22:00.002-05:00

Having trouble sleeping so I thought I'd try to do something constructive. Hopefully this makes sense, I'll probably read it tomorrow morning and wonder what the heck I was doing...

Adding External Storage To The SheevaPlug

If you're looking to do something like setting up an FTP server or using the Plug to share files, you're going to need some external storage. Out of the box, the SheevaPlug does a pretty good job of supporting USB storage devices like flash drives and hard drives. I've successfully used the following USB hardware for storage:

Kingston DataTraveler 8GB flash disk
Verbatim 256MB flash disk
PQI 8GB flash disk
Acomdata external USB hard disk enclosure with 80GB IDE disk
Enermax Jazz external USB hard disk enclosure with 1TB SATA disk

A useful package to install before adding USB devices are the USB utilities:

sudo apt-get install usbutils

test@debian:~$ sudo apt-get install usbutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
wget lynx
The following NEW packages will be installed:
usbutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 161kB of archives.
After this operation, 524kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com jaunty/main usbutils 0.73-8ubuntu3 [161kB]
Fetched 161kB in 1s (105kB/s)
Selecting previously deselected package usbutils.
(Reading database ... 12345 files and directories currently installed.)
Unpacking usbutils (from .../usbutils_0.73-8ubuntu3_armel.deb) ...
Setting up usbutils (0.73-8ubuntu3) ...

test@debian:~$

Once that's installed, plug your USB device in and turn it on (if required). You can tell if the Plug recognizes the device by checking the logs:

dmesg

You should see something along these lines (keep in mind I'm using a Kingston DataTraveler here):

usb 1-1: new high speed USB device using ehci_marvell and address 2
usb 1-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
sd 0:0:0:0: [sda] 15646720 512-byte hardware sectors (8011 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 15646720 512-byte hardware sectors (8011 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
test@debian:~$

Notice that the disk is called “sda”. In some situations, you may also have an “sdb”, “sdc”, or otherwise named disk - usually if you just have one USB disk, it will be sda. Keep track of which one you've got or are working with.

Using or putting the correct filesystem on the disk is important. The easiest thing to do would probably be to use the FAT32 filesystem. This has the advantage of being usable on both the Plug AND on any Windows computers you may want to use it with; unfortunately, it's kind of inefficient and if you use larger disks it becomes impractical. A disk can be set up with NTFS – this solves the disk size and efficiency problems but it's not supported on the Plug right out of the box. My personal favourite is to format with a Linux filesystem – that way, disk size isn't a problem and it should be supported nicely by any Linux machine. The big disadvantage with using a Linux filesystem is that you can't easily read it on a Windows machine.

Regardless, I'm going with a Linux filesystem. If I'm using the Plug as a file server or FTP server, I don't really expect to be pulling the disk out and reading it in my Windows computer all that often. If I had a big rack-mount server, I wouldn't be pulling the disks out of it!

So, to format a freshly attached USB disk with a Linux filesystem (in this case, ext2), you'll need to do the following. Remember that you're going to lose all of the data on your USB disk at this point. Also keep in mind that if you mistype these commands, there is the potential you'll kill your Plug.

Blow away the old partitions on the disk:

sudo fdisk /dev/sda (You'll want to use sdb or sdc or whatever you saw when you typed dmesg a while ago)

test@debian:~$ sudo fdisk /dev/sda

You'll now see the following:

The number of cylinders for this disk is set to 30560.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help):

Type p to see the current partition table on the device:

Command (m for help): p

Disk /dev/sda: 8011 MB, 8011120640 bytes
16 heads, 32 sectors/track, 30560 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 1 30560 7823344 b W95 FAT32

Command (m for help):

Notice the filesystem is currently FAT32. Time to fix this. Type d to delete a partition.

Command (m for help): d
Selected partition 1

Command (m for help):

If there had been more than one partition on the disk, you would have needed to select which one you wanted to delete. Now, type n to create a new partition. You will then be prompted a few times. You'll want to create a primary partition (select primary partition 1), and then accept the defaults for first and last cylinders:

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-30560, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-30560, default 30560):
Using default value 30560

Command (m for help):

Now hit p to take a look at the current partition table:

Command (m for help): p

Disk /dev/sda: 8011 MB, 8011120640 bytes
16 heads, 32 sectors/track, 30560 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 1 30560 7823344 83 Linux

Command (m for help):

Notice the filesystem is already showing up as type 83, or Linux. If it wasn't, then you could hit t and then type in 83 to select it.

So, things look good, time to commit to the changes. Kiss anything that's on that disk goodbye and hit w:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
test@debian:~$

Looks like we need to bounce the Plug, so go ahead and restart it:

test@debian:~$ sudo shutdown -r now

Broadcast message from test@debian
(/dev/pts/0) at 1:33 ...

The system is going down for reboot NOW!
test@debian:~$

Start pinging the Plug until it comes back (mine took 88 seconds), then SSH back in. I'm going to stop including the login screen as you should be familiar with it by now...

Once you're logged in, start up fdisk again and take a look at the partition table. It should now look something like this:

test@debian:~$ sudo fdisk /dev/sda
[sudo] password for test:

The number of cylinders for this disk is set to 30560.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 8011 MB, 8011120640 bytes
16 heads, 32 sectors/track, 30560 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 1 30560 7823344 83 Linux

Command (m for help): q

test@debian:~$

Looks like it's a Linux partition now, and the partition (in this example) is /dev/sda1. Time to format it with the mke2fs command:

sudo mke2fs /dev/sda1

There are quite a few different ways to format the disk. This one is pretty straightforward but doesn't give you a lot of flexibility.

The process may take quite a while (especially with larger disks), but will look something like this:

test@debian:~$ sudo mke2fs /dev/sda1
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
489600 inodes, 1955836 blocks
97791 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2004877312
60 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
test@debian:~$

Now we have to mount the disk so we can use it. To do that, a mount point is needed. To create one:

sudo mkdir /mnt/usb

test@debian:~$ sudo mkdir /mnt/usb
test@debian:~$

With the mount point created, the disk can now be mounted. Remember that /dev/sda1 will be replaced with whatever partition you want to mount. If you only have one USB disk and that disk has only one partition, chances are it will be /dev/sda1. To check the partition table quickly, type the following:

sudo fdisk -l

test@debian:~$ sudo fdisk -l

Disk /dev/sda: 8011 MB, 8011120640 bytes
16 heads, 32 sectors/track, 30560 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 1 30560 7823344 83 Linux
test@debian:~$

Again, in this example the disk is /dev/sda, and the partition to mount is /dev/sda1. Once you know which partition you want to mount, then mount it:

sudo mount /dev/sda1 /mnt/usb

test@debian:~$ sudo mount /dev/sda1 /mnt/usb
test@debian:~$

Once that's done, check out the filesystems available on your Plug with df:

test@debian:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 519168 175716 343452 34% /
tmpfs 257816 0 257816 0% /lib/init/rw
varrun 257816 272 257544 1% /var/run
varlock 257816 0 257816 0% /var/lock
udev 257816 12 257804 1% /dev
tmpfs 257816 0 257816 0% /dev/shm
tmpfs 257816 0 257816 0% /var/cache/apt
/dev/sda1 7700392 17196 7292032 1% /mnt/usb
test@debian:~$

The last entry has the USB disk (in this case, /dev/sda1), and it's mounted at /mnt/usb.

Now, create a directory on the USB disk that you'll actually store stuff in. While you could put data on the USB drive right now by dumping it in /mnt/usb, it's not a good idea. If the USB drive is connected and mounted properly, the data will be put on the USB drive. If, however, the USB drive is not mounted properly, the data will be dumped into the /mnt/usb directory on the Plug's internal filesystem!

So, create a directory that you'll actually use now:

sudo mkdir /mnt/usb/DATA

test@debian:~$ sudo mkdir /mnt/usb/DATA
test@debian:~$

Might as well check if the folder is there:

test@debian:~$ ls -la /mnt/usb
total 24
drwxr-xr-x 4 root root 4096 Oct 11 01:50 .
drwxr-xr-x 4 root root 0 Oct 11 01:42 ..
drwxr-xr-x 2 root root 4096 Oct 11 01:50 DATA
drwx------ 2 root root 16384 Oct 11 01:38 lost+found
test@debian:~$

If you want to be sure that the directory is actually on the USB disk, then unmount the USB disk so it's not available, then check to see if the DATA folder is there:

sudo umount /dev/sda1

test@debian:~$ sudo umount /dev/sda1
test@debian:~$

ls -la /mnt/usb

test@debian:~$ ls -la /mnt/usb
total 0
drwxr-xr-x 2 root root 0 Oct 11 01:42 .
drwxr-xr-x 4 root root 0 Oct 11 01:42 ..
test@debian:~$

And it's gone, so it must've been on the USB disk. Mount the USB disk again so it's available:

sudo mount /dev/sda1 /mnt/usb

test@debian:~$ sudo mount /dev/sda1 /mnt/usb
test@debian:~$

The problem with this setup as it is right now is that every time you reboot your Plug, you will need to manually mount the USB disk. This can be fixed by editing the /etc/fstab file. Unfortunately, fstab is one of those files where you can really mess things up if you're not careful.

You're going to want to add the following line:

/dev/sda1 /mnt/usb ext2 defaults 1 2

AGAIN – keep in mind that your entry may not be /dev/sda1 – take another look using fdisk -l if you're curious! If you created a different mount point than /mnt/usb then you'll also need to reflect those changes in your fstab file. There's a good outline of mount and fstab stuff at http://www.linux-usb.org/USB-guide/x498.html – check it out if you're looking for more options.

Here's what my fstab looks like now:

# UNCONFIGURED FSTAB FOR BASE SYSTEM
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
/proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
varrun /var/run tmpfs rw,nosuid,mode=0755 0 0
varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode=1777 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
rootfs / rootfs rw 0 0
tmpfs /var/cache/apt tmpfs defaults,noatime

/dev/sda1 /mnt/usb ext2 defaults 1 2

Notice the last line.

If you're comfortable with how everything looks, then restart your Plug and once it comes back up (mine took 94 seconds), hop back on and check your mounted filesystems:

test@debian:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 519168 185240 333928 36% /
tmpfs 257816 0 257816 0% /lib/init/rw
varrun 257816 244 257572 1% /var/run
varlock 257816 0 257816 0% /var/lock
udev 257816 12 257804 1% /dev
tmpfs 257816 0 257816 0% /dev/shm
tmpfs 257816 0 257816 0% /var/cache/apt
/dev/sda1 7700392 17200 7292028 1% /mnt/usb
test@debian:~$

And there it is - /dev/sda1, mounted right where it should be.

When you created the /mnt/usb/DATA folder, the only person who really has rights to it is root. You're not going to want to have to do everything as root, so we'll set some permissions on the DATA folder so you can use it. There is a great tutorial for how permissions work in Linux at http://catcode.com/teachmod/ - definitely worth checking out.

Change the group on the DATA folder:

sudo chgrp users /mnt/usb/DATA

test@debian:~$ sudo chgrp users /mnt/usb/DATA/
test@debian:~$

Now change the owner on the DATA folder to your account (in this case, the username I'm using is test):

sudo chown test /mnt/usb/DATA

test@debian:~$ sudo chown test /mnt/usb/DATA/
test@debian:~$

You should now be able to create files and folders on the USB disk:

test@debian:~$ mkdir /mnt/usb/DATA/sha-zam
test@debian:~$

No errors. Check and see if the folder is there:

test@debian:~$ ls -la /mnt/usb/DATA/
total 12
drwxr-xr-x 3 test users 4096 Oct 11 02:16 .
drwxr-xr-x 4 root root 4096 Oct 11 01:50 ..
drwxr-xr-x 2 test test 4096 Oct 11 02:16 sha-zam
test@debian:~$

And it is. So you've now got external USB storage set up that will mount automatically every time the Plug is rebooted. Now things like FTP or file servers start becoming practical – the 512MB of internal flash that the SheevaPlug comes with isn't quite enough to do serious file-related services.

Again, I hope this is helpful information. I'm no expert when it comes to this stuff, but I have fun doing it and hope that by getting excited and writing all this stuff down, other people will discover it and have fun with it too.

Setting Up The SheevaPlug

2009-10-10T22:26:00.003-05:00

So I finally had a chance to unbox and try out my second Plug. So far, it's also working like a charm. It also gave me the opportunity to check my notes to see if they were even remotely close to being right. Fortunately, they seem to be okay so without further ado, here are the first steps I took to getting the Plug running comfortably. I am using the stock firmware that came with the Plug - not the Alpha6 version (at least, not yet).

Keep in mind that this is not a post on best practices, security, or how to use Linux. It's also what worked for me - it may not do the trick for you. As a result, I would suggest that if you're reading this you also look around at some of the other helpful documentation out there - I take no responsibility for what happens if this doesn't work for you or if it leaves giant security holes in your network!

SheevaPlug Basic Setup

The first thing to do is check the box and Plug for any problems. If it looks okay on the outside and a light shake doesn't reveal any rattling sounds, then you'll need the following:

The Plug,
A source of power for the Plug,
A source of wired network,
DHCP running on the network somewhere (typically set up on the router), and
A spare DHCP address.

Ensure that DHCP is enabled either on the router or set up somewhere on your network and make sure there's a free address (but not too many free addresses – in my case, I've only got one DHCP address – 192.168.1.220). Once that's taken care of, you're ready to go.

Connect the Plug to your network. I'm a little wary about the cable they include for this purpose – it looks like decent quality, but it's a little too kinked for my tastes after being bundled in the box like that.

Power the Plug up, then sit down at your computer and start pinging the DHCP addresses you expect the plug to show up on (this is one of the reasons why it's a good idea to not have a larger DHCP address pool than you need). In my case, I'm waiting for 192.168.1.220 to show up. My Plug started responding to pings in 94 seconds. Give it a good five minutes before suspecting there's something wrong.

Once the Plug responds to pings, you can connect to it via SSH. Grab your favourite SSH client (mine's PuTTY), and connect using the default credentials:

Username: root
Password: nosoup4u

You should be rewarded with the following:

login as: root
root@192.168.1.220's password:
Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Sat Jan 1 00:07:04 2000
root@debian:~#

Take a look at the local filesystems. You might want to keep a copy of this so later on you can see where you started at. Use the df command:

root@debian:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 519168 150380 368788 29% /
tmpfs 257816 0 257816 0% /lib/init/rw
varrun 257816 36 257780 1% /var/run
varlock 257816 0 257816 0% /var/lock
udev 257816 8 257808 1% /dev
tmpfs 257816 0 257816 0% /dev/shm
tmpfs 257816 0 257816 0% /var/cache/apt
root@debian:~#

The rootfs entry is the one you're particularly interested in. This is where all of your data will be stored. Keep in mind that it's only 512MB in total, and the operating system is already using 29% of that. Don't worry – you can do an awful lot with the space that's available on the plug, and it's not that difficult to expand the space!

Now, take a look at how much memory is being used. Use the free command:

root@debian:~# free
total used free shared buffers cached
Mem: 515636 29236 486400 0 0 11868
-/+ buffers/cache: 17368 498268
Swap: 0 0 0
root@debian:~#

You can see that the Plug has 512MB of RAM, and thanks to the nice light default installation, it doesn't use a lot!

A good place to start configuring your Plug is the New Plugger Howto on the PlugWiki - http://www.openplug.org/plugwiki/index.php/New_Plugger_How_To

Edit /etc/dhcp3/dhclient.conf. Comment out the following line:

supersede domain-name-servers 127.0.0.1;

#supersede domain-name-servers 127.0.0.1;

Now, run the following:

dhclient eth0

root@debian:~# dhclient eth0
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:50:43:01:68:10
Sending on LPF/eth0/00:50:43:01:68:10
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.1.220 from 192.168.1.1
DHCPREQUEST of 192.168.1.220 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.220 from 192.168.1.1
bound to 192.168.1.220 -- renewal in 5470 seconds.
root@debian:~#

Now to test if the DHCP client is grabbing DNS info correctly, ping a few of your favourite internet sites:

ping www.cbc.ca

root@debian:~# ping www.cbc.ca
PING a1849.gc.akamai.net (63.84.95.75) 56(84) bytes of data.
64 bytes from host75.factsmgt.com (63.84.95.75): icmp_seq=1 ttl=57 time=48.5 ms
64 bytes from host75.factsmgt.com (63.84.95.75): icmp_seq=2 ttl=57 time=48.2 ms

--- a1849.gc.akamai.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 48.226/48.387/48.549/0.272 ms
root@debian:~#

ping kernel.org

root@debian:~# ping kernel.org
PING kernel.org (204.152.191.37) 56(84) bytes of data.
64 bytes from pub2.kernel.org (204.152.191.37): icmp_seq=1 ttl=60 time=80.4 ms
64 bytes from pub2.kernel.org (204.152.191.37): icmp_seq=2 ttl=60 time=80.5 ms
64 bytes from pub2.kernel.org (204.152.191.37): icmp_seq=3 ttl=60 time=80.1 ms
64 bytes from pub2.kernel.org (204.152.191.37): icmp_seq=4 ttl=60 time=80.4 ms
64 bytes from pub2.kernel.org (204.152.191.37): icmp_seq=5 ttl=60 time=80.8 ms

--- kernel.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 80.122/80.475/80.808/0.285 ms
root@debian:~#

If you get a return, then you're in good shape. If not, then make sure you edited the file correctly. If you did, then make sure you can actually ping the sites you're trying from another machine on your network.

Now, edit the /etc/rc.local file. Comment out everything except the line:

mkdir -p /var/cache/apt/archives/partial

Then add a new line to keep the Plug's internal clock accurate:

/usr/sbin/ntpdate-debian

The file should now look something like this:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#insmod /boot/fat.ko
#insmod /boot/vfat.ko
mkdir -p /var/cache/apt/archives/partial
/usr/sbin/ntpdate-debian
#/root/discoverd
#cd /
##./demo.sh
#date 012618002009
#hwclock -w

#exit 0

Run the file you just edited:

/etc/rc.local

root@debian:~# /etc/rc.local
9 Oct 01:18:45 ntpdate[1286]: step time server 91.189.94.4 offset -257334602.242881 sec
root@debian:~#

Now, set your time zone:

dpkg-reconfigure tzdata

Just follow the prompts to find the closest match to your location. If you make a mistake, you can hit Cancel, or just run dpkg-reconfigure tzdata again later.

When you're done, you'll get a nice little statement:

root@debian:~# dpkg-reconfigure tzdata

Current default timezone: 'America/Winnipeg'
Local time is now: Thu Oct 8 20:20:58 CDT 2009.
Universal Time is now: Fri Oct 9 01:20:58 UTC 2009.

root@debian:~#

Now, upgrade the existing installation:

apt-get update

(This may take a while, be patient while the packages are checked and downloaded.)

root@debian:~# apt-get update
Get:1 http://ports.ubuntu.com jaunty Release.gpg [189B]
Get:2 http://ports.ubuntu.com jaunty Release [74.6kB]
Get:3 http://ports.ubuntu.com jaunty/main Packages [1234kB]
Get:4 http://ports.ubuntu.com jaunty/restricted Packages [865B]
Get:5 http://ports.ubuntu.com jaunty/universe Packages [4442kB]
Get:6 http://ports.ubuntu.com jaunty/multiverse Packages [159kB]
Fetched 5910kB in 1min21s (72.6kB/s)
Reading package lists... Done
root@debian:~#

Upgrade the distribution:

apt-get dist-upgrade

root@debian:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
libxcb-xlib0
The following NEW packages will be installed:
aptitude libc6-vfp libcap2 libclass-accessor-perl libcwidget3 libept0
libgdbm3 libio-string-perl libparse-debianchangelog-perl libsigc++-2.0-0c2a
libtimedate-perl libxapian15 perl perl-modules python2.6 python2.6-minimal
The following packages will be upgraded:
adduser apt apt-utils base-files base-passwd bash bsdutils busybox-initramfs
console-setup cpio cryptsetup debconf debconf-i18n debianutils dhcp3-client
dhcp3-common dmsetup e2fslibs e2fsprogs eject file gcc-4.3-base ifupdown
initramfs-tools initscripts kbd klogd language-pack-en language-pack-en-base
libblkid1 libc6 libcomerr2 libcups2 libcurl3-gnutls libdevmapper1.02.1
libgcc1 libgnutls26 libgpm2 libkrb53 libldap-2.4-2 libmagic1 libncurses5
libncursesw5 libnewt0.52 libpam-modules libpam-runtime libpam0g libreadline5
libsasl2-2 libsasl2-modules libselinux1 libsepol1 libsqlite3-0 libss2
libssl0.9.8 libstdc++6 libuuid1 libvolume-id1 libwbclient0 libx11-6
libx11-data libxcb1 locales login logrotate lsb-base lsb-release
module-init-tools mount nano ncurses-base ncurses-bin netbase ntpdate
openssh-client openssh-server openssl passwd procps python python-minimal
python2.5 python2.5-minimal readline-common samba samba-common sudo sysklogd
sysv-rc sysvinit-utils tasksel tasksel-data tzdata ubuntu-minimal ucf udev
util-linux uuid-runtime vim-common vim-tiny whiptail xkb-data zlib1g
103 upgraded, 16 newly installed, 1 to remove and 0 not upgraded.
Need to get 57.1MB of archives.
After this operation, 62.5MB of additional disk space will be used.
Do you want to continue [Y/n]?

Notice it's telling you how much space it's going to use. I suggest keeping tabs on how much space you're using and how much you have left. These packages really don't take up that much space, but if you're not careful, it can build up quickly! Just hit Enter to continue.

This may also take some time, there's a lot of stuff that's going to be updated. Some people wander away and have a coffee – I like watching the progress on the screen. There's a handy little timer at the bottom right of the screen that will give you an “estimate” for how much longer you've got. I wouldn't put much faith in it, heh...

You should be seeing a lot of “Get:## http://ports.ubuntu.com” statements (my update here had 119 of them). If you get a whole lot of something else, something may be wrong...

Once it's done grabbing everything, you'll be prompted with a “Configuring console-setup” screen. I just left it on “UTF-8” and hit Enter. More unpacking and configuring will scroll up the screen. You'll then be prompted with a “Configuring libc6” screen. Just hit Enter again – the two services listed (samba and cron) are either useful (samba) or quite important (cron). So yeah, just hit Enter.

More grinding away – restarting services, then more unpacking/replacing/installing. The SheevaPlug has a lot of processing power for its size and electrical requirements, but it's certainly no quad-core brute with eight gigs of RAM. Don't panic if it takes a while or if you see the occasional [fail] message. Lots are bad. I got one for syncookies.

After about four minutes, you'll be prompted with the following:

Configuration file `/etc/dhcp3/dhclient.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** dhclient.conf (Y/I/N/O/D/Z) [default=N] ?

Hit Enter to accept the default. You edited that file a while ago, let's not overwrite it.

A bit more grinding and you'll be prompted again, this time with the “Samba Server” configuration. Since we don't have any Samba stuff set up yet, select “install the package maintainer's version” and hit Enter. We'll have to configure Samba later anyway.

Another brief burst of work, and you're done! These were the last few messages that scrolled up my screen:

Generating locales...
en_AU.UTF-8... up-to-date
en_BW.UTF-8... up-to-date
en_CA.UTF-8... up-to-date
en_DK.UTF-8... up-to-date
en_GB.UTF-8... up-to-date
en_HK.UTF-8... up-to-date
en_IE.UTF-8... up-to-date
en_IN.UTF-8... up-to-date
en_NG.UTF-8... up-to-date
en_NZ.UTF-8... up-to-date
en_PH.UTF-8... up-to-date
en_SG.UTF-8... up-to-date
en_US.UTF-8... up-to-date
en_ZA.UTF-8... up-to-date
en_ZW.UTF-8... up-to-date
Generation complete.

Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Processing triggers for initramfs-tools ...
root@debian:~#

Now, to tidy things up. This command is handy – you might want to run it every once in a while after you've installed or removed packages:

apt-get autoremove

root@debian:~# apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
libx11-data libxcb1 libxau6 libxdmcp6 libx11-6
The following packages will be REMOVED:
libx11-6 libx11-data libxau6 libxcb1 libxdmcp6
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
After this operation, 3621kB disk space will be freed.
Do you want to continue [Y/n]?

Getting three and a half meg back isn't too shabby at all. Hit Enter to do it.

(Reading database ... 12485 files and directories currently installed.)
Removing libx11-6 ...
Removing libx11-data ...
Removing libxcb1 ...
Removing libxau6 ...
Removing libxdmcp6 ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
root@debian:~#

So your Plug is now updated. The New Plugger How To is cautious at the end – it advises trying to open a second SSH connection to make sure you can still log in before you reboot the Plug. This is my second Plug now, and I haven't had any problems yet, but taking a few extra seconds now can save you a lot of time later. So open up a second SSH session and try to log in. If you can, then it's time to reboot your plug (and cross your fingers):

shutdown -r now

root@debian:~# shutdown -r now

Broadcast message from root@debian
(/dev/pts/0) at 20:51 ...

The system is going down for reboot NOW!
root@debian:~#

Now, back on your computer, ping away until you start getting replies. It took 87 seconds for my Plug to start responding.

SSH back into the Plug using the root and nosoup4u credentials:

login as: root
root@192.168.1.220's password:
Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Mon Dec 4 04:52:05 2017 from 192.168.1.41
root@debian:~#

So if you've got this far, then congratulations – you've now got a good solid platform to start playing with! There are many things that the plug can do at this point, the most popular would probably be sharing a USB disk over the network or something. Before you do that, though – there are two things you need to do: change the root password and create another account that does not have godly root-like powers.

So, to change the root password, type:

passwd

root@debian:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@debian:~#

Now, create a new account (in this case, I'm creating an account called “test”):

root@debian:~# adduser test
Adding user `test' ...
Adding new group `test' (1000) ...
Adding new user `test' (1000) with group `test' ...
Creating home directory `/home/test' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
Full Name []: Test User 1
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
root@debian:~#

So now your user account is ready to go. What I'd suggest at this point is that you set up the account with sudo access so you can actually install and run stuff with the new account:

visudo

I've added the line for the test user (obviously, you'll want to use whatever username you created instead of “test”) as shown below:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL) ALL
test ALL=(root) ALL

# Uncomment to allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
# %sudo ALL=NOPASSWD: ALL

Once that's done, you can log back in with the account you created and you don't have to worry about accidentally messing too much up!

login as: test
test@192.168.1.220's password:
Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Fri Oct 9 18:59:43 2009 from 192.168.1.41
test@debian:~$

Hopefully by now you're logged in as your non-root account. If you choose to log in with root at this point, that's your option – this is not intended to be a lecture or how-to on Linux (or any kind of) security.

So that's that... the first in what will probably be quite a few posts on the SheevaPlug - I hope you found this helpful!

There are so many uses for a little computer like this, and I'm super-impressed with how well they work. Granted, two isn't a great sample, but so far my experience has been great with these devices!

They've Shipped!

2009-10-06T20:29:00.002-05:00

My new Plug order has shipped! With luck it will be here before the end of the week!

I've got a bunch of plans for this order, I especially want to apply my notes against it and see how accurate they are. If I can get the plug running with my notes, I'll post them here.

I haven't had as much time to play with this stuff lately as I would have liked, but Blammo has been working exceptionally well. Mrs. HAL and I have been using Blammo's USB disks as a handy little network storage space. We've got about 190GB on it right now.

I've been manually backing up the "live" 1TB disk using tar, but I tried zipping (tar -cvzf). Ouch - 24 hours later and it was still going. Just doing a tar -cvf and 190GB gets archived in about three hours or so.

The FTP and Motion services have been running flawlessly, too. No problems or complaints at all!

Put In Another Order...

2009-09-24T21:43:00.005-05:00

I haven't had as much time to work with stuff over the last few days as I would have liked, but I did get a few more things working. I set up a little Perl script that talks SMTP, then set up a cron job to run it once an hour... now I'll get a very simple heartbeat email letting me know if Blammo is up. I'm just playing around right now, but it could have its uses.

Here's what I used to send the email:

#!/usr/bin/perl -w

use strict;

use Net::SMTP;

my $smtp=Net::SMTP->new('smtp.mymailserver.com') or die $!;
$smtp->mail("myaddress\@myaddress.com" );
$smtp->to("destination\@address.com");
$smtp->data();
$smtp->datasend("To: destination\@address.com\n");
$smtp->datasend("From: myaddress\@myaddress.com\n");
$smtp->datasend("Subject: Blammo Heartbeat\n");
$smtp->datasend("\n");
$smtp->datasend("This is a heartbeat message from Blammo.");
$smtp->dataend();
$smtp->quit();

And that's it. Not a heck of a lot there. I'm planning on eventually hooking a PIC up to the USB serial thing and hanging various things off the PIC to check - maybe a PIR or smoke detector or something. The PIC would wait for Blammo to query it over the serial port; Blammo would read the data and if something was triggered it could fire an email off. I did something like this a while ago but it required a laptop sitting beside the breadboard that the PIC was on. Kind of clunky.

Oh, and I ran a backup of one my desktop to the 1TB disk on Blammo. Transfer rates were quite consistent:

It's sitting around the 70% utilization point. Checking the CPU utilization on the Plug showed the smbd process only using about 15% and the Plug was still over 20% idle. I'm not entirely sure what the limiting factor is for the data transfer - I'm betting it's my little home network. I'll have to try using a crossover cable between Blammo and something with a Gbit NIC just to see if it speeds things up...

Running an archive job using tar -cvf doesn't tax the Plug's CPU at all. I haven't run a -cvzf since I last had those USB problems, maybe I'll try it tonight. It's too bad I didn't have another one to play around with while this one is actually being used...

Speaking of which - I ordered up another SheevaPlug dev kit yesterday. I'm planning on cracking it open to see how easy it'd be to run off a battery. I'm also going to use it to test all of the notes I wrote down. If I set the new Plug up successfully using my notes, I'll post them (instead of posting them and not being reasonably sure that they're correct). No idea when the new Plug will get here, but that's okay - I've still got a ton of stuff to do with the current one!

SD Success!

2009-09-21T22:39:00.004-05:00

The SheevaPlug - which, from this point on will be known as "Blammo" - is now running its root filesystem off of a 16GB SDHC card!

I followed the directions from http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System - they were quite thorough and well done, I only had one small burp but it was my own fault.

The U-boot system built into the SheevaPlug makes it really easy to change the behaviour of the plug (as long as you're careful). The more I play with this thing, the more impressed I am with it!

I'm going to be ordering another one or two Plugs this coming weekend, I think, so I'm going to get all of my notes together and try it out on a fresh-out-of-the-box Plug to see if my notes are anywhere near correct. If they are, I'll be posting everything I've done to get it working step by step.

Here's something interesting - I compared boot times between the internal flash and the SDHC card. The timer started when I entered the "boot" command from the U-boot console and stopped when I saw the boot prompt. Booting off of the internal flash takes 110.07 seconds. Booting off the SDHC card takes 17.84 seconds. No, that's not a typo!

Here's what the filesystems looked like before:

root@Blammo:/media/big1/DUMP/BACKUPS/M/LAPTOP# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 519168 225320 293848 44% /
tmpfs 257440 0 257440 0% /lib/init/rw
varrun 257440 584 256856 1% /var/run
varlock 257440 0 257440 0% /var/lock
udev 257440 72 257368 1% /dev
tmpfs 257440 0 257440 0% /dev/shm
tmpfs 257440 21824 235616 9% /var/cache/apt
/dev/sda1 961432072 16659648 895934424 2% /media/big1
/dev/sdb1 961432072 10597304 901996768 2% /media/big2

... and here's what they look like now. Notice the rootfs entry:

root@Blammo:/media/big1# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 15796916 496092 14498380 4% /
tmpfs 257440 0 257440 0% /lib/init/rw
varrun 257440 308 257132 1% /var/run
varlock 257440 0 257440 0% /var/lock
udev 257440 80 257360 1% /dev
tmpfs 257440 0 257440 0% /dev/shm
tmpfs 257440 0 257440 0% /var/cache/apt
/dev/sdb1 961432072 17014652 895579420 2% /media/big1
/dev/sda1 961432072 43887736 868706336 5% /media/big2

I'm not sure how long the SDHC card will last, but I'm planning on making a copy of it shortly just in case...

Nothing new on the wireless front, haven't had a chance to look around for a new USB adapter.

Oh - and there have still been no further USB problems since I plugged in that adapter. That's a bit of a relief!

No USB Hiccup Today

2009-09-20T20:24:00.003-05:00

Since I plugged in the USB hub, I've run seven tar jobs from one of the TB disks to the other. So far, so good!

And let me spare you the effort by saying, "DUH" to myself about not plugging in the electrical thing...

A great resource for the SheevaPlug stuff is the PlugWiki. Starting out, the New Plugger How-To was really helpful. Granted, it just works if you plug it in, but if you want to start customizing it a bit (and get around a few little nagging problems), it's a great place to start:

http://www.openplug.org/plugwiki/index.php/New_Plugger_How_To

There are also links to other How-To pages for various other things you may want to get running.

I was a little worried about how much could be done with 512MB of flash disk space. Apparently, quite a bit! Even now, after installing a few extra packages that weren't actually needed to do the things I'm doing, I still haven't hit the 50% mark on the disk:

root@Blammo:/media/big1/DUMP/BACKUPS/M/LAPTOP# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 519168 225320 293848 44% /
tmpfs 257440 0 257440 0% /lib/init/rw
varrun 257440 584 256856 1% /var/run
varlock 257440 0 257440 0% /var/lock
udev 257440 72 257368 1% /dev
tmpfs 257440 0 257440 0% /dev/shm
tmpfs 257440 21824 235616 9% /var/cache/apt
/dev/sda1 961432072 16659648 895934424 2% /media/big1
/dev/sdb1 961432072 10597304 901996768 2% /media/big2

So yeah, 44% full. I'm still planning on migrating the whole thing over to an SD card, but that's more because it'll be easy to duplicate when I get another Plug, and over time, the easily replaceable SD card will fail from repeated writes, and not the internal flash.

SheevaPlug Successes

2009-09-19T23:58:00.002-05:00

Well, I've had the Plug for a few days now and have had some success with it. I'm trying to write stuff down as I do it, and someday I'll get my notes in order, but here's the deal so far.

Hardware:
- SheevaPlug (duh)
- Two 1TB disks in USB enclosures
- QuickCam Pro 3000 webcam
- Staples 4-port powered USB hub (more on this later)
- Parallax-branded USB-to-serial converter

Firmware:
- Running my own custom kernel (2.6.30.7)

Software:
- Samba (for Windows file sharing)
- ProFTPd (for the Axis 207W camera to dump video to)
- Motion (to use with the webcam, it's working but I haven't done much with it yet)
- Trafshow (it's cool and I've never done a Linux installation without installing it, heh)
- Wget (useful for fetching new kernel stuff)
- The Build-Essential package (essential for building a new kernel on the Plug)
- Libncurses package (makes some screens pretty)

So far it's been running quite well. It's a development kit, but there is a lot of documentation out there that's been put together by people fighting with one aspect or another of the Plug. Getting a new kernel to run was probably the most difficult thing I've done so far, but now I've got all the modules I need to get most of the goodies I want working up and running.

I haven't got the wireless working yet, I think the main reason for that is my USB wireless adapter is a screaming piece of crap. But I digress...

I was having some problems with the disk aspect of things. One of the 1TB disks is where all of the "live" data goes. Periodically, that data will be copied over to the other disk using tar. Every once in a while, though, during heavy disk access, the whole USB bus would just burp and that would be it - disks no longer accessible, camera no longer accessible... only a reboot of the Plug would fix it. Looking at /var/log/messages showed the following:

Sep 19 21:32:04 Blammo kernel: usb 1-1.3: USB disconnect, address 6
Sep 19 21:32:04 Blammo kernel: pwc: Disconnected while webcam is in use!
Sep 19 21:32:04 Blammo kernel: usb 1-1.3: new full speed USB device using orion-
ehci and address 18
Sep 19 21:32:04 Blammo motion: [1] Closing video device /dev/video0
Sep 19 21:32:06 Blammo kernel: usb 1-1.3: new full speed USB device using orion-
ehci and address 19
Sep 19 21:32:07 Blammo kernel: usb 1-1.3: new full speed USB device using orion-
ehci and address 20
Sep 19 21:32:08 Blammo kernel: usb 1-1.3: new full speed USB device using orion-
ehci and address 21
Sep 19 21:32:33 Blammo kernel: sd 1:0:0:0: [sda] Unhandled error code
Sep 19 21:32:33 Blammo kernel: sd 1:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00

Uh-oh...

I was worried it was drivers or firmware or who knows what... but then I remembered that even though the USB hub came with an AC adapter, I hadn't been using it. So I plugged it in and have successfully done two full multi-GB transfers between the disks. So hopefully that solves that problem.

I'm really impressed with this little device. With the CPU pinned at 100%, I'm measuring a temperature of 48C on the outside of the box. Pretty warm, but nothing that will start paper on fire or anything. Now that I think about it, this heat may even let it run all winter in an unheated garage, hmm...

Still on my list of things to do are get wireless working, get the USB disks to automatically mount in the right order, and move the whole filesystem to an SD card to make replication easier and reduce the wear on the internal flash.

More later!

It's Here!

2009-09-12T02:43:00.006-05:00

The SheevaPlug dev kit arrived this afternoon - I've been busy playing with it. So far, it's exceeded my expectations.

Firstly, the box. As soon as I saw the box, I thought two things: firstly, half the cost of the item is probably because of the box - it's very sturdy and has a neat little magnetic snap to hold it shut. Secondly, even if the Plug itself was a piece of junk, at least I got a cool box out of it.

Inside the box are five things - a CD (which for some reason my machine won't read - not a big deal as updated stuff is on the website), a power cable (which is optional as the unit itself has a regular plug built onto it), an ethernet cable, a USB cable, and the plug itself.

As I mentioned above, I couldn't get the CD to work in my machine so I hopped onto Globalscale's site and downloaded all the SheevaPlug stuff. I read just enough of the documentation to get ready, then set up DHCP on my DSL router (to start everything up initially, the Plug needs DHCP), then plugged it in and turned it on.

It worked. I downloaded PuTTY and hopped onto the Plug. Took a quick look around. The Plug has 512MB of internal storage (flash), and 512MB of RAM. Stock, the Plug was using about 30% of the storage and a little less than 10% of the RAM. Nice tight install.

I took a peek at the Plug Wiki (www.openplug.org) and found some good "real world" instructions on what to do first to bring things up to spec. I updated the packages and distribution (it's running a slimmed-down Ubuntu for ARM-ish processors), but didn't update to the A6 firmware.

After that, I grabbed an 8GB USB stick and plugged it in, just to see what would happen. The Plug found it and I was able to mount the filesystem (FAT32) no problem. Connecting an old external hard disk (80GB, USB1.1) was a little more problematic, but after reformatting it with ext2, it was up and running just fine.

Since then I've been running around in all kinds of directions, playing with it. Here's what's running so far:

- Samba - it's functioning as a Windows file server, I've been copying stuff to and from it but that USB1.1 disk is BRUTALLY slow.
- FTP - I installed ProFTPd, it's pretty snazzy. It's also suffering from the same performance problems as Samba due to the fact it's folders are on the same disk.
- Just for the heck of it, I turned on motion detection on the Axis 207W camera and it's dumping its videos to the FTP server.

So far, so good! What I really need is a USB hub so I can run more than one device at a time. I'd also like to get a bigger (and faster) disk or two. I'm also looking at downloading the Motion software and having it talk directly to the Axis camera to do its own motion detection. I played with Motion a year or two ago and it worked really well.

Here's a photo of the Plug in action. Notice how small it is!
The cable at bottom left is ethernet, bottom right is USB (to the external disk), the power cable in the top outlet is also going to the external disk.

The unit itself is silent. The whirr of the disk on the floor beside it is all I can hear. It's warm-ish, but not hot at all. I've got it all hidden downstairs in the basement - it's small and will stay out of the way. With no moving parts, it should last quite a while, the only thing I can see wearing out is the internal flash, but that can be mitigated by moving some of the applications to an SD card (there's an SD socket on the side, you can see it in the picture) or to an external USB disk or flash.

I could see these being ridiculously popular if they were easier to get ahold of. Even from a business perspective - small companies that only need a small file or printer server and don't have any room, power, or environmental for a proper "server room" may be able to get away with using a few of these with USB disks attached. There are so many possibilities!

I've got a lot of playing to do!

Iiiiiiinteresting...

2009-08-30T19:17:00.001-05:00

Whoo - been busy lately, haven't had any time to build or play around with anything, but...

I just ordered up a SheevaPlug development kit. I saw them back in February and thought they were pretty neat, now the reviews are in and they're quite positive. Basically, what it is is a tiny server that runs Linux that fits into a wall wart. It's got 512MB RAM, 512MB flash storage, and to talk to the rest of the world it's got USB and ethernet ports.

This is the kind of thing I've been waiting YEARS for! The potential is pretty much endless - aside from all the experiment-y stuff, just plug an external USB disk into it, plug it into the wall somewhere in the basement, wire it in (or set up a USB wireless ethernet adapter), and presto - instant back-ups! Instant file server! Plug in web cams, set up the motion software and presto - network accessible camera! Security camera! Whatever!

The whole package has no moving parts and consumes 7W when running flat out. That's small - like, run-for-days-on-a-battery small!

Moving Along...

2009-07-05T23:04:00.004-05:00

Didn't spend as much time on stuff as I'd planned, but I did get a chance to do up the boards for the Linx transceiver chips that I'm going to be using. Normally, I would buy something in a DIP package so I could just plug it into a breadboard, but I don't think any of these transmitter/receiver/transceiver chips actually come in DIP. That, and they're pretty succeptible to noise so you need a groundplane, so there's another reason to put them on a PCB.

A long time ago (really long time ago), I'd just draw the lines out on a piece of copper-clad board with a Sharpie, then hope for the best. This worked pretty well for discrete components and up to, say, 8-pin DIPs.

Then I migrated to using a laser printer to print the traces on a sheet of paper, then pressing the traces from the paper onto the PCB with a hot iron, THEN soaking it in water for a few hours so the paper fell off. It gave me pretty decent results, but required a lot of touch-ups as the traces wouldn't be deposited on the PCB consistently. I could do 40-pin DIPs with this method, but it didn't look very good and I was limited as to how thin I could make my traces.

About a year ago, I finally dropped some money on the pre-sensitized boards from MG Chemical. Print up your PCB design on a clear sheet of plastic, then use a lamp to expose it on a board for 10-15 minutes, then drop the exposed board into the developer, lightly brush, rinse, and voila! A (more often than not) great-looking board with no annoying shorts. It is a little more time to make a board, but I can make a board with much higher component and trace density than the other two methods.

Anyway, so here's a batch (there are 10 on this board) of freshly etched transceiver boards, just ready to be cut out, drilled, and soldered. I put one of the transceiver chips on there just to make sure all the pins lined up:

That hole on the left side is for the length of dental floss I tie to the board so I can move it around in (and lift it out of) the ferric chloride.

With luck I'll have two of these up and running in the next day or two!

It's Alive!

2009-06-28T16:24:00.005-05:00

Finally had a chance to sit down today and work on the CRC stuff. It works!

I had it working over wire pretty quickly, but it was difficult to test because I had trouble introducing enough noise into the wire to flip bits at the right time. Imagine that - here I am, half the stuff I put together barely works because there's too much interference, but when I actually need to generate some... I tried:
- Touching the wire,
- Putting a long antenna-like wire in parallel with the transmission wire,
- Grabbing my little fluorescent lamp (all the TVs and radios in the house make noise when I turn that sucker on),
- Running the signal through a 30-foot piece of wire,
- Wrapping the wire around the fluorescent lamp, and
- Running the signal through a 150 foot spool of cable, which sat on top of the fluorescent lamp.

None of these worked. I ended up having success by adding another wire to the 30-foot piece of wire (which was the transmission line at the time), then running a metal file along it. Made enough noise that I could get the receiving PIC to turn on the CRC fail LED with some regularity.

Then went to RF. The signal's being transmitted at 2400bps, which is about as high as I can go running a 4MHz crystal. Most of the things I do don't really require anything any faster. 2400bps transfers 88bits plus a 16-bit preamble in less than 50ms. Not too shabby.

Anyway, the transmitter sends the signal ten times. My old projects would transmit 50x or more to try to get a signal out. I left the transmitter in the basement and wandered outside and into the garage and if I knelt down behind the car with my chest, car, garage wall, deck, outside wall of the house, and two inside walls between the transmitter and receiver, I could sometimes mess up the signal enough to get the CRC fail LED to go on. I'm only using one of the ten available bytes to transmit data (the other nine are just a bunch of zeroes), but the data is being received and checked!

I'm quite pleased with the progress here. Progress towards what, you ask? Well... I'm not 100% sure. I'm looking at some monitoring and automation down the road a bit, but for now it's just good to get this working. The code is pretty fat right now, but I'm not working on medical equipment or space station parts.

So, a general outline here (I need to get me a scanner):

- PORTC.0 of the transmitter connects to PORTC.1 of the receiver, whether it's by cable or through wireless.
- PORTC.7 determines whether that particular PIC is going to be a transmitter or receiver. I'm only using a simplex link here, so PORTC.7 is directly wired in on both PICs right now.
- PORTA.0 on the transmitting PIC is connected to a potentiometer that swings between VCC and GND, that way I read the voltage level with ADC port 0. That's the byte of data I'm tucking into the 80 bits worth of payload I have to work with.

Here's a shot of the transmitter and receiver side by side. Notice the same display on both bar LEDs, and the green LED (CRC OK) on the receiver is lit:

There's no way I'll be able to mess up the signal and take a picture of the transmitter and receiver at the same time so you'll have to take my word for it that it works. Already I can think of a whole bunch more uses for this scheme than the previous ways I'd done RF projects... I can actually send sampled data now instead of just notifying of a particular situation.

Here's the code - this is also the first RF project I've done where the same code is running on both the transmitter and receiver!

@ device pic16F877A, hs_osc, wdt_off, lvp_off, protect_off

define OSC 4

DEFINE ADC_BITS 8 ' Set number of bits in ADC result
DEFINE ADC_CLOCK 3 ' Set ADC clock source (rc = 3)
DEFINE ADC_SAMPLEUS 50 ' Set ADC sampling time in microseconds

TRISA = %11111111 'PORTA is set to inputs (using for ADC)
TRISB = 000000 'PORTB is set to outputs
TRISC = %11111110 'PORTC is set to inputs except pin0 (TX)
TRISD = 000000 'PORTD is set to outputs

'CRC-8-CCIT: x^8 + x^7 + x^3 + x^2 + 1 = 110001101

'**Aliases**

TX var PORTC.0
RX VAR PORTC.1
TX_RX var PORTC.7
MSG_GOOD var PORTB.0
MSG_BAD var PORTB.1

'**Variables**
MESSAGE4 VAR WORD 'Most sgnificant WORD (16 bits) of data
MESSAGE3 VAR WORD '2MSW of data
MESSAGE2 VAR WORD '3MSW of data
MESSAGE1 VAR WORD '2LSW of data
MESSAGE0 VAR WORD 'Least significant WORD (16 bits) of data
DATATMP4 VAR WORD 'a copy of the original data that will be shifted into CALC
DATATMP3 VAR WORD
DATATMP2 VAR WORD
DATATMP1 VAR WORD
DATATMP0 VAR WORD

RECEIVED_CRC VAR BYTE 'CRC byte that's been received

TRANSMIT_CRC VAR BYTE 'CRC byte that's been calculated and ready to go out with message

WORKING_CRC VAR BYTE 'Byte for working CRC value. If CRC is being generated,
'then this is set to zero. If CRC is being checked, then
'this is set to RECEIVED_CRC.

CALC VAR WORD 'space for DATA to be shifted in to run CRC against

SHIFTCOUNT VAR BYTE 'count the number of bit shifts done

POLY VAR WORD 'CRC-8-CCITT Polynomial. Actually needs nine bits

X var byte 'Counter variable to transmit a burst of the same msgs.

Init:
PORTD = %10101010 'Show the PIC is alive
msg_good = 1
MSG_bad = 0
PAUSE 500
PORTD = %01010101
MSG_GOOD = 0
MSG_BAD = 1
PAUSE 500
PORTD = %10101010
MSG_GOOD = 1
MSG_BAD = 0
PAUSE 500
PORTD = 0
PORTB = 0

POLY = 00000110001101 'Preload with the CRC-8-CCITT polynomial value

ADCON1 = 2 ' PORTA is analog

Start:

'Clear everything:
MESSAGE4 = 0
MESSAGE3 = 0
MESSAGE2 = 0
MESSAGE1 = 0
MESSAGE0 = 0

'PORTD = 0 'Don't clear PORTD, leave the last result on the bar display.
'That way, you can easily tell if it's still actuall running.
'If a signal has not been received this time around, the
'CRC OK or BAD LEDs will turn off. The effect ends up being
'that if signals are being received either the OK or FAIL CRC
'LEDs will flash if a signal is being received.
PORTB = 0

'Read the TX_RX switch, see if we're receiving or transmitting. High = TX,
'Low = RX.

if tx_rx = 1 then
WORKING_CRC = 0
ADCIN 0, MESSAGE0.lowbyte
goto Docalc
endif
'If we're here, then TX_RX must be 0, which means we're receiving. Give the
'only wait 15s for a signal before returning to Start so we're not stuck forever.
serin rx,16780,15000,start,["AA"],message4.byte1,message4.byte0,message3.byte1,_
message3.byte0,message2.byte1,message2.byte0,message1.byte1,message1.byte0,_
message0.byte1,message0.byte0,received_crc

working_crc = received_crc

goto docalc

'--PSEUDOCODE HERE--

'IF (TASK IS TO TRANSMIT DATA) THEN
'WORKING_CRC = 0
'ELSE
'WORKING_CRC = RECEIVED_CRC
'ENDIF

'--END PSEUDOCODE--

DoCalc:

CALC = 0 'Clear the CALC variable.

DATATMP4 = MESSAGE4 'Get a working copy of the data for the calculations.
DATATMP3 = MESSAGE3 'MESSAGEx comes from the data that is to be sent out
DATATMP2 = MESSAGE2 'or is one of the bytes of data received from the TX side.
DATATMP1 = MESSAGE1
DATATMP0 = MESSAGE0

SHIFTCOUNT = 0 'Clear the shift counter

RunCRC:

If SHIFTCOUNT = 88 THEN 'Shifting 88 times: 80 for the actual data, another
'eight for the padding zeroes or CRC data at the end
GOTO DoneShifting
ENDIF

CALC = CALC << 1 'Shift the bits in the calculation over by one.
CALC.0 = DATATMP4.15 'Dump the MSB of DATATMP into the LSB of CALC
DATATMP4 = DATATMP4 <<1 'And shift the DATATMP data over by one
DATATMP4.0 = DATATMP3.15
DATATMP3 = DATATMP3 << 1
DATATMP3.0 = DATATMP2.15
DATATMP2 = DATATMP2 << 1
DATATMP2.0 = DATATMP1.15
DATATMP1 = DATATMP1 << 1
DATATMP1.0 = DATATMP0.15
DATATMP0 = DATATMP0 << 1
DATATMP0.0 = WORKING_CRC.7 'Append eight zeroes to the end of the message
WORKING_CRC = WORKING_CRC << 1 'or the received CRC data, depending on TX or RX.

SHIFTCOUNT = SHIFTCOUNT + 1 'We've just done a shift, so increment.

IF CALC.8 = 0 THEN 'If there's a 0 in position 8, we can't do an XOR, need to shift again.
GOTO RunCRC
ENDIF

CALC = CALC ^ POLY 'XOR the current calculation with the POLY.

goto RunCRC: 'Done this cycle, see if there are more bits to do.

DoneShifting: 'Go here when done the shifting and calculation

'Done all the shifting. If we're transmitting, then TRANSMIT_CRC = CALC.
'If we're receiving, then if CALC = 0, the message passes the CRC check and can
'(hopefully) be considered sane.

if TX_rx = 1 then '1=transmitting, 0=receiving
PORTD = message0.byte0 'Display the message being sent
transmit_crc = calc
for x = 0 to 10 'Send the message 10 times, just in case.
serout tx,16780,["AA",message4.byte1,message4.byte0,message3.byte1,_
message3.byte0,message2.byte1,message2.byte0,message1.byte1,message1.byte0,_
message0.byte1,message0.byte0,transmit_crc]
next x
pause 1000 'Done. Wait here for 1s before starting again
goto start
endif
'If we're here, then we're set to RX.
'Did the data pass the CRC check?
if calc = 0 then 'If CALC = 0, the data passed the CRC check
msg_good = 1
msg_bad = 0
PORTD = message0.byte0
PAUSE 1000 'Wait for 1s for display visibility and to ignore
'any other attempts during this "burst" (10 copies).
goto start 'Done here, go back and try it all again
endif
'If we're here, then the data was bad!
MSG_GOOD = 0
MSG_BAD = 1
PORTD = 0
goto start 'Done here, go back and try it all again. Don't wait, go
'back quickly to see if we can catch the transmitter before it's done sending
'the rest of the burst (10 copies).

Next step is to sample more data... maybe a few more ADC channels. Displaying the data at the receiving end in text on an LCD would be a lot easier than watching the bar LEDs, too...

But... Will It... Work?

2009-06-23T20:45:00.002-05:00

So I think I've put together what I need to both generate CRC blocks AND check the sanity of received data. Unfortunately, I don't have time to test it this evening, but I'm going to post it here anyway. If it works, I'll be pleased - if it doesn't, then my public humilitation on the internet will be complete. Either way, it'll be interesting.

I'm heading towards using an 11-byte packet for my RF projects. Here's the structure:

|Preamble/Sync|DST Addr/SRC Addr|Next Hop/Previous Hop |Flags1|Flags0|Desc2|Desc1|Desc0|Data2|Data1|Data0|CRC|

And here's what each segment means:
- Preamble/Sync (16 bits, not counted towards packet total or included in CRC calculations): Sends ASCII string "AA" to wake up receivers. The next 88 bits received after "AA" are counted as data.
- DST Addr (4 bits) / SRC Addr (4 bits): You can probably figure out what these are.
- Next Hop Addr (4 bits) / Prev Hop Addr (4 bits)
- Flags1 (8 bits), Flags0 (8 bits): These are pretty fluid right now, but include ACK, NAK, Request ACK, RF Test, Data Test, Too Many CRC Errors, Low Power, PORTA Fail, PORTB fail, PORTC fail, PORTD fail, PORTE fail, Direction (for really, REALLY basic routing), and Last Gasp.
- Desc2 (8 bits), Desc1 (8 bits), Desc0 (8 bits): Used to describe either the status of a particular reading or operation or to tell the receiving end what is contained in the DATA fields (i.e. a temperature reading, port bit reading, etc).
- Data2 (8 bits), Data1 (8 bits), Data0 (8 bits): Meant to contain actual data from a PIC port or peripheral. PIC ADCs are 8-bit, 10-bit, 12-bit, or 16-bit depending on model.
- CRC (8 bits): the CRC checksum that's generated by the above code (hopefully).

The structure is most definitely going to be changing, but hopefully there's enough there for me to make some progress.

As for the CRC code, here it is. Oh, and yes, I know I should have been using arrays instead of a big list of shuffling variables, but... well... uh... yeah, I have no excuse. Anyway, here it is:

'CRC-8-CCIT: x^8 + x^7 + x^3 + x^2 + 1 = 110001101

Variables:
MESSAGE4 VAR WORD 'Most sgnificant WORD (16 bits) of data
MESSAGE3 VAR WORD '2MSW of data
MESSAGE2 VAR WORD '3MSW of data
MESSAGE1 VAR WORD '2LSW of data
MESSAGE0 VAR WORD 'Least significant WORD (16 bits) of data
DATATMP4 VAR WORD 'a copy of the original data that will be shifted into CALC
DATATMP3 VAR WORD
DATATMP2 VAR WORD
DATATMP1 VAR WORD
DATATMP0 VAR WORD

RECEIVED_CRC VAR BYTE 'CRC byte that's been received

TRANSMIT_CRC VAR BYTE 'CRC byte that's been calculated and ready to go out with message

WORKING_CRC VAR BYTE 'Byte for working CRC value. If CRC is being generated,
'then this is set to zero. If CRC is being checked, then
'this is set to RECEIVED_CRC.

CALC VAR WORD 'space for DATA to be shifted in to run CRC against

SHIFTCOUNT VAR BYTE 'count the number of bit shifts done

POLY VAR WORD 'CRC-8-CCITT Polynomial. Actually needs nine bits

Init:
PORTD = %10101010 'Show the PIC is alive
PAUSE 500
PORTD = %01010101
PAUSE 500
PORTD = %10101010
PAUSE 500
PORTD = 0

POLY = 00000110001101 'Preload with the CRC-8-CCITT polynomial value

Start:

'--PSEUDOCODE HERE--

'IF (TASK IS TO TRANSMIT DATA) THEN
'WORKING_CRC = 0
'ELSE
'WORKING_CRC = RECEIVED_CRC
'ENDIF

'--END PSEUDOCODE--

CALC = 0 'Clear the CALC variable.

DATATMP4 = MESSAGE4 'Get a working copy of the data for the calculations.
DATATMP3 = MESSAGE3 'MESSAGEx comes from the data that is to be sent out
DATATMP2 = MESSAGE2 'or is one of the bytes of data received from the TX side.
DATATMP1 = MESSAGE1
DATATMP0 = MESSAGE0

SHIFTCOUNT = 0 'Clear the shift counter

RunCRC:

If SHIFTCOUNT = 88 THEN 'Shifting 88 times: 80 for the actual data, another
'eight for the padding zeroes or CRC data at the end
GOTO DoneShifting
ENDIF

CALC = CALC <<>
CALC.0 = DATATMP4.15 'Dump the MSB of DATATMP into the LSB of CALC
DATATMP4 = DATATMP4 <<1>
DATATMP4.0 = DATATMP3.15
DATATMP3 = DATATMP3 <<>
DATATMP3.0 = DATATMP2.15
DATATMP2 = DATATMP2 <<>
DATATMP2.0 = DATATMP1.15
DATATMP1 = DATATMP1 <<>
DATATMP1.0 = DATATMP0.15
DATATMP0 = DATATMP0 <<>
DATATMP0.0 = WORKING_CRC.7 'Append eight zeroes to the end of the message
WORKING_CRC = WORKING_CRC <<>

SHIFTCOUNT = SHIFTCOUNT + 1 'We've just done a shift, so increment.

IF CALC.8 = 0 THEN 'If there's a 0 in position 8, we can't do an XOR, need to shift again.
GOTO RunCRC
ENDIF

CALC = CALC ^ POLY 'XOR the current calculation with the POLY.

goto RunCRC: 'Done this cycle, see if there are more bits to do.

DoneShifting: 'Go here when done the shifting and calculation

'Done all the shifting. If we're transmitting, then TRANSMIT_CRC = CALC.
'If we're receiving, then if CALC = 0, the message passes the CRC check and can
'(hopefully) be considered sane.

Now keep in mind that this code won't actually DO anything - it's meant to be plugged into other code that will gather/receive/transmit data.

I'm hoping to try it out before the weekend. Wish me luck!

Doing The CRC Thing...

2009-06-21T18:33:00.003-05:00

Wow... been a while since I've posted here. Actually, it's been a while since I've sat down at the bench and worked on stuff.

I picked up some of those Linx transceivers a little while ago and had some great plans for things to do with them. The reason I like the Linx stuff is they include everything except voltage regulation on the chip. You don't need any LC network or, well, anything else to make it work. They're a little more expensive, but it ends up being worth it when you're trying to get things to work - as long as there's power and serial data going in, you can be pretty sure there's serial data being sent out.

Up until now all of my RF projects were very simple affairs - a PIC would read, say, an ADC and if it was out of range, it would send a particular signal. An example would be if it was a reading above 200 (8-bit ADC), it would send the string "AAAAAA". If it was a reading below 50, it would send "BBBBBB". The nice thing about this is that if you're worried about noise, you can send a shorter signal (like "AA"), or if you're worried about false alarms, you can send a longer signal (like "AAAAAAAAAA").

There are two main problems with this scheme. The first is there is a definitive tradeoff between lessening the chance that a message will be accidentally "built" by noise and lessening the chance that a legitimate signal will be corrupted by noise. Make the signal shorter and there's less chance that noise will corrupt it - but then there's a better chance that a random burst of noise will actually create a signal or even corrupt one signal to make it look like another. Make the signal longer and it's less likely to be replicated by random noise, but then it's easier for the noise to mess the signal up.

The second problem is that you're then stuck with either limiting the number of conditions you can test for, or you need to create lookup tables that tell the PIC what to do for any of the possible conditions that the system may encounter. For a small number of tests or conditions, this isn't a problem. Things like checking if an ADC is reading above or below something, whether an input line is high or low, this is fine. But once you start trying to transmit multiple conditions or (gasp) data, then it becomes a problem. Even something as easy as a wireless thermometer with 1.0 degree resolution would be a big chore. You'd need to send "AAAAAA" if the temperature was 0C, then "BBBBBB" if the temperature was 1C, then "CCCCCC" if the temperature was 2C, and so on. The receiving end would then need a lookup table for every possible temperature that was being sent so it would know what to do when it received something like "TTTTTT". Since a lot of microcontrollers are limited in RAM, code space, or clock cycles, It's obvious that in situations like this it'd be a lot more elegant to just send data to the receiver so it could do the calculations or do calculations and send the results as data to the receiver. But how to send data which could be any value through the air and be pretty sure that the receiver is reading it properly?

One popular way to do this is to transmit multiple copies of the same message. Then, the receiver compares the copies and decides which is correct based on how many look the same. For example, five copies would be sent, the receiver found three the same and two are different, so it decides that the three matching ones are correct. This is a pretty simple way to do it but it does have problems, too - just because a certain number of messages match does not guarantee that that particular message is correct. Also, in lower-power environments it's not desireable to spend extra power transmitting the same message multiple times.

Another way to go about it is using cyclic redundancy checks, or CRCs. CRCs have been around for a long time now, and depending on their application are excellent at detecting errors in data. CRC's can't fix the error, but they will tell if one has been received (with a certain degree of accuracy) so the message can be ignored or asked for again by the receiver. The main disadvantage of CRCs is that they require a bit of processing to calculate, at both the transmitting and receiving sides. Basically, a CRC block is the result of XORing data that you want to transmit with a generator polynomial. There are many different generator polynomials of different sizes. Ethernet, for example, uses a 32-bit CRC. The calculated CRC is tacked onto the end of the data and transmitted, and the receiver uses the same generator polynomial and runs it against the received data and CRC. If the answer ends up being zero, the message was received correctly (well, "should" have been received correctly - there are still some bit patterns that can fool the CRC check). There are a lot of good articles out there about how CRCs work, and I've become pretty decent at working them out on paper, but as I pretty much suck at math and programming (it's a hobby, not a career, thank goodness) I'm making slow progress getting them working on the PICs.

I've had success with PicBasic Pro on the 16F877A (which has been discontinued - phooey) generating a 4-bit CRC with a 4-bit chunk of data, and I've also been able to generate an 8-bit CRC with a 32-bit chunk of data. Next step is to write a program that'll generate AND check 64-bit data with an 8-bit CRC.

An 8-bit CRC certainly isn't the strongest error-detection scheme out there, but even so, it should detect 255/256 or 99.6% of errors. A 0.4% error rate is not too shabby, especially for what I'm doing. Probably not too great for something like a heart monitor or dialysis machine, but for telling the temperature outside or whether there's light on a photoresistor it should be fine. Tacking on eight bits to a 64-bit message would also keep overhead down to about 11%. Still not great, but it's not like it needs to be super speedy...

What I'm really trying for here is a multi-node network where the nodes in the middle act as relays between the nodes at the ends. The Linx modules have a range of 3000 feet in the right conditions (and I've had the opportunity to test that out in the country - they actually exceeded 3000 feet line-of-sight), and what I'd like to do is be able to, say, check the temperature from 10000 or 15000 feet away (almost three miles).

But baby steps. I need a portable 8-bit CRC program that will generate and check CRC data. Fortunately, the two activities are so similar that I just need to slightly modify my existing (working) CRC generator.

I've tried to put up a set of instructions on how to do CRCs, but for the life of me, I can't get the formatting to come out nicely. Since there's a lot of XORing, the instructions make absolutely no sense if the bits don't line up. Everything looks fine in Notepad, but regardless of font or setting, I can't get them to line up properly here. Hmm... maybe I need to put up a picture or something...

So, let's try something - a blinking LED

2009-02-17T18:04:00.004-06:00

Probably not a bad idea to actually look at a simple project with the 16F877A. With the parts I mentioned in the previous post, you can easily use PBP to write a program that will confirm that your PIC is indeed alive. Sure, a blinking LED isn't all that exciting, but what the heck, it can't hurt to start small. It's also a good idea to have an extra LED built into more complex projects so you can make it blink every once in a while to show you whether the program is working. I don't know how many times I've done that...

I won't bother mentioning that you need a programmer, the PBP demo, or a computer to put it together with. How about a schematic?

So, let's take a look. The top section is your power supply. Hook a 9V battery up to the Input and Ground pins of the 7805. Magically, at the output you'll have a usable 5V supply that you can use to hook up to your PIC. Remember to disconnect the battery - even when the PIC isn't hooked up, the 7805 will slowly drain your battery all by itself. Make sure you look up the pinout of the 7805 that you're using - the ones I've used are all (if you're holding it up, facing you) IN, GROUND, and OUT from left to right. Check before you hook it up, though!

The second part is obviously where the PIC goes. The 10k resistor from Pin 1 to +5V makes keeps the /MCLR line high so the PIC won't accidentally reset itself. The 1k resistor hanging off pin 19 limits the current going to the LED, which in turn goes to ground.

The Vdd and Vss pins are the +5V and GND (Ground) connections, respectively. The "dd" and "ss" mean "drain" and "source" in ye olde MOS lingo - best to just ignore that and remember that for the PICs, Vdd is +, Vss is -. It is VERY important to make sure you have both sets of these pins hooked up!

Pins 13 and 14 are the oscillator pins. You hook your 4MHz crystal between them, and also hook each pin to GND with a 33pF capacitor. This provides a nice stable clock for your PIC to run on.

Once you've got that built, it's time to write the program with the PBP demo. This is how I did it (and I do not pretend to be a master programmer):

******

'Name - Blink.pbp
'MCU: 16F877A
'Clock: 4MHz, external HS crystal oscillator
'Description: Blink an LED on PORTD.0

@ device pic16F877A, hs_osc, wdt_on, lvp_off, protect_off 'Turn off the WDT
define OSC 4 'Clock at 4MHz, using external HS Crystal Oscillator

TRISD = 000000 'Set all of PORTD to outputs
PORTD.0 = 0 'Turn off PORTD.0 when starting up

MainFunction:

pause 1000 'Pause for 1000 milliseconds
toggle PORTD.0 'If PORTD.0 was on, turn it off. If it was off, turn it on.

goto mainfunction 'Go back and do it again.

end

******

And that's pretty much it. If everything works properly, the LED should turn on and off at about one second intervals.

That "define OSC 4" line near the top of the program tells PBP that you're using a 4MHz crystal. If you've got an 8MHz crystal, you should change it to "define OSC 8". If you've got a 1MHz crystal... well, you get the drift. If the "define OSC" line doesn't match the actual crystal you're using, your program will run either faster or slower than you intended. Or won't work at all, if you're really unlucky.

The "pause 1000" line tells PBP to wait 1000 milliseconds. If you change that to 500, then everything's going to happen twice as fast.

Pretty easy, eh?

Here's the finished product:

So, you've got a PIC. What now???

2009-02-16T19:26:00.006-06:00

I've been asked by several of my friends and coworkers who are interested in electronics about how to get into working with microcontrollers. Being a big fan of Microchip's PIC lines, I naturally point them in that direction. Of course, that always leads to what you can possibly do with these little chips.

Well, there's a lot. I mean, an AWFUL lot.

Some of the different PICs have ADCs built into them, some of them have PWM modules so you can pump out a fancy signal while you do other tasks with the PIC, some have 30 or more pins you can hook input or output devices to... the sky's the limit (as lame as that sounds).

This brings up another point. What do you use to write the program? Well, thanks to the simplicity of the instruction set, the 12F and 16F series of PICs are actually pretty easy to program using assembler. It can be a little frustrating and take a while, but there is something nice about being so close to the hardware that you can time your programs by individual clock cycles. Me - I'm lazy. I bought microEngineering Labs' (www.melabs.com) PICBASIC Pro compiler a few years ago and have used it ever since. Sure, being right next to the hardware is nice, but it's also nice being able to read an ADC with a single command. PBP hasn't let me down yet. The one downside is that it's NOT cheap... but if you're looking at seriously playing with PICs as a hobby, you may want to consider investing in PBP (I got mine from Digi-Key).

But... there's another possibility. MELabs is nice enough to offer a demo version of the PBP compiler. It's full-functioned but will only work with certain PICs and is limited to 31 lines of commands (comments and blank lines don't count towards the total).

So, if you're interested in trying PICBASIC Pro out, you can always give the demo a shot before deciding whether you want to buy the full version. One of the limitations of the demo actually helps prove how good PBP is - you can do an AWFUL lot in 31 lines of code.

One of the PICs that works with the PBP demo is the 16F877A. It's a pretty standard chip, been around for a while, and there are TONS of projects using it. I just happen to have one here:

It's a 40-pin monster, but it's got it where it counts!

To get this sucker working, you'll need the following:

- A parallel-cut crystal (4MHz is a good bet)
- Two 20-40pF capacitors (I use 33pF)
- A resistor (anywhere from 1k to 47k should do just fine)
- Another resistor (1k would be perfect here)
- An LED. Any colour but blue or white!
- A power supply (I'm a big fan of a good old 9V battery)
- A +5V voltage regulator (the 7805 series works well for playing around)
- A breadboard
- Some wire
- **A PIC programmer**. These are available from several different places, I personally like (and use) Microchip's PICKit 2.
- A computer (to compile your programs on and hook the aforementioned PIC programmer up to)

And that's it - that's all you need to get a 16F877A running and being able to actually tell that it's running.

China's Attacking Me!!!

2008-11-15T21:53:00.003-06:00

Interesting thing here. I've got the camera sitting in the DMZ of my router so I can check on the animal from wherever. I was wandering by it and couldn't help but notice that the activity LED was flashing regularly. Since there aren't many people who know where the camera is or the username and password, I thought it odd that there was that much activity.

Time to sniff some traffic!

Grabbed my trusty laptop and fired up Wireshark. Take a look at this:

Now this here... is an automated attack. Somebody's just hammering away at the camera with their little dictionary of possible passwords, trying to get in.

I'd be worried that some day they'd actually get in, except that the username is not "test".

Anyway... I plugged the IP into a few whois pages and (assuming the address isn't spoofed), the entity attacking my poor innocent little Axis camera is... CHINA!

Now that's exciting!

Axis 207W Camera - Part II

2008-11-15T15:02:00.011-06:00

Okay, so I had a bit of time today to take some pictures and jot down the schematic.

Here's the back of the Axis 207W camera, showing the green terminal block:

Here's how I've set it up on the board:

And here's the schematic (pardon the quality, I should've used unlined paper):

Here's the PicBasic Pro code:

; Axis207-01.pbp
;
; Listens to Axis 207's terminal port. Camera's external port goes high/low, PIC reads it,
; then turns on an LED. Turn external port high/low again, PIC turns on
; another pin.
; Camera connects to PIC via 4N37 optoisolator.
; Camera output signal fed to PORTB.0.
; PIC uses RB0 interrupt to tell when it's time to turn on/off LEDs.
; Output pins are PORTD.0 through PORTD.3 inclusive.

; This just sets PIC up. Let's not use the WDT here...
@ device pic16F877A, hs_osc, wdt_off, lvp_off, protect_off

; Use a 20MHz crystal. You can use a 1, 4, 8MHz crystal, whatever, as long
; as you indicate the speed here. Check the PBP manual for what crystal
; types are supported right out of the box.
define OSC 20

; Set up one byte for a counter
x VAR BYTE

; PORTB set up - PORTB.0 (pin 33) is the INT pin.
TRISB = 000001

;Make PORTD the output pins
TRISD = 000000

; Turn off all of the output lines
PORTD = 0

; Clear the counter
x = 0

; Set up interrupts. When one is detected, jump to IntRoutine:
on interrupt goto IntRoutine

; Enable the RB0 interrupt
INTCON = %10010000

MainLoop:

; Not much to do but wait...
goto mainloop

; Disable PBP interrupts while the interrupt routine is running
disable

IntRoutine:

; We don't have a fifth LED, so if the count has gone to 5, change it to 0.
; And yes, I know this isn't the best way to do this... but it works.
if x = 5 then
PORTD = 000000
x = 0
endif

if x = 0 then
PORTD = 000000
endif

; If count = 1 then turn on the PORTD.0 LED
if x = 1 then
PORTD = 000001
endif

; If count = 2 then turn on the PORTD.1 LED
if x = 2 then
PORTD = 000010
endif

; If count = 3 then turn on the PORTD.2 LED
if x = 3 then
PORTD = 000100
endif

; If count = 4 then turn on the PORTD.3 LED
if x = 4 then
PORTD = 001000
endif

; Increment the counter
x = x + 1

; Done the interrupt routine. Clear the interrupt flag
INTCON.1 = 0

; Go back to where you were when the interrupt was called (MainLoop:)
resume

; Re-enable PBP interrupts
enable

A few notes:

The board pulls less than 20mA when running. Using a 5V micropower regulator instead of the good old 7805 would use about 5mA less right there. If you used a lower frequency crystal, you could drop that even further. I'm powering the board with a 12VDC, 300mA wall wart.

It's been working fine for me for a few days now (I'm now using it to turn on and off a lamp in the living room for fun), but I take no responsibility if it burns down your house or something.

BEFORE you hook it up to your camera, you should do a few things:
- Check your camera manual to make sure which camera terminal pins are which
- Measure the voltages on the camera terminal pins to make sure you know which pins are which
- Make absolutely sure you are not either shorting out the camera or applying more than 5V to it. I think the manual says a maximum of 10V, but who wants to fool around, eh?
- To test the circuit, you can connect the 1k resistor that's connected to pin 2 of the 4N37 between pin 2 and ground, and then connect and disconnect pin 1 of the 4N37 to +5V. If everything's working properly, that should trigger the output of the 4N37 which will in turn trigger the PIC and you should see LEDs turning on and off.

Enjoy!

Axis 207W Camera

2008-11-12T20:58:00.002-06:00

So I picked up an Axis 207W camera a while ago to use as a pet-cam. It's great - self contained, plug it in and it works.

It also has an external four-pin terminal block that you can hook stuff up to. Two of the pins are power and GND, and the other two are signal in, and signal out. It's not too fancy - basically, the only "signal" is a high or low. It looks like there may be a way to change things by playing around with the scripts on the camera, but I'm more a hardware guy.

The camera allows you to set up a "pulse" button on the main page, so you can easily trigger a pulse on the output pin. That gave me an idea.

I have a few PIC 16F877A's lying around, so I hooked the camera's output pin up to it (through an optoisolator - no sense melting _everything_ if I screwed up). A bit of a program, and presto - I now have a camera that cycles through four outputs when you click the "pulse" button on the camera's webpage.

I hooked one of the four outputs to a relay (through another optoisolator) and it's currently running a lamp.

I'll clean it up a bit and post the schematic, pics, and code as soon as I can.

But right now... I'm famished. Time for some scrounging in the fridge.

Oh, and those parts from Digi-Key came in! It occured to me when I opened the box up that, along with the serial-to-USB converter I got, I should've picked up a USB jack. Whoops.

Anyway, off to eat.

Yet Another Digi-Key Order

2008-11-09T18:36:00.004-06:00

I buy a lot of stuff from Digi-Key. Probably too much, but I have a lot of fun with it. I've got another order that should be arriving tomorrow or the day after - and there are two parts I'm very excited about - an RF transceiver (no more needing two chips and two antennae or an antenna switch!), and a serial to USB converter. Both are from Linx Technologies.

I'm especially looking forward to the RF transceiver - I've built a lot of things that use a simplex communication link, and only once have I built something that ran half-duplex. I actually used two transmitter/receiver pairs, each running at different frequencies. It worked, but what a waste.

Other than that, I picked up a few more micropower voltage regulators, I was fresh out of 3.3V regulators.

Now, the tricky thing is to figure out what I'm going to do with all this stuff...

There's always a starting point, I suppose...

2008-10-27T21:19:00.002-05:00

Well, here I am. I never thought I'd actually set up a blog.

I've been playing around with electronics for a while. It's always been a hobby. I'll get into it for a while, then leave it for something else for a while, then get back into it. I do it for fun.

I'm not an electrical engineer, I'm just some dude with a workbench, a few breadboards, and lots of little electronic parts lying around. Maybe you'll laugh at the things I work on, or how I did it, or whatever. If you like something that I've got here, let me know. If you learn something, use something, or improve on something, let me know that too.