I had need of a 3.3v TTL serial interface to reprogram a device I was working on. Looking around I realized I had mostly 5v logic USB to serial adapters. I figured the Raspberry Pi would work well enough, but I also needed hardware flow control. As it turned out the Pi can do RTS / CTS flow control, so I documented my notes on the subject here in case I or someone else might find them useful in the future.

What is flow control

In serial communications occasionally we need a way to tell the device or computer on the far-end of our serial connection that we need it to shut up for a bit while we collect our thoughts. Flow control exists for this purpose, although it is not a requirement of serial communication. Modern devices are fast, with large buffers for collecting incoming data, and often times flow control is omitted, particularly if data loss isn’t critical.

Flow control can be done in software (Xon/Xoff) by sending special control characters to say stop or start the data flow. This creates some hassle since, particularly in the transmission of binary data, those control characters might come up naturally without the intent to change the flow of data. If you’ve ever accidentally frozen your Linux terminal (^s / ^q) you know what I’m talking about.

Flow control can also be done out of band of the data transmission using dedicated signal pins/wires, we call this hardware flow control. Serial communications are old, there are a lot of variations so it probably isn’t much of a surprise to learn that there are multiple ways of doing hardware flow control. The most common are RTS / CTS and DTR / DSR. We are focusing on RTS / CTS, although DTR is still useful to know about (it gets used for example in programming the Arduino, to trigger a reset of the Arduino before programming). Because we can arbitrarily set the state of RTS and DTR via software we can abuse them to signal all sorts of stuff to connected hardware beyond just flow control.

RTS stands for “Request to Send”, and in the current common use it is a terrible name for what it actually does. The name implies that it signals a request to send data to the equipment on the other side of the serial connection. CTS stands for “Clear to Send”, and as we might (correctly) assume it is a signal being sent to us from the far-end that indicates we are cleared to send our data. The problem with this is that it is only half-duplex (it goes just one way). How could we tell the far-end that we aren’t ready to receive data? Originally this was actually how it worked, it was intentionally half-duplex and it was designed with some rather old modem technology in mind.

RTR or “Request to Receive” is probably a better name for RTS as it is used today, and some people prefer to use this term instead. We, or rather the UART controlling our communication doesn’t actually change the state of RTS when it wants to transmit data. RTS/RTR gets changed when the UART is unable to receive any more data from the far-end. This probably indicates that our hardware receive buffer is full and hasn’t been read and emptied out by software on our system yet.

On the Raspberry Pi RTS is set low (0v) as long as the Pi’s UART is ready to receive data. If it can’t handle more incoming data it sets RTS high (3.3v). Our Pi should only send data to the far-end when the state of our CTS pin reads low and we should stop sending data if our CTS pin is high. So now we’ve got a working plan for bi-directional flow control. Our RTS goes to the CTS of the far-end and the far-end RTS goes to our CTS (and hopefully we both agree on the logic levels).

In our serial connection RTS and TX are our outputs, and CTS and RX are our inputs.

Where are the RTS / CTS pins?

On older versions of the Raspberry Pi with 26-pin GPIO header, you need to solder on an additional 2×4 section of dual row male 0.1″ (2.54mm) header pins on the unpopulated “P5” header.

On early Pi’s like the original version B, this header isn’t there, and so if you are still using one of those devices you’ll probably need to work something else out.

The P5 header is actually intended to be mounted on the bottom of the Pi board (opposite to the 26 pin GPIO). That seemed pretty crazy to me, because the thing would obviously never lay flat or fit in standard cases that way. I think the intent is to avoid interfering with Raspberry Pi hats that sit on top of the 26-pin header, but even with P5 populated on the reverse side of the board (same side as the 26-pin headers) I was able to put the one hat I have on my Pi. Your miles may vary of course. If you do put the P5 header on the same/sane side of the board as the 26 pin header keep in mind that many of the pin-outs you run into online might be mirrored.

