International Voice + SMS forwarder: International Call Forwarding

Previously: New Project: International Voice + SMS Forwarder

Using Zapier's instructions for How to Build a Smarter International Phone with Twilio in Just 15 Minutes, I was able to set up voice forwarding that would be ready the instant my phone number ported in.

The 30 second version of those instructions is:

1. Set up a Twilio account
2. Apply to port in your phone number
3. Modify your Geographic Permissions to allow international calling.
4. Wait for Twilio to approve your request (this took 24 hours for me)
5. Set up voice forwarding with a Twimlet
6. Wait for the port to complete (3 business days)

I'm going to focus on step 5, which is the most complex part.  Using some tools from Twilio, it's actually pretty easy.

When you view your porting in request, you can set up URLs to configure how to handle voice and SMS.  Twilio will load that URL and it will do some action based on the response.  For voice calls, the following response will forward a call:

<Response>
  <Dial action="/forward?Dial=true" timeout="20">
    33651xxxxxx
  </Dial>
</Response>

It's silly to set up a web server just to serve a simple XML document.  Even something simple like putting an XML file in an AWS S3 bucket is a a bit of work.  So Twilio offers something called Twimlets, which are pre-made services that generate XML documents for basic phone tasks like forwarding, simultaneous ringing, or accepting voicemail.  You use their configuration tool to generate a Twimlet URL, and you just paste that URL into your Voice configuration.

The phone number has the country code (33), followed by the number I want to forward to (6 51 xx xx xx).  You can see the output this URL produces:

mbenza:~$ curl http://twimlets.com/forward?PhoneNumber=33651xxxxxx
<?xml version="1.0" encoding="UTF-8"?>
<Response><Dial action="/forward?Dial=true" timeout="20">33651xxxxxx</Dial></Response>

This XML is the same as the XML example above, just without formatting to make it easy to read.  Once your phone number ports over, Twilio will forward calls from the number you ported in to the number in your Twimlet.

SMS forwarding is a different beast.  Twilio doesn't offer a Twimlet for that.  The main difference between voice and SMS forwarding is that there's a different behavior each time  for SMS; the sender and message changes with every SMS.  For voice calls, the "forward" command automatically encapsulates the caller into the process.  For SMS, there's no forwarding command in Twilio, so you've got to build something to do that for you.

Previously: New Project: International Voice + SMS Forwarder
Next Update: SMS Forwarding Part I

GSM Motion Sensor: Everything arrives

Previously: New Project: GSM Motion Sensor

The PIR (Passive Infrared sensor) + MSP430 development board and the SIM900 development board (GSM / cell service) arrived the day before I moved to France.  I quickly shoved them in my luggage and then ignored them for a few days.  Everything should just work, right?

The Passive Infrared Module is tiny.  Maybe 1" by 1.5".

 

And the SIM900 came, too.  Looking more closely at it, there's a lot of stuff on that board.  I started thinking, "It must take a lot to power all that.  Did I buy two different wrong things?"

My plan was to first get my old MSP430 working – one that I bought in 2012 – then worry about the new one, and finally work on integrating the SIM900.  I looked for Code Composer Studio, the MSP430 development suite and I found out it's not supported on OS X.  But wait!  There's a beta for OS X.  I looked into the beta and found out that it doesn't support my first generation MSP430.

Three year old software usually works just fine. Even 20 year old software works fine on emulators.  Why doesn't three year old hardware work fine?  Electrical engineers, I'm looking at you.

Trying to be positive, and remembering that I've invested money in this, I figure I'll move on to the new MSP430 (with the integrated PIR sensor).  I start looking for the pins to connect, as my wife's cousin John had suggested on Facebook.  They don't exist.  You need a special $70 JTAG programming tool from the manufacturer to program the device.  Or a different one for $115.  More frustrating is the fact that there's a base standard for how to implement JTAG, but different manufacturers expand it in different ways, then charge you an exorbitant amount of money for their specific JTAG programmer.  Not only can I not start small on a known introductory system (my old MSP430), but I can't even start on the more challenging device.

The Olimex PIR device didn't even have the jumpers its manual advertised for switching between TI's JTAG implementation (Texas Instruments designed and manufactures the MSP430) and Olimex's JTAG implementation.

The "jumpers" are solder bridges.  I don't have a 220V soldering iron, so there's no chance I'll be fixing those soon.  Plus I'm not sure I want to buy one that's high enough quality to solder these 1.5mm x 2mm pads right next to an extruded plastic component.

I went back to Facebook to gripe / vent / ask for help and luckily my old National Instruments coworker Craig was able to point me the open source hardware project called Armstrap developed by another NI coworker, Charles.

After a couple emails back and forth with Charles, I decided to buy an Armstrap.  I had it sent to my dad's and I'll get it in two weeks when I visit the US.

The Armstrap is built on a different architecture than the MSP430.  It's got an ARM microprocessor (CPU), specifically the Cortex M4.  The ARM architecture is targeted at a bit of a different market segment than the MSP430.

The MSP430 is very low-level.  The processor on the PIR device I bought is only 16MHz, which is about 160 times slower than the modern laptop processor.  And there's only 2KB of RAM to hold your program (that's about 14 tweets).  But for such a weakling processor, it consumes a minuscule amount of power: about 3mA when active and 0.5µA when sleeping. 

For comparison, a standard smart phone battery provides 2800mAh (2800 milliamps for one hour), so the MSP430 in active mode would last 39 days on a smart phone battery running at full power.  In theory it'd last 600+ years in sleep mode on a smart phone battery, but realistically it'd be much shorter than that, but still over a year.

