Archive

Posts Tagged ‘tutorial’

Getting Started with B&T RTL-00 RTL8710 Module – Serial Console, AT Commands, and ESP8266 Pin-to-Pin Compatibility

August 18th, 2016 13 comments

The announcement of the ultra-low cost ARM based Realtek RTL8710 WiFi modules for IoT applications generated quite a lot of buzz since they can potentially compete with the popular ESP8266 modules. The main problem at the time was documentation and software support, but after some searches we could find that RTL8710 was part of Realtek Ameba family, and found some documents and an SDK for RTL8710/RTL8711/RTL8195. ICStation also kindly provided one B&T RTL-00 module for review, which costs $3.55 shipped per unit, and as low as $2.85 if you purchase 10 or more.

Click to Enlarge

Click to Enlarge

Click to Enlarge

Click to Enlarge

The question here is how to get started? The answer can be found in page 8 of the Chinese datasheet for the module with GB0 and GB1 pins used for Tx and Rx to access the serial console. Time for some soldering…

RTL8710_Soldering

For the first test, we’ll just need Tx (GB1), Rx (GB0), GND and 3.3V, and cut breadboard wires to give me the flexibility to use it with a breadboard just in case.

RTL8710_Serial_Connection

Now you need to connect the module to a USB to TTL debug board with all four pins connected since it will also provide power.

Click to Enlarge

Click to Enlarge

Insert the debug board into a USB port of your computer, and setup a serial connection @ 38400 8N1 using minicom, screen, putty, or other serial capable app. I struggled to get the full boot, until I found ATSR command would reboot the board:

If you type help you’ll see some AT commands:

You can find the full AT command set in RTL8710 forums, and somehow it differs from the AT command set found in AN0025 Realtek at command.pdf application note available in Ameba Standard SDK.

Time to have some fun by trying to connect the board to my WiFi router:

Success, and that was easy. Now AP mode….

ATPA needs four arguments with ESSID,password (8 to 64 characters), channel, and hidden or not (1 or 0). I could not find the new access point with my phone, connected to it and typed the password. The serial console outputted it.

The command ATW? will return lots of info about WiFi status:

I’ll complete those little tests by enabling the web server in the board:

You can now connect to the web interface to configure the access point.

Click to Enlarge

Click to Enlarge

AT commands are all good, and you can configure WiFi, UDP/TCP servers, and even OTA firmware update, but there’s nothing about controlling GPIOs there… So that will be something to look into. [Update: ATSG is the command for GPIOs. See comment]

Dpape on RTL8710 forums discovered something very interesting: B&T RTL-00 module is pin-to-pin compatible with ESP12E module based on ESP8266, so if you already own a board with such module including NodeMCU board, you could unsolder the ESP8266 module, and replace it with RTL8710 and get going.

NodeMCU_RTL8710That’s exactly what he’s done and shown to work, with the module bought from Aliexpress, which appears to come pre-loaded with the exact same firmware. You’d normally not need the red USB debug board as shown above, but he removed the USB to TTL chip on NodeMCU previously, so that’s why…

ESP12E_vs_RTL00

The modules are actually only mostly pin-to-pin compatible, as for example GC5, corresponding to ADC on ESP12E, does not seem to support ADC, but only I2C1 SCL, SPI0 CS2, and GPIO_INT signals. But the power signals, Tx and TX, and most GPIO signal will match.

Realtek RTL8710 is still nowhere near ESP8266 in terms of community and software support however. However an ARM development board company – previously featured in this blog and many news outlets – is involved in the project, and I’ve been informed more details will be provided in 2 to 3 weeks. The current modules sold are for the Chinese market, and an international version is planned with a slightly different radio.

How-to Setup a DLNA/UPnP Server in Linux for Smoother Video Streaming with Kodi and Other Media Players

August 16th, 2016 8 comments

I’m normally playing videos from a SAMBA share installed in a Ubuntu PC to play files from Kodi in Android TV box reviews, but sometimes when I use 10/100 Ethernet, or worse WiFi local “streaming” may not be as smooth as possible. SAMBA is convenient because of access control and read write operations, but if you want to get a bit more performance, you may switch to NFS instead, or like I’ve going to show you here to a DLNA / UPnP server to stream videos locally from Kodi 16.1.

There are several options, but MiniDLNA is lightweight compared to MediaTomb, so it will also run on lower end hardware like cheap ARM Linux development boards like Raspberry Pi, Orange Pi, or NanoPi NEO without taking too many resources.

Installation is very easy in Debian / Ubuntu distributions, and I supposed this should also work with Windows Subsystem for Linux in Windows 10:

MiniDLNA can be configured with the same settings for all users, or different settings for specific users. In both case you’ll need to edit /etc/minidlna.conf configuration file. In my case, I only changed or uncommented the following lines for global settings:

You can add as many media_dir lines as you want, and also add A, V or P letter to separate Audio, Video, and Photo media type. For example:

Please note that minidlna daemon (minidlnad) will automatically scan subdirectories, so they don’t need to be specified.

Now that we have modifed the configuration, let’s restart it:

The Wiki on Ubuntu linked in the introduction also mentions to run the following command to rebuild the database:

However, while I could find my new UPnP server in Kodi, there were no files at all, and the log shows the same error message over and over:

eventually the command:

fixed the issue. But that’s not exactly the right way to fix it as it assumes root is running the daemon.

A better way if you’re going to have a decidated server is probably to set the ownership of media files to minidlna with a command like:

So how do you play videos from your DLNA/UPnP server in Kodi 16.1? Go to Videos->Files, and select Add videos…

Kodi_UPnP_devicesNow select UPnP devices

Kodi_miniDLNA_serverKodi should like your UPnP / DLNA servers. In my case FX8350:root, which correspond to the hostname or friendly_name in the hostname, and to the user, normally minidlna. Select the server, than Browser Folder, or Videos, and click OK.

I’ve shot a short video showing how to setup UPnP devices in Kodi, and compare SAMBA and DLNA performance by playing the same video file in Kodi 16.1 Android through SAMBA and UPnP/DLNA.

You’ll notice the video played from the SAMBA server starts much faster, but buffers several time during playback, while the video played from MiniDLNA server on the same PC will buffer data longer at start, and always fill the buffer fast enough to avoid bufferring.

I took Conky screenshots for another video showing the traffic shape for both SAMBA with relatively constant speed (6600 KB/s to 7400 KB/s) and DLNA which shows very high bitrate (>10000 KB/s) to fill the buffer the first time, and then play consistently around 6400 to 6800 KB/s.

SAMBA_vs_DLNA-UPNP

Of course switching from SAMBA to DLNA won’t do miracles, but if you notice a few buffering while playing videos in SAMBA, switching to DLNA/UPnP may resolve the issue. You can also keep the best of both world, for example using SAMBA to download/copy files, and DLNA to play them back.

How to Resolve Slow Boot Times in Ubuntu 16.04

August 9th, 2016 9 comments

I’ve recently upgraded my machine from Ubuntu 14.04.4 to Ubuntu 16.04.1, but while my computer used to boot in about 40 seconds, after the upgrade boot times increased considerably to 2 to 3 minutes.
Ubuntu_16.04_Boot_timesThe first easy check was to look at dmesg:

There’s a bit 87 seconds gap between checking for the floppy, and VirtualBox drivers loading. So there’s definitely an issue here, but the log does not exactly give a clear queue.

I’ve read you could use systemd-analyze to find which process(es) may be slowing down your computer at boot time:

Two processes are taking close to 8 seconds, but those 16 seconds still do not explain why it takes 2 minutes more to boot…Eventually, I realized systemd-analyze has a few more tricks up its sleeves:

The first command shows there’s no problem with the kernel itself, and something is slow in user space. The second command draws a huge boot chart (SVG), whose shape looks like the picture below.

ubuntu_16.04_BootchartSo we have something to look at, namely the area just before the large gap… I’ve zoomed in on it:

Ubuntu_16.04_Bootchart_ProlificThere are a few things there including the DVDROM drive, and “Prolific Technology Serial Controller” connected to /dev/ttyUSB0. The latter is a USB to TTL debug board based on PL2303, so I removed it and rebooted my machine, and miracle! Boot time was reduced to just 17 seconds:

Ubuntu_16.04_Fast_Boot_TimeThe SVG chart shape, shown on the right, also changed completely as it booted most of the same services in much less time. So since I don’t use the debug board everyday, I’ll make sure I only connect it when needed.  Ideally, I suppose a bug should be filled, but I’m not sure which package cause the issue.

On a rather unrelated note, yesterday I also decided to look into Firefox performance issues (switching or closing tabs would take 2 to 3 seconds), and I discovered recent versions of Firefox browser (47+ and greater) include support for “about:performance” tab showing which add-on(s), plugin(s), or page(s) may be problematic. Just let it run for a while, and go about your business browsing the web, and then come back to the tab to check if any has many alerts. It helped me find an add-on slowing down browsing considerably, so I disabled it, and performance is now much better.

How to Customize Amlogic Android Firmware – A Tutorial with NEXBOX A95X (S905) TV Box

August 6th, 2016 61 comments

CNXSoft: Bear in mind that there are multiple versions of Nexbox A95X. Yesterday, I published the review of Nexbox A95X with Android 6.0, with the model based on Amlogic S905X processor. In this article, Karl had a look at Nexbox A95X with Amlogic S905 processor, which he purchased a couple of months ago, but since he was not happy with the Android 5.1 firmware, he decided to customize it.