To remove ambiguity I’ve just colored the correct pins below rather than giving pin or GPIO numbers:

On newer Raspberry Pis with the 40-pin header, this is much easier, there is nothing to solder first:

Enabling RTS / CTS flow control

OK, so now we’ve got the physical connections handled, but we still need to enable the RTS/CTS mode of these pins. As you might know several (most) of the Raspberry Pi GPIO pins live double (or triple) lives. By instructing the Broadcom SoC to enable the alternate functions we can get additional hardware features, I2C, hardware flow control for our UART, etc.

We need to change a bit of memory to inform the Broadcom SoC which function of the GPIO we want. An easy way to do this for RTS / CTS is to use Matthew Hollingworth’s rpirtscts utility:

https://github.com/mholling/rpirtscts

The last little note about stty in the rpirtscts help message is useful to mention. If you are using software that is aware of hardware flow control (i.e. will use the ioctl syscall to enable / disable it) you don’t need to worry about setting the stty option. If you are sending input/output from programs over serial that are not specifically intended to be sent over a serial line, then you will probably want to tell stty to tell the system to enable RTS / CTS. The rpirtscts utility sets the Broadcom SoC to use the RTS / CTS alternate functions of the applicable GPIO pins, but it doesn’t tell Linux to enable RTS / CTS flow control.

Current versions of rpirtscts can detect which Raspberry Pi you are using and take the appropriate action for that hardware.

Using rpirtscts on the 26-pin Pi looks like this:

The 40-pin Pi is set with the same command, but uses the (different) correct GPIOs for that hardware:

As an alternative to rpirtscts, if you’d like the CTS / RTS alternate function to be the usual function of your particular Pi (and persist across reboots) you might instead consider configuring a device tree overlay:

https://www.raspberrypi.org/documentation/configuration/device-tree.md

Also note that the Raspberry Pi 3 uses the ttyAMA0 port for driving Bluetooth, so there are some additional considerations to deal with. Thankfully Weave has this is all well documented here:

http://www.deater.net/weave/vmwprod/hardware/pi-rts/

Good luck!

Check out http://www.pighixxx.com/ for great art of popular electronics.

We’re running an older installation of Elastix at my office, version 2.0.0 (release 58) on top of freePBX version 2.7.0 (release 10). The call trace feature was bothering me. This feature is mapped to the *69 feature code as is common with many LECs in North America. In the default implementation you hear an announcement about the number of the last incoming call, and can then optionally press the “1” key to call the party back. I was frequently annoyed with having to wait for the IVR attendant to finish announcing the number of my last incoming call, I couldn’t interrupt the announcement without waiting for her to finish. Seemed pretty clear that I needed to replace Playback() with Background() some place.

Here is a video showing the original behavior, and the modified behavior.

Inside of /etc/asterisk/extensions_additional.conf is a context for [app-calltrace-perform]. Originally I made the correction in there, completely ignoring the header comment that read “Do NOT edit this file as it is auto-generated by FreePBX”. This worked, for a little bit, until changes were made and applied in the Elastix web interface, and then as promised the config was overwritten by a new auto-generated configuration.

It appears the correct place to add this is in /etc/asterisk/extensions_override_freepbx.conf

I appended the following lines to the end of extensions_override_freepbx.conf to accomplish the desired change.

When done, save the file and reload the dialplan

This all comes from Elastix (well technically FreePBX I think) other than the replacement of Playback() with Background() during the playback of info-about-last-call.gsm. Of course I also had to move Set(lastcaller..) and stuff above Background() since we can now jump straight to exten => 1,1 without having those variables set.

I’m not sure if this has changed in later versions of Elastix 2.x. I have to assume this annoys other people as well, but maybe it’s just me. If you have anything to add let me know in the comments.

Thanks

