Thursday, April 11, 2013

Massimo Banzi on open-sourcing imagination

I just got back from a presentation by Massimo Banzi, one of the inventors of the Arduino.

It was the last installment of the Penny Stamps Distinguished Speaker Series sponsored by the U of M
School of Art & Design and it was fascinating.

He spoke to a packed house at the Michigan Theatre in Ann Arbor on his work with Arduino and Interaction Design at SUPSI Lugano.

His talk should be on-line at http://www.facebook.com/PennyStampsSeries at some point.



Inspirational stories, examples of Arduino in industry and the arts, and plenty of anecdotes on design interaction.




Invent, prototype, refine!

Thursday, February 7, 2013

Web connected outlet - Epilogue

Finishing

I boxed everything up today, poked some holes in the cover so it could breathe and tested everything one last time before plugging it in.  The app autostarts about a minute after plugging it in so it truly is a headless device.

The box is rather large, but I wanted plenty of space. Putting stuff in boxes is often the hardest part for me.  I typically have to drill extra holes to get everything aligned and screwed together.  This time, I used the time-honored tradition of "measure twice, cut once" and it turned out pretty well.  The next one will be in a smaller box and will use the Raspberry Pi Model A.

Why do this?

When I decided to do this project, I mostly wanted to learn a little more about the RPi and to prove a point (again): if you can think it, you can do it.

At some point the "doing it" gets easier and the "thinking it" gets harder. There are so many people thinking and doing ("makers") that by the time you think of something, someone else has probably already done it - and maybe they're even selling it!  For example, Belkin makes a relatively inexpensive system called WeMo that does the same thing as this project a little more elegantly and for about the same cost.  I just saw a really cool Siri/Raspberry Pi system on Life Hacker that handles lights, garage doors, etc. using off-the-shelf components.

But, regardless of the utility or the uniqueness of these little innovations, the fun is really in the learning and testing and experimenting and just playing with the technology. It's way more fun than watching TV (with the possible exceptions of Big Bang Theory or Modern Family) and playing video games (with the possible exception of Pong.)

I believe that the next big thing is the "Internet of things" so I try to nudge it along whenever I can. So, what's the next project? Maybe one that has to do with things!

Monday, February 4, 2013

Web connected outlet - part 6


The software

The WebIOPi software, developed by Eric Ptak and featured in this month's MagPi magazine, has some great, easy to use software for manipulating GPIO ports.  If you're doing GPIO, you owe it to yourself to check this out.  Most of the code below started from the WebIOPi examples, except for the C code (which started out as code by Kevin Sangeelee, released as GPLv2.)

I've skinnied down his WebIOPi Javascript code to simply turn on and off a single port.  These web apps are stored in /usr/share/webiopi/htdocs on the RPi and are called, imaginatively, on.html and off.html. Here's what they look like:

on.html

<html>
<head>
<title>Switch 1 on</title>
    <script type="text/javascript" src="webiopi.js"></script>
    <script type="text/javascript">
        webiopi().ready(function() {
            webiopi().setFunction(7,"OUT");
            webiopi().setValue(7, 1);
        });
    </script>
</head>
<body>
<FORM METHOD="post">
    <INPUT TYPE="button"
        VALUE="Back"
        OnClick="history.go(-1);return true;"">
</FORM>
</body>
</html>


off.html

<html>
<head>
<title>Switch 1 off</title>
    <script type="text/javascript" src="webiopi.js"></script>
    <script type="text/javascript">
        webiopi().ready(function() {
            webiopi().setFunction(7,"OUT");
            webiopi().setValue(7, 0);
        });
    </script>
</head>
<body>
<FORM METHOD="post">
    <INPUT TYPE="button"
        VALUE="Back"
        OnClick="history.go(-1);return true;"">
</FORM>
</body>
</html>