Karl here with a review of the Nexbox A95X S905 box. This took a while to even start. I received the box about 2 months ago and I dived right in and broke it. I didn’t have factory firmware, and wasn’t cautious enough and bricked it. I found some firmware that worked but it didn’t work very well for me. Email’s to Nexbox directly didn’t help and I was stuck with a bricked box… I later found someone who had factory firmware and was kind enough to share and I was back in business. But I still didn’t like it, as it felt sluggish when doing anything else besides Kodi and missing notifications and navigation bar.

Click to Enlarge

Click to Enlarge

Click to Enlarge

Click to Enlarge

Quest to find better firmware

There is a dirty little secret with these boxes and it is a little unfair to the manufacturers who do make good software but you can just about flash any firmware on any matching processor box. The biggest thing is to match the WiFi chip. They will sometimes brick hard and to restore requires shorting pins on the NAND flash. It is pins 29 and 30 on this one (TBC). Short the pins while connect to PC, and apply power and you are able to flash new firmware. I never had to do it on this one. The A95X has an RTL8189ETV WiFi chip as can be seen in the picture above. So I did some searching for “S905 RTL8189 Firmware” and I found some, but they were not any better. If WiFi doesn’t matter and you have Ethernet you will have better luck or can use a USB to Ethernet adapter if the firmware supports it.

Review Turned into a How To

I wasn’t happy with anything (I know….I am needy). So what do we do? Go and try a manufacturer’s who put out good software regardless of WiFi and Ethernet. I had used Tronsmart’s S905 firmware on another box and it is pretty good. So I started there and flashed it and the box booted but without WiFi, nor Ethernet, and I assume no remote control either (I don’t typically use the remote and test with Logitech K400R). So I tried to use this firmware as ROM to port from, and now the time consuming part starts…

Setup

Before we begin I will put out the typical disclaimer that you assume all risk and don’t blame me. If you don’t want to have to do this buy a box from a good manufacturer. Several stand out… search for reviews in CNX Software, or other forums.

I do all my work in Windows, so no Linux is necessary but just recently upgraded to Windows 10 and with bash opens up some additional possibilities I have yet to explore. I did try mounting an img but it doesn’t support it yet.

Below is the main software that I use. If you know any other alternatives please leave a comment. Especially Beyond Compare only 30 day evaluation. It is not too expensive and I use it for other things. Install all the programs below with defaults and it should work except the Customization Tool. Install it to someplace other than Program Files. It will save button presses when needing elevated privileges.

Customization Tool

I will be going to go over the basics of this tool. When you first load the tool it will be in Chinese. The 2nd menu Item in the top will set it to English, and it will remember it the rest of the time.

Amlogic_Customization_English

The first step is to unpack the img files. Press the load button, and you will be prompted to what you want to unpack. I check them all at this point except the bottom one. There is an issue right now with the tool with the last one. Then choose the img we are porting to. This will take a while. Amlogic_CustomizationTool_Load

Amlogic_Customization_Tool_Settings

Once the img is unpacked navigate to where you installed the customization tool and rename the tmp directory to Tronsmart.

NEXBOX-A95X-Customization

Now repeat the process again with the Nexbox Stock img. Don’t close the Customization Tool until we are done.

Now we have 2 img’s fully unpacked and in each directory we have 2 folders: Level 1 and Level 2. Level 1 has all the individual partitions and we won’t be doing anything in there today. Level 2 has the different partitions broken out so we can manipulate them. We will only have to go into system to do this port.

NEXBOX-A95X_System

Now in the Nexbox firmware,  delete app, fonts, framework, media, priv-app in the system directory, and copy them over from Tronsmart.

At this point go back to the Customization Tool Press the Pack button and save it somewhere. If I was doing this the first time I would flash and do some testing to see if it booted, Wifi, remote etc. This also gets you to a good spot to go back to so in case something goes bad you don’t have to do the whole thing over again. As you are exploring it is good to do this often to save some headache and time.

Beware once you pack an img, as you must close the customization tool down and unpack the last one you packed. There is a bug if you pack make a change test then pack again without restarting and reopening. All the img’s after that first pack won’t be able to be unpacked by the tool.

Final Tweaks

Here is our chance to remove all the bloat and clean the img up. When I clean an img I take a picture of the app drawer with my phone and remove any unwanted apps from the app directory or priv-app directory. Be aware there is also a pre-install directory that won’t install anything. I removed everything to tidy up. I did try to fix quickly but didn’t spend much time on it.

I also replaced the Tronsmart boot animation with a different one. It is in the media directory.

Extra’s