UPDATE: This article (and sadly many others) have sat in my “Drafts” folder for far too long. I had originally intended to give this a look-over before release about a year ago, but I never got around to it. One of my co-workers recently reported a problem with the weather display on their IP phone. It seems that the Yahoo! feed may now be down (as predicted in this article). I’m publishing this now to assist anyone who may be interested in working on a MITM-type replacement for it. The original intent of this article was to help people find the appropriate city-code for their area.

Grandstream GXP21xx-series phones have a neat weather application. I’m using a GXP2140 with color screen and I thought it would be nice to display the weather on the home screen (a feature native to the phone).

The trick is trying to find the Location ID, or as Grandstream calls it “City Code” for your area. The phone automatically tries to find the best Location ID to use, but at least in my case, it wasn’t as accurate as I would have liked. So how do you find the correct location?

A packet capture shows that the phone grabs its weather information from Yahoo!

A little research shows that Yahoo! gets this data from Weather.com, and these Location IDs are Weather.com related. You can query weather.com for a Location ID for a given place name in text form at the following link:

http://wxdata.weather.com/wxdata/search/search?where=London

Only the first 10 results are shown:

Let’s use New York, NY as an example.

A few different results are returned for “New York“, but the one we want it USNY0996. Once we know this code we update it in the web interface of the IP phone. In the case of my phone this was found under Settings -> Web Services

It looks like Yahoo! is using a newer API for weather these days, so I’m not sure how much longer these phones will be able to get weather. Documentation about the API is available here:

https://developer.yahoo.com/weather/archive.html

For posterity I’ve included a quick partial example of the output from these requests, in case you should ever need to implement your own service (to be intercepted at your firewall, or via DNS) in order to maintain this feature on your phone.

The results have been trimmed down for brevity

This article is about adding manufacturer information when displaying MAC addresses in bash script output to create friendlier data for the user. A manufacturer name can suggest more about a device than just the MAC address alone. For example, if you saw a MAC address with an OUI of B8-27-EB it probably wouldn’t mean much to you, but if you saw the name “Raspberry Pi Foundation” you’d have a pretty good clue that the device in question was a Raspberry Pi.

As you may know, MAC address ranges are registered to manufacturers by the IEEE Standards Association. The IEEE-SA provides a web-based look-up form where you can see which OUI is assigned to a vendor, or vice versa. It’s possible for your script to scrap the IEEE-SA’s web look-up resource (in fact I’ve done that in a script to detect and report new Wi-Fi clients on my home network). This is a slow (and not very nice) process when dealing with a larger number of MAC addresses, and so an offline method would be preferable.

The IEEE-SA has a set of data files you could download for this purpose:

http://standards.ieee.org/develop/regauth/oui/oui.txt
http://standards.ieee.org/develop/regauth/iab/iab.txt
http://standards.ieee.org/develop/regauth/oui36/oui36.txt

That method requires occasionally freshening local copies of those files to make sure OUI assignment changes are reflected in the script output.

An alternative option, and the one I’m going to be using is to reference the data in the “manuf” file that Wireshark uses for this same purpose. Wireshark displays ethernet addresses by replacing the vendor/OUI portion of the MAC address with a shortened vendor name, but leaves the unique device portion of the address untouched. Here is an example screen shot taken from Wireshark:

You can see that the MAC address 1c:6f:65:95:2b:ad belongs to a device made by Giga-byte and it is talking to 00:07:50:52:86:d1, a device made by Cisco.

If you download Wireshark’s “manuf” file through your package manager, you should receive updates to this list as part of your normal update routines. It is not necessary to download a full copy of Wireshark. Under Ubuntu and probably other Debian-based systems the file is provided by the package libwireshark-data.

On Ubuntu the manuf file resides in /usr/share/wireshark, but you might need to update the script for your system.

The above example uses shell built-ins, but if you do not care about the purity of your bash script you could use grep (as shown in the comment) and omit the get_line function from your script for faster results. Notice that this script doesn’t currently parse OUI ranges that are shared across manufacturer’s despite that information being available in the manuf file.