The ARM on the other hand is a bit higher level.  It's processor runs at 180MHz and consumes about 18mA when active and 12µA when sleeping.  It's got more RAM (192KB - 256KB). Thankfully, almost all of the time will be in sleep mode.  In theory, that's only 26 years of sleep mode.  Practically it'll be much shorter than that, but I think it'll still be over a year.  So I think the Armstrap will work for me.

Previously: New Project: GSM Motion Sensor

Next Update: Getting the Armstrap (est. Thanksgiving)

New Project: International Voice + SMS forwarder

When I moved to France, I got a French phone number.  It works just like an American phone number – I can get calls, SMS (text) messages, and MMS (picture, video, and group) messages.  But it's very expensive for Americans to call or text it.  Most carriers charge about $1-$2 a minute and $0.50 per text and won't even support international MMS.  I don't expect people to call me and spend any more than they're used to.

I want people to be able to call and text me at my old number and have it forward to my new number.  There are services out there that do something like that, but each lacks some feature I need or want.

• Google Voice audio quality is atrocious and depends on a high-bandwidth connection.
• Magic Jack requires a device in your home plugged in, and it's expensive.
• Skype doesn't support SMS forwarding.
• ring.to will forward phone calls to US numbers and can receive SMS, but usability seems terrible.
• Many other services charge a base rate of a few bucks a month ($5-$30), plus a high per-minute voice rate ($0.10+)

So, that means it's time to build my own.  My requirements are:

1. Cheap ($5 or less per month, $0.05 per minute or less)
2. International voice forwarding
3. Good audio quality with minimal delay
4. SMS forwarding, either direct or via email
5. MMS forwarding would be nice.
6. The ability to reply via SMS or MMS would be great.

My original plan was to use a service called CallWithUs, which allows you to set up call forwarding and has great international rates.  I'd port my phone number to Google Voice and then have that forward to my CallWithUs number, which would forward to my French number.  Google Voice has good SMS and MMS support (and can forward calls without getting their poor audio quality in the way), so I started working on that.  It seemed convoluted, but it made sense.

I set up CallWithUs and had it forward to my French number.  Then I went to have Google Voice forward to my CallWithUs number and it wouldn't let me forward.  A post on the Google Voice product forums went unanswered, so I gave up on that.  As is always the case with Google, you get what you pay for.  Too bad I already paid for a number on CallWithUs.

I was at the AWS re:Invent conference a few weeks ago and met some guys from Twilio, a company that aims to make voice, SMS, and MMS internet-friendly.  They mostly target much bigger users who have frequently changing voice and messaging needs, but they have low entry-level pricing and developer-friendly documentation.  I signed up, and got started.

The general process to port in my US phone number, set up call forwarding, and set up SMS forwarding.  For now I'll just have it forward SMS messages to my email.  In the future I might add the ability to reply via email to texts, forward MMS messages to my email, and maybe even support replying via email with MMS messages.

I've only started porting in my US phone number, and I've followed the directions for international call forwarding, so we'll see what happens when the port request goes through.

Next up: International Call Forwarding

New Project: GSM Motion Sensor

My first project will be a motion sensor that will alert me thousands of miles away if it's triggered.  There's actually a really good reason why this is the first thing I'm making.

When I was packing up to move to France, I rented a storage unit.  When I was signing the lease, I overheard the manager talking to a new employee, explaining that theft occasionally happens there and all the stuff she had to do to be vigilant.  That made me think: if someone broke into my storage unit then put a new lock on, it would be months before I knew about it.  The video tapes and access records would probably be long gone.  So, I set out to make something that would let me know as soon as someone entered my storage unit.  

The requirements are simple:

• It must run on a battery for up to 12 months
• It must not rely on WiFi
• It must be relatively cheap

I couldn't find any product that combined these three.  There are GSM game cameras ([1], [2]), but they're very expensive and I couldn't find anything about their battery life.  I considered using my Raspberry Pi with a GSM shield, but the power draw on a Raspberry Pi would kill even the one of the largest USB battery packs you can buy in a week (40000 mAh / 230 mAh for an idle Pi = 174 hours = 7.25 days).

I know a passive infrared (PIR) sensor draws very little power – on the order of 5 µA.  And I know the MSP430 from TI has an ultra low power draw in sleep mode.  Plus, you can get a SIM300 or SIM900 GSM chip that supports serial or SPI communication and can sleep using very little power.

So, it seems like I've got a basic plan sketched out: An MSP430 that will be triggered by a PIR sensor with a SIM300 or SIM900.  I was able to find a MSP430 combined with PIR sensor, so that would eliminate all of the analog electronics.  I bought that, then started asking for advice.

I asked on Facebook, and I got some helpful feedback from one of my old coworkers, Eric, and my wife's cousin, John.  Plus a not-so-helpful comment from my mom.

After I ordered everything with next-day shipping so I could bring it to France, I started thinking if I was getting in over my head.  Is this too big of a first hardware project?  Did I just waste a bunch of money on projects I'm not going to finish?



Next up: GSM Motion Sensor: Everything arrives.

An Introduction

As I sat down to write this introduction, I realized that I don't have a concrete idea of what I want to write about.  I have some technical topics I'd like to write about, but other than that, I'm not sure.  We'll see where it goes.

My initial goals are to document my progress on some tasks I've set out for myself. Hopefully I'll be able to stick to these better than others I have in the past.  My first two projects are a GSM-enabled infrared sensor and an international phone + SMS forwarding system.

I'm working on the GSM-enabled infrared sensor is because like to get more into hardware hacking and learn more about digital electronics.

The international phone + SMS forwarding will be so that I can keep my old US phone number and have something more reliable than Google Voice.

For more information, check out the About Me page.