You can also modify boot img and logos with this tool. I use gimp to modify logos. First I would navigate to the logo folder in the level 2 directory. The largest file bootup is a bmp file. Rename to bootup.bmp, right click on it go to properties and note the dimensions and bit depth. In this case it is a 32bit 1280×720 bmp img. Find whatever picture or logo…your imagination is the limit but you have to make sure your dimension and bit depth are exact. In gimp you export to bmp and choose 32 bit…if done correctly your file will be the exact same size as the original. Rename bootup and delete the original. When done you can pack and enjoy your new logo. I believe the tool itself will import but I like to do it by hand. The only thing I use the tool for is to unpack and pack the img.

Troubleshooting

So we haven’t touched a couple tools so far. That is a good thing. But if we did run into some trouble Beyond compare can drastically reduce the time to find. With this tool you can compare all the files from the stock rom, and the rom you are porting to. If I ran into troubles with booting start with comparing kernel in level 2. Maybe in one of the rc files a reference something differently. This can lead to many hours lost. I have lost many and not succeeded. Be prepared to do lots of reading and research. I included HXD and Notepad++ if you had to modify a file. In the Windows notepad it doesn’t recognize Linux carriage returns.

If you’d just like to install the custom image on your NEXBOX A95X (Amlogic S905 only) TV box, here’s the custom firmware link.

Embedded Android (Marshmallow) and Brillo / Weave Internals Presentation Slides

August 3rd, 2016 1 comment

Karim Yaghmour – founder of Opersys, a company specializing in Embedded Linux and Android training and development – is currently at Android Devcon 2016 were he gave a full day Embedded Android Workshop on August 1st, as well as a separate 1+ hour talk about Brillo/Weave internals on August 2, and more talks scheduled on the next two days about Android memory management, debugging and development, and Project Ara.

He has just released the presentation slides on Slideshare, with the first “Embedded Android Workshop with Marshmallow” presentation totaling 175 pages, and dealing with Linux and Android concepts, overall architecture, system startup, the Linux kernel, hardware support, native user-space, Java for Android, JMI, AOSP, and more…

The second presentation is much shorter with 29 slides, and deals specifically with Brillo / Weave internals including Embedded Linux, Android, Binder, DBUS, HAL, the source tree architecture, and so on.

While you’d probably learn a lot more by attending the live workshop and session, you may still earn a few things about Embedded Android and Brillo by scrolling through the slides.

Categories: Android, Brillo Tags: Android, brillo, opersys, tutorial

How to Set an Android TV Box Video Output to Portrait Mode

August 2nd, 2016 4 comments

Most buyers who buy an Android TV box just want to use it to watch videos, browse the web, play games, and so on, so landscape mode seems to be the best choice, and orientation option in the firmware is often disabled. However, TV boxes can also potentially be used as digital signage players, which may require landscape or portrait modes if the screen is positioned vertically. Since I’ve just been asked that question, I’ve checked for a solution, and luckily there’s an app called Set Orientation that does the job.

Click for Original Size

Click for Original Size

When you first start the app, it will show the option “Disabled”, but you can click on the arrow to reveal more options, and select Portrait to rotate the screen.

Click for Original Size

Click for Original Size

In case the screen is upside down, simply select Portrait (reverse) option, click OK, and you’re done! Easy.

Getting Started with NanoPi NEO Development Board – Ubuntu Core Firmware

July 20th, 2016 36 comments

NanoPi NEO is an exciting ARM Linux board due to the power it packs into its small size, and its low price starting at $7.99. It’s made by FriendlyARM, and since I’ve read some people had never heard about the company before, I’d like to point out it has been providing development boards well before the Raspberry Pi board was launched, with products such mini2440 based on a Samsung ARM9 processor introduced around year 2010. Anyway, I asked the company if they were willing to send 2 samples for review, as I plan to remove the USB & Ethernet port on one of them. Instead I got a 4 boards and accessories, so I’m going to start reviewing the board by writing a quick start guide, showing how to setup it, and check out the Ubuntu core provided by the company. If you are a fan of armbian made Debian distribution, NanoPi NEO will soon be supported too.

NanoPi NEO Pictures

So company send the parcel by DHL, and for some reasons declared an $11 value for 6 boards in the invoice, despite the board selling for respectively $7.99 and $9.99, and the two PSU-ONECOM debug boards going for $4 each… This resulted in higher custom duties than expected…

Click to Enlarge

Click to Enlarge

I opened all packages, with the board stored in anti-static bags as they should.

Click to Enlarge

Click to Enlarge

The complete package content include two NanoPi NEO 512MB RAM, two NanoPi NEO with 256MB RAM, two PSU-ONECOM debug board (which I don’t recommend, more details below), two 5V/2A power adapter and corresponding USB cables, as well as two blank 8GB micro SD cards. Each NEO board package also features a piece of paper with the specifications, and a getting started guide partially written for NanoPi-T3 (no you can’t use HDMI with NanoPi NEO), but still two useful links pointing the NEO Wiki, and Friendlyarm github account.