They're really quite simple and they work. I picked GPIO 7 because it's the last pin in the header on the outboard side. (It's the easiest to locate without counting pins.)

From a browser just access these two web pages to turn on and off port 7:

http://192.168.1.210:8000/on.html
http://192.168.1.210:8000/off.html

I can also call these from a web page running on my mac from a couple of buttons. The html on the mac looks like this:

<html>
<body>
<FORM METHOD="post">
    Switch 1
    <INPUT TYPE="button"
        VALUE="On"
        OnClick="window.location='http://192.168.1.210:8000/on.html'">
    <INPUT TYPE="button"
        VALUE="Off"
        OnClick="window.location='http://192.168.1.210:8000/off.html'">
</FORM>
</body>
</html>

Pretty simple... Obviously, you can make these web pages arbitrarily complex, or you could just use the demo code that Eric provides. But for this purpose, the simpler the better.

There are also libraries that allow you to do GPIO manipulation in C.  Here's a C program that turns on and off port 7:


#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>
#define IOBASE   0x20000000
#define GPIO_BASE (IOBASE + 0x200000)
#define GPFSEL0    *(gpio.addr + 0)
#define GPFSEL1    *(gpio.addr + 1)
#define GPFSEL2    *(gpio.addr + 2)
#define GPFSEL3    *(gpio.addr + 3)
#define GPFSEL4    *(gpio.addr + 4)
#define GPFSEL5    *(gpio.addr + 5)
// Reserved @ word offset 6
#define GPSET0    *(gpio.addr + 7)
#define GPSET1    *(gpio.addr + 8)
// Reserved @ word offset 9
#define GPCLR0    *(gpio.addr + 10)
#define GPCLR1    *(gpio.addr + 11)
// Reserved @ word offset 12
#define GPLEV0    *(gpio.addr + 13)
#define GPLEV1    *(gpio.addr + 14)
#define BIT_7 (1 << 7)
#define PAGESIZE 4096
#define BLOCK_SIZE 4096

struct bcm2835_peripheral {
    unsigned long addr_p;
    int mem_fd;
    void *map;
    volatile unsigned int *addr;
};

struct bcm2835_peripheral gpio = {GPIO_BASE};

// Some forward declarations...
int map_peripheral(struct bcm2835_peripheral *p);
void unmap_peripheral(struct bcm2835_peripheral *p);

int gpio_state = -1;

////////////////
//  main()
////////////////
int main(int argc, char *argv[]) {

    if(argc == 2) {
        if(!strcmp(argv[1], "on"))
            gpio_state = 1;
        if(!strcmp(argv[1], "off"))
            gpio_state = 0;
    }
    if(map_peripheral(&gpio) == -1) {
        printf("Failed to map the physical GPIO registers into the virtual memory space.\n");
        return -1;
    }
    GPFSEL1 &= ~(7 << 21); // Mask out bits 23-21 of GPFSEL1 (i.e. force to zero)
    GPFSEL1 |= (1 << 21);  // Set bits 23-21 of GPFSEL1 to binary '001'

    if(gpio_state == 0)
        GPCLR0 = BIT_7;
    else if(gpio_state == 1)
        GPSET0 = BIT_7;

    usleep(1);    // Delay to allow any change in state to be reflected in the LEVn, register bit.
    printf("GPIO 7 is %s\n", (GPLEV0 & BIT_7) ? "high" : "low");
    unmap_peripheral(&gpio);
}

// Exposes the physical address defined in the passed structure using mmap on /dev/mem
int map_peripheral(struct bcm2835_peripheral *p)
{
   // Open /dev/mem
   if ((p->mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) {
      printf("Failed to open /dev/mem, try checking permissions.\n");
      return -1;
   }
   p->map = mmap(
      NULL,
      BLOCK_SIZE,
      PROT_READ|PROT_WRITE,
      MAP_SHARED,
      p->mem_fd,  // File descriptor to physical memory virtual file '/dev/mem'
      p->addr_p      // Address in physical map that we want this memory block to expose
   );
   if (p->map == MAP_FAILED) {
        perror("mmap");
        return -1;
   }
   p->addr = (volatile unsigned int *)p->map;
   return 0;
}
void unmap_peripheral(struct bcm2835_peripheral *p) {
    munmap(p->map, BLOCK_SIZE);
    close(p->mem_fd);
}


Finally, la pièce de résistance: there's also a RESTAPI provided with WebIOPi that you can use to turn on and off GPIO ports - here is how you turn on a port using the curl interface to issue REST POSTs from a Mac:

curl -X POST http://192.168.1.210:8000/GPIO/7/function/out
curl -X POST http://192.168.1.210:8000/GPIO/7/value/1

Even easier than the web interface! As with anything on the Pi, there are a dozen ways to do it! I'll probably use the RESTAPI method with a cron schedule on the Mac to turn lights on and off when we're away.

When the RPi model A's come out, I expect I'll use a couple of them to build some more of these.  Pretty simple and useful tools!

Next time: packaging and wrap up (still waiting for the box to put it in...)

Sunday, February 3, 2013

Web connected outlet - part 5

Headless WiFi Pi

Hooking up wireless on the Pi is pretty easy.  Here's the high-level process:
- Start out by connecting a monitor, keyboard and a downloaded image on your SD card
- During configuration, select that you want SSH installed and running
- Hook up your ethernet connection
- Reboot
- Log in via the keyboard and do an ifconfig to get the IP address of the Ethernet adapter (or just monitor your router during the reboot to see what new IP address shows up. Ethernet defaults to dhcp so you can't predict what IP address it will be...)
- ssh from your computer to the IP address of the Ethernet adapter.  I use this with the password raspberry
All wired up - sans case.
Don't touch anything!
ssh pi@192.168.1.27
- modify /etc/network/interfaces so it looks something like this:
auto lo
iface lo inet loopback
 
auto wlan0
iface wlan0 inet static
wireless-essid [your-wifi-ssid]
address 192.168.1.210
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 8.8.8.8
 
auto eth0
iface eth0 inet dhcp
- plug in your WiFi USB device into the empty USB port on the RPi
- reboot and disconnect your wired connection, keyboard and monitor - you're WiFi headless now.
- you should now be able to connect to the IP address you set up above. (You can always reconnect the wired Ethernet, or connect a monitor and keyboard if something goes wrong.)

Obviously, you'll want to use your own network's ssid and IP subnet.  For these devices, I use an unprotected WiFi network (you'll probably want to use WPA.)  There are lots of good Raspberry Pi wireless configuration resources; just google it...

Note that eth0 follows wlan0 in the file, above. I did this because, if it's not connected to anything, the eth0 connection continuously tries to connect and may just sit there waiting for a long, long time, before the wireless connection gets configured [at least this is my speculation - I couldn't get a wireless connection until I moved eth0 down.]


The WiFi USB device I'm using I got from Newark.com for about $16 [at left.] (For some reason, at this time, the picture on the Newark web page shows something different than what you actually get. View the "Technical Data Sheet" for an image of the actual device.)  I've used a couple of other small USB wireless adapters, but found that this one seems to be most reliable. One of the others apparently had a short and was actually smoking when I pulled it out of the USB port (with my bare hands, BTW. You gotta be tough to be a geek.)


Next time: the web page.

Saturday, February 2, 2013

Web connected outlet - part 4


Connecting the pieces

This is the dicey part.  Dealing with 120VAC is potentially lethal. So, if you don't know what you're doing, don't do it. You've been warned.

So far, I've cobbled together a transistor switch that will allow a GPIO output pin to open and close a relay. I wired it up on a little Radio Shack project breadboard and tested it with 5V on the relay and a 3.3 V signal.  I've loaded the software on the RPi and demonstrated that it controls the GPIO.  I tested the breadboarded relay with the GPIO software just to hear that satisfying click one more time...

Danger, Will Robinson!

 When you're wiring up the circuit to the mains there are some things to be careful of:
- separate the low-voltage and high-voltage parts of the system as much as possible.
- insulate the high-voltage parts
- include a properly rated fuse to keep the house from burning down if there's a problem
- solder everything together - don't just twist wires together and wrap them in electrical tape...
- tie down any loose wires and bolt the components to the case
- remember the wiring codes / color codes for your location - they're there to protect you. In the US, black is hot, white is neutral and green is ground.  On electrical cords and sockets in the US, the wide spade is neutral (wide/white/neutral is how I remember it) and the narrow spade is hot. The round pin is ground.
- protect the system from poking fingers and pets (put it in a box)

I've hacked apart a small 5V 2A supply from a wall wart that was used for some equipment that's no longer in use and shortened the mini-USB cable to hook up to the RPi.

Exciting Video:
Test setup on the bench
Here's a link to a video of me switching on and off a table lamp. Before you watch this, you should sit down and scooch toward the edge of your chair - just to be prepared. It's riviting stuff. http://youtu.be/69POMqXjwls

I didn't have a plastic case that will fit all the pieces, so I ordered a couple of plastic project cases from Amazon.  I'll box it up when they arrive in a week or so. (I'll drill some holes in the case so the RPi can breathe.)

While I'm waiting, I'll get this hooked up to the WiFi network - I've just been using an Ethernet connection for the testing.  I'll discuss this next time.

Thursday, January 31, 2013

Web connected outlet - part 3

Loading up the Raspberry Pi

The Raspberry Pi, out of the box, doesn't do anything.  You need to hook up a monitor, a keyboard, a power supply, an Ethernet cable and you need an SD card loaded with the operating system to make it work.

The instructions at RaspberryPi.org are well written so that's a good place to start. I went to the website and downloaded the latest release of the Raspbian operating system - it's a performance tuned version of Debian Linux for the RPi.  There are several OSes that you can download, but I'm most familiar with Debian and I know it installs easily and works great so I used that one.

I burned the SD card using a little USB/SD adapter and the command line interface on my Mac  (solid instructions also on the RaspberryPi.org website.)  I powered it up, ran through the handy configuration tool.  Part of this configuration provides the ability to turn on SSH. Once I did that, I was able to unplug the keyboard, mouse and HDMI cables and connect to it using SSH, "headless", from my Mac.

Then I did some googling for software to run the GPIO ports - preferably something that I could connect to a web interface.  I found the perfect solution: WebIOPi.  It's basically software that provides a web interface to the GPIO ports.  Exactly what I was looking for!  It's free, but there's a link where you can donate to help support the effort (donate!)

Using the instructions on the  site, I loaded the software.  It took maybe 10 minutes.  The instructions were top notch - there's even a video how-to. When I fired up the web interface, bob's yer uncle, it worked great the first time.  Using a multimeter I monitored the voltage of the GPIO pins as I flipped them on and off using the web interface. I wasted about ten minutes playing with it - hypnotic, really...

Next: wiring it up and testing


Wednesday, January 30, 2013

Web connected outlet - Part 2

Wiring it up

Well, I breadboarded up the little circuit.  What could be easier: 4 components and some wire?  Five minutes, max.

The Raspberry Pi GPIO pins can source up to 16 milliamps, but there's no need to over do it. Just to keep the current to a minimum necessary to switch the transistor, I figured a nice, conservative 3 ma (milliamps) would be fine.  I knew the transistor could do it - I've used them before for this kind of thing. So using I=E/R (current = voltage / resistance), 3.3 V / 1000 ohms = 3.3 milliamps. Certainly close enough for government work, so I wired it up.

The only problem was the transistor wouldn't switch with anything more than about 500 ohms (about 7 ma.)  What gives? The transistor I used, a 2N2222, has been used in millions of switching applications and it should switch at a couple of ma of base current with no problem.

Turns out that the batch of transistors I bought (cheap on ebay) didn't use the "standard" lead configuration.  In most 2222's the pins are, from left to right facing the "flat" face of the transistor: EBC (emitter, base, collector.)  For some reason, this batch had it reversed (CBE!?!). Doh!

It took me a while to figure that out...  Once I flipped it around ("backwards"...) it switched just fine at less than 2 ma (using a 2K resistor.)

I guess I should learn a lesson or two from this:
- Buy cheap transistors: you may not get what you think you're getting
- Always check the spec sheet (geez - these didn't even come with one...)
- Always trust your instruments (I briefly entertained the thought my milliammeter might be off...)

Oh well, live and learn!

Next time: loading up Raspbian on the Pi.

Tuesday, January 29, 2013

Web connected outlet - Part 1

OK, so what do I need to do to connect an electrical outlet to the web?

- Drive a 5V relay with a 3.3V output (because I don't have any 3.3V relays.)
- Get the Pi working on a WiFi connection
- Write some software for the Raspberry Pi that lets me turn on/off a GPIO pin
- Get a web page connected to the GPIO switch app.
- Wire it up
- Test it
- House it in a pet-proof plastic enclosure


The hardware is the easy part.  I need to switch a 5V relay with a 3.3V output on the RPi.  I think an NPN transistor, a resistor, a diode and a relay will do the trick.

So, first I'll wire this up and test it with 3.3V input, to simulate the GPIO.

I need 5V for the Raspberry Pi, so I can use the same power supply for the relay.  I'll probably hack an existing wall wart to enclose in the box with the RPI and relay circuit.

Next time: Load the RPi with the latest Raspbian and get WiFi working.

Monday, January 28, 2013

The next project: a Raspberry Pi light switch.

I'm a big fan of the future, in general, and 'The Internet of Things' in particular.  As connectivity gets cheaper, more and more common 'things' will get connected.  The more of them that can communicate with each other, the greater the network effect, and the more value we can get from them all.

But regarding actually implementing this stuff in my house I'm somewhat ambivalent.  

George Jetson is expected to invent the Internet of Things
sometime in the late 21st Century based on advanced
Spacely Sprockets technology.
I have an Internet connected thermostat, but I still use mechanical timers on lights in my house.  I have an Internet connected phone system, yet I have a dedicated/stand-alone sprinkler system. I have an Internet connected TV but my garage door opener uses wireless connectivity from the 60s. (And I still don't have a flying car...)

I've been reluctant to buy into the various connection schemes like X11 and the like, thinking that a more generic connectivity (via 802.11) would be a better long-term bet.

Now, with the availability of an 802.11 connected computer for $35 (a model A Raspberry Pi and a $10 WiFi USB nub) it's getting to the point where dedicated devices like this are actually affordable - particularly compared to Internet connected lightbulbs for $60...

So, my next project will explore a web connected electrical outlet.




Sunday, January 20, 2013

More PBX adventures

UPDATE: SIPStation must have made some more changes - trunk2 no longer works for incoming calls.  But trunk1 does. Caveat lector (the sip.conf below shows trunk2. At some point, that will probably be correct again...)


I've been using my Intel Atom computer for home phone PBX service for the last couple of weeks using Asterisk/FreePBX.

Several callers complained that incoming calls were either being dropped or "answered" with a fast-busy.  I verified that this was the case; calling in from work for a couple of days, I found that about 50% of the attempts to call home were successful. That's not good.  A service request to AXVoice got them to attempt to dial in.  Of course the few times they called, it worked...

So, I did some digging - using a different computer for the PBX, loading the PBX onto the Raspberry Pi, putting the PBX outside of the firewall/router, using a different router, changing NAT settings in the PBX, changing QOS settings in the router, turning on port forwarding, etc., etc.

Based on the log files and activity log at AXVoice, I concluded that AXVoice was just not connecting about half the time.  So I signed up with another SIP provider for a test.  For this test I used a SIPStation trunk and dialin line.  

I had played with an earlier version of Asterisk before (1.8) and got a couple of extensions and incoming/outgoing calling going on it.  This time, I loaded the latest version (11) and took it for a spin.  While I was at it I loaded a new version of Ubuntu server on the Intel Atom platform and used that.  During this testing, I moved the house phones back to our cable phone provider.

Turns out that SIPstation incoming calls worked just fine... 

But, wait: there's more.  

SIPStation only offers domestic calling. My AXVoice plan has unlimited calling to 40 countries, including Switzerland (where Cindy's mom lives.)  So, it looks like I'll just keep both services for now - at least until SIPStation offers international service, or until AXVoice fixes their problem.  Even paying for both of them is cheaper than our monthly bill used to be from Telecom*USA.  If it continues to work well, I'll drop the phone service I have with our cable company and port that number over to SIPStation.

If you're interested in the sip.conf and extensions.conf that make Asterisk go,  you'll find them below.  There are also some Netgear router settings that I needed to adjust (just ask...)

There must be thousands of Asterisk implementations in small business around the world - the interwebs are just brimming with information on configuring Asterisk.  Unfortunately, there are so many different versions and front-ends that much of it is a little misleading.  The best resource is O'Reilly's Asterisk, The Definitive Guide [ISBN: 978-0-596-51734-2] (an on-line version is available for free...)

It gets more interesting the further down the rabbit hole one goes!

_______________________________________________________________________________

sip.conf
[general]
externhost=amos-family.dyndns.org  ; because we're using dynamic dns
localnet=192.168.1.0/255.255.255.0 ; used for NAT traversal (necessary?)
externrefresh=60                   ; how often to recheck the external IP

context=unauthenticated            ; default context for incoming calls
allowguest=no                      ; disable unauthenticated calls
srvlookup=yes                      ; DNS SRV lookup - mostly for external SIP
udpbindaddr=0.0.0.0                ; listen for UDP requests on all interfaces
tcpenable=no                       ; disable TCP support

register => [username]:[password]@trunk2.phonebooth.net ; trunk1 doesn't work...

[office-phone](!)                  ; create a template for our devices
type=friend                        ; channel driver matches username then IP
context=phones                     ; calls from the device enter the dialplan here
host=dynamic                       ; the device will register with asterisk
nat=no                             ; the office phones are on the same net as PBX 
secret=[phone password]            ; a secure password for this device
dtmfmode=auto                      ; accept touch-tones from the devices
disallow=all                       ; disallow codecs except those allowed below
allow=ulaw                         ; which audio codecs to allow...
allow=alaw                         ; ...in the order we prefer

[201](office-phone)                ; set up phones using the "macro" above
[204](office-phone)
[205](office-phone)

[sstn]                             ; set up SIPStation trunk, used for incoming calls
type = peer
host = trunk2.phonebooth.net       ; only trunk2 appears to work...
username = [username]
context = incoming_calls           ; where incoming calls go
secret = [password]
insecure = invite,port             ; apparently "very" is deprecated
dtmfmode = rfc2833
disallow = all
allow = ulaw
allow = alaw
nat=no                             ; this appears to work, though we use NAT...
canreinvite=no                     ; ... took a lot of time to figure this out.
qualify=yes
sendrpid=yes
trustrpid=yes

[AXVoice]                          ; set up AXVoice trunk, (used for unlimited outgoing calls)
type = peer
host = magnum.axvoice.com
username = [username]
secret = [password]
insecure = invite,port 
dtmfmode = rfc2833
disallow = all
allow = ulaw
allow = alaw
canreinvite=no
qualify=yes
sendrpid=yes
trustrpid=yes


extensions.conf
[globals]
[general]
[incoming_calls]
exten => _X.,1,Dial(SIP/201&SIP/204&SIP/205)   ; a cheap ring group...

[outgoing_calls]
exten => _011.,1,Set(CALLERID(all)="Amos"<[my phone number]>)
same => n,Dial(SIP/AXVoice/${EXTEN})
same => n,Hangup()

exten => _1NXXNXXXXXX,1,Set(CALLERID(all)="Amos"<[my phone number]>)
same => n,Dial(SIP/AXVoice/${EXTEN})
same => n,Hangup()

exten => _911.,1,Set(CALLERID(all)="Amos"<[my phone number]>)
same => n,Dial(SIP/AXVoice/${EXTEN})
same => n,Hangup()

exten => _NXXNXXXXXX,1,Set(CALLERID(all)="Amos"<[my phone number]>)
same => n,Dial(SIP/AXVoice/${EXTEN})
same => n,Hangup()

[internal]
exten => 201,1,Verbose(1,Extension 201)       ; just puts something in the log 
exten => 201,n,Dial(SIP/201,30)
exten => 201,n,Hangup()

exten => 204,1,Verbose(1,Extension 204)
exten => 204,n,Dial(SIP/204,30)
exten => 204,n,Hangup()

exten => 205,1,Verbose(1,Extension 205)
exten => 205,n,Dial(SIP/205,30)
exten => 205,n,Hangup()

[phones]
include => internal
include => outgoing_calls


Friday, January 18, 2013

New server paradigm

Facebook uses a lot of servers.  A way lot of servers.

Frank Frankovsky thought there were inefficiencies in the design, manufacture and disposal footprint of the commercial servers he was buying, so Facebook started building their own.

What they learned from this endeavor has been embedded in what they're calling the Open Compute Project.  The folks over at Business Insider have done a great job describing the project, so if you're interested, head over there for more.

Here's my take.

I really love the idea of Linux - a lot of great stuff is built on it, it's fun and there are a lot of really talented geeks doing amazing things with it (Android is based on it.)  It's "open." That means lots of people can contribute, to add their expertise and ideas to improve it.

That also means a lot of great free software: LibreOffice (a very functional replacement for Microsoft Office), Gimp (an alternative to Adobe drawing software), Apache (a popular web server), MySql (the most popular open database server), Asterisk/FreePBX (a PBX for homes and small businesses) - the list goes on and on.  The Ubuntu desktop that I'm using on a couple of computers at home is another example - great desktop software that performs well on even old, underpowered computers.

Recently there has been some movement in open hardware that promises some of the same benefits - inexpensive devices supported by communities of interested users and talented geeks.  Many 3D printer tools that are appearing on the market are open hardware.  The Raspberry Pi, while not technically "open", is moving in that direction. HPSDR (a bleeding-edge "Software Defined Radio") has open hardware.  The whole "maker movement" seems to be headed in that direction.

With the backing of Facebook, the Open Compute Project could give this open hardware movement a big boost.

Check it out.


Wednesday, January 16, 2013

Cleaning up the PBX

I've been using an Intel D945GCLF mini-ITX computer for my home PBX for a couple of weeks now.  However, it has had some periodic problems.  Every so often the caller hears a  delay (no ring) and then the call either drops or he gets a fast busy.

I thought perhaps it was a problem with my provider, AXVoice, but found something interesting when I loaded FreePBX/ Asterisk on my Raspberry Pi.  This problem doesn't happen using the RPi(!)

I'm still trying to run this down - I've installed a couple of different versions of Asterisk with and without FreePBX on the Intel box, using the same configuration as on the RPi but the problem still happens on the former but not the latter...

It may be a LAN issue - I'll move some stuff around and see if the problem follows the changes.

In the mean time, the RPi is working just fine as a PBX...  Go figure.

While I was doing this testing, I thought I might as well clean up the Intel box - it was just sitting in a metal box with a big fan on top of a big old 500 Watt power supply with an IDE disk drive wedged in under some cables. It works, but it's not pretty.  And, because the top is open, I can't set anything on top of it (like coffee cups or cold drinks or bowls of soup...) 

So, I'm cleaning it up. I thought I'd try a couple of components from Mini-Box.  They make a small ITX enclosure and some equally small power supplies for them.  

The box is designed for mini-ITX computers and everything fits nicely.  I'm using a 2 1/2" SSD as a main disk (very little get's written to the disk when I'm not debugging) and don't normally have.  I'm using a 120 Watt power supply that plugs into the motherboard and uses and outboard 12V transformer.  

I added an extra fan and configured it to re-boot on power loss/return (so that the phones come back up after a power outage.)  I probably ought to put this on a UPS along with the router, switch and cable modem.

In any case, (in this case...) it looks much nicer now and at least now the cat won't be able to get into it.

I built another one just like this but with two Ethernet adapters (one on the board and another in the only expansion slot.)

I'm thinking of loading up some firewall or network monitoring software on this one.  

I'll report on that effort here as it gets going.

Now, back to tracking down that pesky call drop problem!



Tuesday, January 1, 2013

Home PBX Project - Redux

The FreePBX home PBX is working great.  I've got a half dozen extensions connected including X-Lite for PC's, Bria for the iPads/iPhone, an OBi202 WiFi analog phone "adapter" connected to our wireless phones and a Nortel LG-1535 for my office.  These Nortel desksets are inexpensive, but they're really nice.  I got this one on E-bay - it was packaged in a new box, but was set up for Turkish... (simple config option to get it to English.)

I've forwarded my home phone number to the new PBX and changed the outgoing Caller ID to match the home phone's number.  So, now the whole house is using the new service transparently (i.e. you just pick up the phone and dial, all the phones ring with either incoming number, CallerID works, etc.)  I'm using the AXVoice SIP International Home service so I get unlimited voice to the US and 40+ countries and when one phone is busy, I can just pick up another and dial.  It comes out to about $18 / month.




The PBX is currently running on an Intel Atom mini ITX board (a D945GCLF2) running a headless version of FreePBX / Asterisk / Centos. (I think you could get this configuration running on just about any old PC you have laying around. I first brought it up on an old Dell tower.)

This past weekend, thanks to Technical How To  and Asterisk: the Definitive Guide,  I got a "raw" Asterisk instance running on Ubuntu 12.10.  This doesn't have all the bells and whistles of the Centos version, but it did give me a look at configuring Asterisk using it's own configuration files.  I brought up a simple 2 extension PBX connected to AXVoice just to demonstrate that it works.  It took a couple of hours, some digging in the Asterisk book and Google - and two config files.  In addition to being a great Asterisk technical reference, the book has some great background on telephony.

RPi CID on a tiny 3" screen



I'm still using my CID decoder running on the Raspberry Pi to produce a web page with the Caller ID, but I'm thinking I'll move this function to the PBX - where it belongs - and reuse the RPi for something else!

The idea behind this project was to A.) learn something about Asterisk; B.) get unlimited calling; C.) have some fun - and all of these objectives were met!   If you're at all interested in learning about telephony (or a home PBX) I'd highly recommend the exercise!