Need an Asterisk setup? Why not combine the long term support of an Ubuntu LTS release with the long term support of a Certified Asterisk release?

Certified Asterisk releases are supported for around 4 years, and Ubuntu LTS for around 5 years, helping ensure you don’t need to mess around with major reconfiguration again for some time.

We’ll be working with Certified Asterisk 13 and Ubuntu 14.04. Certified Asterisk 13 has an end-of-life date (EOL) of October 24, 2019, and Ubuntu 14.04 has an EOL of April 2019.

A list of Asterisk versions and their end of life dates can be found here:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

Prerequisites

Let’s start by making sure we are up to date

Make sure kernel headers are installed

Grab a sensible build environment along with subversion and git which we will use later to retrieve additional source code

For many people, the next two sections will be optional, you can probably skip down to the “Asterisk” section below.

DAHDI

On the system I’m working with, I have a Digium T1/E1 PRI card, so I’m going to grab the DAHDI modules and tools as well. You may want to install DAHDI regardless of your hardware for the dahdi_dummy timing driver. At one point the Zaptel dummy driver was used for MeetMe conferences when Digium hardware based timing was absent, although I’m not sure if this still remains the case.

We’ll be building our source under /usr/local/src, so switch in to that directory.

Download and unpack DAHDI

Switch in to the newly created source directory, compile, and install DAHDI.

If you have DAHDI hardware you should see the type of card in the make config output

Switch back to /usr/local/src to continue building other packages

LIBPRI

Asterisk

OK, finally we can get to building Asterisk. Let’s find the latest certified Asterisk 13 on this page:
http://www.asterisk.org/downloads/asterisk/all-asterisk-versions

At the time of writing it looks like that is 13.1-cert1, so that’s what we’ll use in this example (you may need to adjust these instructions accordingly).

Download the gzip compressed Asterisk tarball.

Decompress and unpack the file

Switch in to the newly created source directory

Add mp3 support

Fetch all the prerequisites available in the package repository

I ran into a problem on one computer where the install_prereq script Aborted with a message about conflicts. It looks like aptitude returned “:i386” prefixed on some of the output while searching for installed packages. When then data was later fed in to apt-get it failed.. so I modified it with:
aptitude -F ‘%c %p’ search ^build-essential$ ^libz-dev$ |awk ‘/^p/{print $2}’ |sed ‘s/:i386//g’

On line 74 changed:

to

I think the script also looks for pjproject-devel, and I wonder if that should be libpjproject-dev instead.

If you get conflicts and the script aborts, or if you prefer not installing everything but the kitchen sink you could manually grab the essentials:

If libvpb0 gets installed you may be prompted to type in your country calling code

After installation completes you should see a message indicating success.

There may be additional source code to grab that wasn’t retrieved from the Ubuntu repository. This will potentially install Network Broadcast Sound, libresample, jansson, libsrtp, and pjproject

Now that the prerequisites should be well covered, let’s configure Asterisk.
Run the configure script

If everything works out, you should get the ASCII art Asterisk logo

Ensure the the modules you want are enabled.

You might want to see if there are any neat things you want. format_mp3 for example, or EXTRA-SOUNDS-EN-GSM might be desirable.

Channel Drivers -> chan_sip
Add-ons -> format_mp3
Extra Sounds Packages -> EXTRA-SOUNDS-EN-GSM

N.B.
Recently the Asterisk project started using PJSIP as a replacement for the older chan_sip. If you want or need the classic Asterisk SIP module you’ll have to manually select it.

To use the deprecated chan_sip, unselect the the PJSIP channel driver.

Next, select the chan_sip driver.

When you are done making any changes “Save & Exit” out of menuconfig.

Now it is time to build Asterisk

You should get a message that the build completed successfully.

So let’s copy the newly built files into the right places on the system

If everything went to plan, you should see a message that the install completed successfully.

Copy the init startup scripts to make asterisk start on boot

And you’re done.