Click to Enlarge

Click to Enlarge

The top of the board features Ethernet, USB host, and micro USB (power) ports, as well as the micro SD slot, and I/O headers, while we’ll find the only two main ICs on the back with Allwinner H3 quad core Cortex A7 processor, and a Samsung RAM chip.

In case you wonder how to differentiate between the 512MB and 256MB version in case you buy both model, there’s a 512M RAM sticker on the former, and no sticker on the latter.

NanoPi_NEO_512MB_vs_256MB

If for some reasons, the sticker is detached, or remove, just check the back of the board for the Samsung memory part number: 2G (2 Gbit) = 256 MB, and 4G (4Gbit) = 512MB. Easy enough.

Samsung_Memory_256MB_vs_512MBNanoPi NEO can be considered a competitor of several other small ARM or MIPS Linux boards including Raspberry Pi Zero, Orange Pi One, Next Thing CHIP, and Mediatek LinkIt 7688, so I’ve taken a “family pictures” to show the respective size of the boards, and NanoPi NEO is clearly one of the smallest, and more powerful than most other board save for Orange Pi One.

Click to Enlarge

Click to Enlarge

However, it’s also much thicker than most because of its RJ45 jack, and vertical USB port.

NanoPi_NEO_Ethernet_USBI had planned to shoot a video showing how to remove the Ethernet and USB port (and possibly serial header), but I’ll probably skip it, because the company has now decided to also sell NanoPi NEO 512MB without Ethernet nor USB for $9.98 + shipping.

Getting Started with Ubuntu Core image for NanoPi NEO

So now, that we’ve checked out the hardware, it’s time to play with the board. Eventually, armbian will release an image, and it may become the preferred option, because of community support, but in the meantime, I’ll use the “Ubuntu Core + Qt Embedded” image released by the company. The instructions below are to be follow in a terminal windows in Debian, Ubuntu, or Mint operating system, but if you use Windows 10 you can flash the image with Win32DiskImager just like with a Raspberry Pi, or install Windows Subsystem for Linux, and follow the exact same procedure as in Linux.

First, you’ll need to download the image (currently nanopi-neo-core-qte-sd4g-20160704.img.zip) through mediafire, and uncompress it:

Now insert a micro SD card into your computer, and check the device name (/dev/sdX, or /dev/mmcblkpX) with lsblk command:

That step is very important. In my case, my 8GB SD card (the 3.7GB image should also work on 4GB micro SD cards) is /dev/sdb, so that’s what I’ll use. If I used /dev/sda instead, the instructions would completely wipe out my hard drive, and I’d lose all my data and OS. Anyway, let’s go ahead, and umount the SD card, and flash the image, checking the progress with pv:

The third step should take a few minutes to complete. Now we can take the micro SD card out, and insert it into the board, connect an Ethernet cable and the power, and after a few seconds (about 5 to 10 seconds). you should be able to ssh to the board with its IP address, which you can get from your router DHCP list.:

All good that was easy, and the board works out of the box. What’s not so nice is that the image is based on Ubuntu 15.10, an unsupported version of Ubuntu at this time.

Another way to connect to the board, especially if you don’t plan to use Ethernet is through the serial console. I’ve first done so using the company’s PSU-ONECOM debug board, plus a NULL modem cable, and an RS232 to USB adapter, since my computer does not have a DB9 connector.

NanoPi_NEO_RS232_Board

That’s fun, and it works, but that’s what I’d consider the old way of doing things simply because most recent computers or laptop don’t have a COM port. So instead, I’d recommend to use a standard USB to TTL, which normally cost $1 shipped, to connect to your computer, as it’s just more convenient to most people.NanoPi_NEO_USB_to_TTL_BoardSimply connect GND, Rx, and Tx to GND, Tx and Rx pins on the serial header of the board as shown below.NanoPi_NEO_Serial_Header

That’s the board output in minicom connected to /dev/ttyUSB0 with 115200 8N1 settings. In Windows, you may want to use Putty.

Let’s type some other command to find out more:

So the image is using a Linux 3.4.39 legacy kernel (mainline support should be a few weeks or months away), the rootfs size is 3.6GB with 3.0GB free (You’ll want to resize it with parted + resize2fs), and the quad core Cortex A7 processor has a maximum frequency of 1.2 GHz, instead of 1.29 GHz for boards with a different voltage regulation, but that’s OK, as the board has been mostly designed for IoT applications, and not necessarily for maximum performance. The GPIO module is compiled, but an error is generated after I load it, and now GPIOs are exported, which differs from my experience with the images I used with Orange Pi Allwinner H3 boards, where GPIOs are listed and ready to use.

Power consumption on this type of board is a topic that will require a separate post, but since I’ve been asked I’ve taken some quick measurements using a “kill-a-watt” power meter, and power consumption at idle is around 2.0 watts. Since the platform should also support standby/sleep mode, I tried it with pm-suspend:

Power consumption only dropped to 1.4 watts, and I was not able to resume by connecting a USB keyboard. So either the method I used is not correct, and suspend is not fully supported in the kernel. I’ll have to study a bit more, but obviously tips or links that could help me are welcome in comments.

Finally, I also checked whether it would be feasible to install an heatsink for people who may want to push the board to its limits.

NanoPi_NEO_HeatsinkThe Ethernet jack pins prevents to simply put some thermal paste on the processor and RAM, so you’d have to add some thermal pads on both ICs before fitting a heatsink, unless you use a smaller heatsink that does not cover the area under the RJ45 connector. There’s also no obvious way to keep the heatsink in place.

If you are interested in the board, it sells for $7.99 with 256MB RAM, and $9.98/$9.99 with 512MB RAM without/with Ethernet and USB host ports, plus shipping which normally amounts to $4 to $5 by airmail.

Setting a VoIP SIP user agent with Embedded Linux

July 19th, 2016 6 comments

This is a guest post by Leonardo Graboski Veiga, working for Toradex.

Introduction

This article’s main goals are: to cross-compile the PJSIP libraries and the PJSUA API reference implementation; deploy it to the target system; give an overview about the SIP protocol; and explore the reference implementation features, regarding audio only. For this purpose, a Computer on Module (CoM) from Toradex was chosen in the following configuration: Colibri iMX6DL* + Colibri Evaluation Board. The evaluation board and CoM are displayed in Figures 1 and 2, respectively.

Figure 1 -

Figure 1 – Colibri Evaluation Board

 

Figure 2 -

Figure 2 – Colibri iMX6DL

VOIP or Voice over IP, is a term designed to refer to a set of methods and technologies targeted for the implementation of telephony services over the Internet. For the purpose of this article, the scope will be limited to the use of a reference implementation built upon the SIP communication handling protocol by means of the PJSIP libraries and PJSUA2 API. If you wish to gather more information about VOIP itself, there is a website that labels itself “A reference guide to all things VOIP” and it holds comprehensive information on the matter.

SIP is the Session Initiation Protocol – a protocol used for signaling and handling communication sessions. This protocol is sometimes referred to as the de facto standard for VOIP implementations. It is an IETF (Internet Engineering Task Force) standard even though there are other options to SIP, such as IAX2. SIP employs the RTP protocol for data transmission which itself is encapsulated in TCP or UDP and can be encrypted by using TLS.

PJSIP is a set of libraries that implements the SIP and related protocols such as RTP and STUN, among others in C language. Some of its advantages are that it is free, open source, and highly portable. It was started in 2005 and is still being maintained and improved with wide documentation and the advantage of having a high level API named PJSUA2 for easily building custom applications. The PJSUA2 even has an online book for its official documentation.

Cross-compilation

The first step to cross-compile the PJSIP libraries and the test/sample application is to have the toolchain set. To do it, we can follow the toolchain for hard float calling convention section of this article. Note that if you are willing to use your own cross-compilation toolchain, according to this PJSIP documentation, you are required to have the following GNU tools: GNU make (other make will not work), GNU binutils, and GNU gcc for the target.

If the basic rootfs provided by Linaro doesn’t have some ALSA headers and the library needed to compile PJSIP, we will download and compile these libraries from the ALSA project website. In this article, the alsa-lib version downloaded was 1.1.1. then we will install the headers and library to the Linaro rootfs.

Install the toolchain Linaro:

Export the environment variables:

Download and unpack the ALSA lib:

Before compiling the ALSA lib source codes, it is necessary to run the autoconf script with the CFLAGS, LDFLAGS and prefix variables pointing to the rootfs from the Linaro toolchain:

Then just build and install. After the make command, the compilation will fail at some point; but it doesn’t matter because the headers and library we need will have been compiled.

Having the toolchain configured, it is time to download and extract the PJSIP source codes to the host machine and then go into the directory that holds the unpacked content. At the time this article was written, PJSIP version was 2.5.1.

Before compiling the PJSIP source codes, it is necessary to run the autoconf script pointing to the previously modified rootfs from the Linaro toolchain. It is almost the same way we did to compile the ALSA libraries, except for the fact that the directory where we want the compiled libraries to be installed is a directory we will compress and deploy to the target machine.

Then we are able to compile the libraries and also copy the reference implementation executable to the installation folder:

The next steps are to compress the folder and copy it to the Colibri iMX6. To discover the iMX6 IP, you can issue the ifconfig command:

Finally, log into the Colibri iMX6:

Now, we have the PJSIP deployed to the target – although it isn’t necessary for our next steps, since we will be using a binary only, you may find it useful somehow while developing applications of your own. We are also ready to start using the reference implementation, but first, let’s check some other things.

Audio check and configuration

The PJSIP library uses ALSA (Advanced Linux Sound Architecture) resources, which is also the audio subsystem used by the Toradex embedded system BSPs. Before starting, make sure you plug a headphone/speakers and a microphone into the carrier board with the system powered-off, as illustrated in the Figure 3.

Figure 3 -

Figure 3 – Connecting the mic/headphones/speakers to the Evaluation Board

Then you can use the alsamixer application to adjust the audio options according to your system.

The configuration used is illustrated in the Figure 4 and you should notice that adjusting the microphone’s amplification too loud can cause distortion, thus, it is good to experiment with the settings. Even adjusting the mic option to zero won’t mute your microphone; it just means there will be no amplification, or in other words 0dB gain. Another important point to notice is that if you force power-off the system, the configurations you made might be lost, therefore reboot or shutdown from the command line the first time you make your changes.

Figure 4 -

Figure 4 – Alsamixer configuration (Click to Enlarge)

To test the audio input (microphone) and, subsequently the output (headphones/speakers), we will record some audio by using the arecord command and then play it by using the aplay command. Notice that for the arecord there are some options that we need to set: -V displays a VU meter so you have visual feedback whether your mic configuration is good or not; mono is passed since microphone is mono; -r is the sampling rate; -f is the format and -d is the duration in seconds. For more information regarding arecord, you can use the –help option, or if you want to know more about audio on the Colibri iMX6, you can go to the Toradex developer related page.

If you can hear yourself well, we are ready to go ahead. Otherwise, check the connectors and the audio configuration.

SIP protocol overview

SIP is the session initiation protocol standardized by the IETF and used for VOIP and other types of multimedia sessions, such as messaging and video. It is text-based and uses the UTF-8 encoding, usually choosing UDP or TCP over port 5060 as a transport protocol. The information provided here about this protocol is mostly based on information provided here.

The protocol has methods defined in its RFC and method extensions defined in other RFCs. A few of them are:

  • ACK: used in some situations for handshake
  • BYE: session hang up
  • CANCEL: cancel an invite
  • INVITE: add another user agent to a session
  • SUBSCRIBE: request information about the status of a session
  • NOTIFY: sent from time to time by the gateway, must be answered with 200 OK
  • MESSAGE: used to allow and transport instant messages

There are also response codes, each with a specific meaning, that consist of 3 digit values:

  • 1xx: provisional – request received and still needs to process e.g. 100 trying, 180 ringing
  • 2xx: success – action successfully received and accepted e.g. 200 ok
  • 3xx: redirection – there is still some action needed to complete the request e.g. 300 multiple choices; 305 use proxy
  • 4xx: client error – server cannot process request or the client sent invalid e.g. 400 bad request; 404 not found
  • 5xx: server error – server cannot process a valid request e.g. 500 server internal error
  • 6xx: global failure – no server can fulfill the request e.g. 600 busy everywhere; 603 decline

It is important to notice that the SIP protocol doesn’t carry the audio information. Instead, it uses the RTP protocol encoded usually in UDP or TCP transport. For a better understanding, the Figure 5 explains how the transaction between two user agents is done for a simple call.

Figure 5: Example of a simple SIP call between user agents

Figure 5: Example of a simple SIP call between user agents

To make calls, a SIP URI is needed. It is a form of identifying a communication resource. A complete SIP URI has the format sip:user:[email protected]:port;uri-parameters?headers, but there are systems which can operate even with a SIP URI that provides only the host.

PJSUA reference implementation

The PJSUA API reference implementation is a command-line based application which uses the PJSIP, PJMEDIA, and PJNATH libraries and implements a user agent, also known as softphone. Its source-code can be found here and is a useful starting point to developing your own solution. The full documentation regarding the use of the PJSUA application can be found here.

Before starting to test, find the IP address for both your embedded system and your PC/notebook. You must have both of them in the same LAN, because we are not worried about using a proxy server or anything like that, therefore our connection between devices will be made point-to-point.

In this article, we will assume IP address 192.168.10.5 for the Colibri iMX6 and 192.168.10.1 for the PC. You also must have softphone software installed in your PC – it can even be the same reference application, if you want to compile it for your machine – this article will use the Linphone open-source softphone for Ubuntu 14.04 LTS. To start PJSUA in the embedded system use the following command. The PJSUA command line interface that you are expected to see is described in the Figure 6.

Figure 6: PJSUA command-line interface (Click to Enlarge)

Figure 6: PJSUA command-line interface (Click to Enlarge)

To make a new call from the embedded system to the PC, type “m” and then enter the simplest SIP URI possible which consists of passing only the softphone IP in the format sip:192.168.10.1. The process of making the call is illustrated in the Figure 7 and the answered call in the PC is illustrated in the Figure 8. To hang up, use the command “h”.

Figure 7: Making a call from PJSUA

Figure 7: Making a call from PJSUA

Figure 8: Linphone positive answer – in progress

Figure 8: Linphone positive answer – in progress

In order to send instant messages, type “i”, the SIP URI of the destination and the message, almost like the way we did to start a call. In your PC softphone, you should see the message. Try to send some message to the iMX6 by using the GUI. The Figure 9 displays the Linphone messaging interface with some messages exchanged between devices, while Figure 10 illustrates a message received by the Colibri iMX6 embedded system.

Figure 9: Message exchange between the Colibri iMX6 and the PC/notebook

Figure 9: Message exchange between the Colibri iMX6 and the PC/notebook

Figure 10: Message received by the Colibri iMX6 embedded system

Figure 10: Message received by the Colibri iMX6 embedded system

Additional configuration

In this subsection, some of the options for the PJSUA command-line application will be presented. They can be found here. Firstly, create a file named .pjsua-conf in the embedded system with the following contents:

The stereo configuration lets the audio output to be played on both the headphone’s speakers, while omitting it just makes the application to output the sound to only one of them. The auto-answer option lets you configure an answer code for incoming calls – in this case, the answer is 200, which means the call is accepted – and this can be useful in situations where the embedded system endpoint doesn’t has a human interface. Duration sets a maximum call duration in seconds, and this may be useful in applications such as debugging purposes. Color makes some log messages such as warnings and errors be colored, which helps identifying specific situations. Lastly, the add-buddy option lets you add SIP URIs so that you don’t have to add them manually every time you restart the application neither do you have to type the URI every time you want to make a call to the corresponding buddy (you may specify this option more than once for multiple buddies).

Passing the configuration file to the application:

Among the various options available, there are two that are nice for testing purposes: rx-drop-pct=PCT and tx-drop-pct=PCT. They both simulate packet loss by adjusting its percentage (PCT). It was tested with a package loss for both Rx and Tx of 10%, 20% and 30%, respectively, while monitoring the call quality average displayed by Linphone, which ranges from 0 to 5. The quality went from almost 5.0 without loss to 3.3, 2.3, and 0.6, respectively. Figure 11 shows the Linphone screen capture for the last situation (30% loss).

Figure 11: Quality for Rx and Tx packet loss of 30%

Figure 11: Quality for Rx and Tx packet loss of 30%

There you go! Now you have a VOIP implementation for the Colibri iMX6 running and a starting point to develop your own application according to your needs. Some additional information will be presented in the next chapter: network monitoring in order to see the SIP packets and some transactions being made.

Network monitoring for SIP packets

In order to see the SIP transactions being made between devices, the Wireshark software will be employed. You must notice that there is a third IP address 192.168.0.20 in the transactions and that is because the notebook was used as a DHCP server for the iMX6. Therefore, the notebook has two IP addresses. Still, no further investigation on why or how the SIP application is accessing the second IP address.

The sequence of operations made while capturing the network is described below:

  1. Call from Colibri iMX6 and reject from the notebook
  2. Call from Colibri iMX6 and accept from the notebook
  3. Colibri iMX6 hang up
  4. Call from the notebook and accept from Colibri iMX6
  5. Colibri iMX6 puts on hold
  6. Colibri iMX6 resumes the call
  7. Colibri iMX6 sends UPDATE
  8. Colibri iMX6 sends instant message
  9. Notebook sends instant message
  10. SUBSCRIBE/NOTIFY

The Figure 12 displays only the SIP protocol packets exchanged during the capture, with the highlighted lines corresponding to the start of the situations described above. Hence, 10 lines are highlighted. Notice that there is a SUBSCRIBE/NOTIFY handshake a moment before the third operation listed above.

Figure 12 - Network monitoring for SIP protocol packets only (click to enlarge)

Figure 12 – Network monitoring for SIP protocol packets only (Click to enlarge)

In the Figure 13, there is a capture of a very brief conversation (~4s) SIP and RTP packets. Notice that while the notebook uses the IP address 192.168.10.1 to send data to the embedded system, this one replies to the IP address 192.168.0.20.

Figure 13: Network monitoring for SIP and RTP packets for a brief call (Click to Enlarge)

Figure 13: Network monitoring for SIP and RTP packets for a brief call (Click to Enlarge)

With the information gathered, this is a way to confirm in practice some of the information presented in the previous chapter SIP protocol overview.

This is the end of the article that goes through implementing the PJSUA console-based application on a Toradex Colibri iMX6 and Evaluation Board running embedded Linux. Thank you for reading and I hope it was a useful article!

* for T20 based modules, mfpu=neon could generate incompatible binaries.