Posts Tagged ‘Linux’

FriendlyARM NanoPi NEO Board Benchmarks

July 22nd, 2016 1 comment

We’ve already seen how to setup NanoPi NEO with Ubuntu Core, and while it’s mostly designed as an IoT node, for example to control relays over Ethernet or the Internet, I’ve still decided to see how it would perform under load by running Phoronix benchmarks, and then network and storage (micro SD card provided by FriendlyARM). It’s a small board, so we should expect it to heat a lot under load, especially it does not come with an heatsink by default. Also bear in mind that performance may dramatically change depending on the software implementation, and for the test, I’m using the company’s Ubuntu Core firmware.

Before start the benchmark, I noticed that QTe-Demo was running in the background, probably because it was used on their other board with video output or LCD. but it’s taking some CPU usage, and is absolutely not needed here.

To disable it, edit /etc/rc.local, and comment out one line as follows:

I also planned to install RPi-Monitor, which is very easy to install in armbian, but I could not find a quick way for the Ubuntu core image, so I skipped it for now, instead manually checking the temperature.

Let’s install Phoronix Test Suite:

and run the benchmark against Orange Pi, Banana Pi, Raspberry Pi, etc… boards results.

Since it will take a while (4 to 5 hours) checking the terminal output while the benchmark is running may be informative:

Phoronix will run the same test several times, and in theory, every iteration of the test should have roughly the same results, but in practice, modern processors do overheat, and either reduce frequency or cut the number of cores to keep the temperature below the (safe) junction temperature. The results here don’t look good, because they become slower overtime. A temperature check with an IR thermometer after one hour or so, shows the CPU is getting really hot.
NanoPi_NEO_CPU_TemperatureWe can also verify this in the command line by reading one of the temperature sensor:

It’s hot, and the temperature tops at 80 C, and sometimes drops down to 76 C, before getting back to 80C, so the system is clearly throlling and the final results made that clear (ARMv7 rev 5 is NanoPi NEO without heatsink). Please also note that all 6 boards included below are using the same governor settings (interactive or ondemand). However, NaniPi NEO’s Ubuntu core Linux kernel is configured to run the RAM at the lower frequency to either decrease power consumption or heat generation.

Click to Enlarge

Click to Enlarge

John the Ripper is a multi-threaded password cracker, and in theory NaniPi NEO should have about the same performance as Orange Pi One, but there’s clearly a massive drop in performance.

Click to Enlarge

Click to Enlarge

Same thing for single threaded FLAC audio encoding, where NanoPi NEO is almost 50% slower than Orange Pi One, and about the same as Raspberry Pi 2.

So let’s check what happens is we had an heatsink. I glued the largish heatsink (for that board) by putting thermal paste on Allwinner H3 and the Samsung DDR3 SDRAM chip. It is not centered on the board because the Ethernet jack pins prevent this. You could add some thermal pads to work around this.


So let’s start again phoronix-test-suite to see if this improves anything:

Terminal output for the first benchmark:

We can see the results are both higher, and more stable, so that’s a good sign.

The heatsink temperature is about 54 C after around one or two hours.

NanoPi_NEO_Heatsink_TemperatureBut the CPU temperature is still high, and topping at 80 C from time to time:

Nevertheless the final results are way better. I repeated the test with heatsink twice to some issue with uploading the results the first time…

Click to Enlarge

Click to Enlarge

FLAC audio encoding is now just as good as on Orange Pi One.

Click to Enlarge

Click to Enlarge

John the Ripper is still a bit lower on NanoPi NEO, which could either be because of RAM clock or overheating despite the heatsink. The multi-threaded performance is still better than on Raspberry Pi 2 however.

So if you want to want NanoPi NEO to control some relays, you probably don’t need to care at all about this, but if you plan to use it as part as a cluster or build farm, you’d have to consider using a heatsink and possibly a fan to get optimal performance, as well as make sure the board does not die prematurely…

Let’s switch to Ethernet performance, but running iperf server on the board:

and running iperf client on a computer running Ubuntu 14.04 to test dual duplex performance:

So the download speed is all good at 93.8 Mbps, but the upload speed is not quite up to the task at 25.8 Mbps. Remember that a dual duplex test is a worse case scenario with heavy traffic going in both directions at the same, and it does not mean upload speed is limited to 25 Mbps in more typical scenarios.

NanoPi NEO does not come with any storage, and you can use any micro SD card you want, but FriendlyARM sells and recommend Sandisk Ultra 8GB SD micro card,  so it would interesting to see how the one they’ve sent me performs.

For that purpose I’ve installed iozone to test the micro SD card performance. You’ll need to edit /etc/apt/source.list to add multiverse at the end of the first two lines, and then:

I’ve run iozone3 with armbian community command line options, so that it can be compared to other SD cards:

So it’s not quite the fastest around, especially in terms of random write for some files, and if you want a board that boot very fast (i.e. faster than the 10 seconds boot I got), and your application is I/O depend you may want to get something better like Samsung EVO 32GB.

Google Research PRUDAQ is a 40MSPS ADC Data Acquisition (DAQ) Cape for BeagleBone Black & Green

July 21st, 2016 2 comments

Engineers at Google Research wanted to measure the strength of a carrier signals without having to use a bulky oscilloscope or DAQ (Data Acquisition) system,  so they looked into several makers boards to achieve this task, eventually decided to go with BeagleBone Black / Green, and created their own PRUDAQ cape capable of sampling 40 million samples per second, and open source it all.

PRUDAQPRUDAQ cape specifications:

  • Dual-channel simultaneously-sampled 10-bit ADC (Analog Devices AD9201)
  • Up to 20MSPS per channel (40MSPS total) theoretical
  • 0-2V input voltage range (DC coupled)
  • 4:1 analog switches in front of each channel provide a total of 8 single-ended analog inputs. (See here for differential input)
  • SMA jacks for direct access to the 2 ADC channels
  • Flexible clock options:
    • External input via SMA jack
    • Internal on-board 10MHz oscillator
    • Programmable clock from BeagleBone GPIO pins
  • Powered via BeagleBone headers – no external power needed
  • Fully exposed BeagleBone headers on top to connect/stack more electronics or another cape
  • Dimensions – 87mm x 56mm (+/- 1mm)
  • Weight – 29 grams

The complete software and hardware documentation can be found on the Wiki and source code and design files in Github. The software is based on BeagleLogic logic analyzer, and you can retrieve and analyze the data on your computer using the command line with a typical output looking like:

The Beaglebone Black already has an ADC input, but PRUDAQ allows for much faster sampling, suitable to capture radio waves for example. Bear in mind that it’s not really suitable to be used as an oscilloscope due to limitations such as 0 to 2V range, and others. Any specific questions about PRUDAQ project can be asked on PRUDAQ users Google Group.

While the add-on board has been designed by Google Research engineers, it is not a Google product, and it’s made by GetLab, and currently sold on GroupSets for $79 for the cape only, or $159 as a bundle with a BeagleBone Black, PRUDAQ cape, an 8GB micro SD card pre-loaded with BeagleLogic image, one 64GB USB 3.0 Thumb Drive, one BNC-M to SMA-M RG-58 Cable, a USB mini cable, and 3 jumpers.

Gateworks Ventana GW5530 SBC is Designed for Drones, Robots, and Digital Signage

July 21st, 2016 No comments

Gateworks Ventana is a family of boards based on NXP i.MX6 processor designed for embedded applications, and often include one or more mini PCIe ports for expansion. Their latest single board computer – Ventana GW5530 –  is powered by an NXP i.MX 6Dual processor coupled with 512MB RAM, 256MB storage, a mini PCIe port, a micro SD / SIM card slot, micro HDMI output, and some I/Os.

Click to Enlarge

Click to Enlarge

Ventana GW5530 specifications:

  • SoC – NXP i.MX6 Dual Core ARM Cortex-A9 processor @ 800MHz with Vivante 2D and 3D GPUs
  • System Memory – 512MB DDR3 (Up to 2GB as option)
  • Storage – 256MB flash (Up to 2GB as option), micro SD/SIM card slot, serial configuration EEPROM
  • Video & Audio Output – micro HDMI 1.4 port
  • Connectivity – Optional u-blox EVA-M8M GPS Receiver with MMCX or u.FL Antenna Connector
  • USB – 1x micro USB 2.0 OTG Port
  • Sensors – 9-axis inertial module (accelerometer/gyro/magnetometer)
  • Expansion
    • High-Power Gen 2.0 mini-PCIe Socket with USB 2.0 Support
    • SIM socket (shared with micro SD card)
    • Video input header for CVBS, Y/C, YPrPb
    • Digital and serial I/O header
  • Debugging – JTAG connector
  • Misc – RTC with battery backup, voltage and temperature monitor, programmable watchdog timer, reset header, LED header
  • Power Supply – 8 to 60V DC input via 2-pin header; Reverse voltage protection
  • Power Consumption – [email protected] (typical); 7W Available for mini-PCIe socket
  • Dimensions – 100x35x13 mm
  • Weight – 28 grams
  • Temperature Range – -40°C to +85°C

    Click to Enlarge

    Click to Enlarge

The company can provide OpenWrt, Android, Yocto Linux, and OpenEmbedded board support packages (BSP) for the board. Some documentation can be found on Ventana wiki. The boards targets “small embedded applications such as Man Portable Units (MPUs), Unmanned Aerial Vehicles (UAV) equipment, digital signage, and robotics”.

Block Diagram

Block Diagram

The board is available now, with pricing not disclosed, and 1 year warranty. Gateworks GW11038 development kit with GW5530 SBC, OpenWrt BSP, USB and video cables, power supply, and a JTAG programmer can also be purchased for evaluation. More details can be found on Gateworks Ventana GW5530 product page.

Getting Started with NanoPi NEO Development Board – Ubuntu Core Firmware

July 20th, 2016 30 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.


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 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.


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.

Onion Omega2 is a $5 Linux WiFi IoT Board (Crowdfunding)

July 20th, 2016 5 comments

Onion Omega board was first introduced in 2015. The tiny OpenWrt Linux board featured an Atheros AR9331 processor with GPIO headers, and various baseboards and add-ons. The company has now launched a Kickstarter campaign for the second versions – Omega2 & Omega2 Plus – with a faster processor @ 580 MHz, compatible with docks and add-ons boards used for Omega, and a much lower price with $5 for the Omega2, and $9 for Omega2 Plus with more storage and memory.

Omega vs Omega2 / Omega2 Plus Board

Omega vs Omega2

Omega2 & Omega2 Plus specifications:

  • WiSoC – 580 MHz processor, possibly Mediatek MT7688 MIPS processor used in LinkIt Smart 7688
  • System Memory
    • Omega2 – 64MB
    • Omega2 Plus – 128MB
  • Storage
    • Omage2 – 16MB flash
    • Omega 2 Plus – 32MB flash + micro SD slot
  • Connectivity
    • Built-in – 802.11 b/g/n WiFi with on-board and external antenna support
    • Via add-on boards – Bluetooth 4.0 LE, GPS, and 2G/3G
  • Expansion – 15x GPIO, 2x PWM, 2x UART, 1x I2C, 1x SPI, 1xI2S
  • Power Supply –
  • Dimensions – A fourth the size of the Raspberry Pi, and less than a third the size of the Arduino UNO
Omega2 with Dock and Arduino Shield

Omega2 with Dock and Arduino Shield

Although the module can be used own its own, it’s much easier and fun to use with docks with the Expansion dock, mini dock,  power dock, or Arduino dock shown above, and combined with one or more add-on boards adding relays, OLED displays, servo board, Ethernet, Bluetooth, GPS, or 2G/3G cellular connectivity. The developers also partnered with ControlEverything to provide for sensors add-ons.

Omega2_ProgrammingOmega2 runs Linux, likely OpenWrt, and can be programming with visual editor like Node-RED, as well as programming languages like C, C++, Node.js, Python, and php. You can checkout their github repositories to see what they’ve done for the original Omega board.

The campaign has reached its funding target within a few hours. Beside Omega2 and Omega2 Plus board, you may also consider get a bundle with a dock of your choice for $20 or $24, and various other kits are also offered as rewards. Please note that shipping is not included, and they’ll ask you to pay shipping later when the board is ready to ship with the price for the board only expected to be around $2 for most people, but it can be as high as $15 to some countries. Delivery is scheduled for November 2016.

Thanks to Freire & Nanik for the tip.

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.


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.


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 for the Colibri iMX6 and 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: 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 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

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 to send data to the embedded system, this one replies to the IP address

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.

ArduCAM has designed a Tiny Coin-Sized Raspberry Pi Compatible Module

July 18th, 2016 10 comments

Now you can design your own custom hardware and leverage Raspberry Pi software, by integrating Raspberry Pi Compute module (and soon Raspberry Pi 3 Compute module) into your custom designed baseboard. But if you’d like something more compact, and even more compact than a Raspberry Pi Zero or RPi Compute module, ArduCAM has been developing a 24x24mm Raspberry Pi compatible system-on-module powered by Broadcom BCM2835 processor.


ArduCAM “NanoPi” Module vs Raspberry Pi Zero and Raspberry Pi Compute Module

ArduCAM has also designed a small adapter board “UC-343 Rev. A” for the module with the following specifications:

  • SoC – Broadcom BCM2835 ARM11 Processor @ 700 MHz (or 1GHz?) with Videocore IV GPU
  • System Memory – 256MB/512MB LPDDR2
  • Storage – micro SD card slot
  • USB – 2x micro USB ports including one for power only
  • Camera – 1x MIPI CSI connector supporting 5MP or 8MP Pi cameras (dual camera support)
  • Expansion –
    • AV output header
    • 16-pin and 8-pin headers (unpopulated) with GPIOs, 2x I2C, UART, 2x SPI
  • Misc – Power LED
  • Power – 5V via micro USB port, or battery header
  • Dimensions – 36x36mm (Module only: 24mm x 24mm)
  • Weight – 5 grams
Click to Enlarge

Click to Enlarge

Since it’s compatible, it should run any operating system or program supported by Raspberry Pi Model B, Zero, and Compute module. They have even posted a demo video last month using the module connected to UC-343 demo baseboard.

I’ve not been able to find availability nor pricing information, but since it’s starting to show up on some shops without price, it should be available very soon. ArduCAM website only seem to have the announcement, but no further details. If the module gets a little too popular, it could also end up being killed, just as what happened to ODROID-W board, as Broadcom may refuse to sell the processor.

Via Amornthep on Facebook.

LibreELEC 7.0 Ported to Amlogic S905 TV Boxes & ODROID-C2 Board

July 18th, 2016 21 comments

Most TV boxes are now sold pre-loaded with Android, but there’s still a fair amount of people who only want to play videos in their box, or only run Kodi, so they may prefer a Linux experience. Some companies provide ready-to-use solution such as ARNU Box Mach 10 64-bit Pure Linux, but in some cases it’s also possible to side-load OpenELEC or LibreELEC, with the main advantage being that it is usually quite cheaper at the cost of being a bit more complicated.

LibreELEC_AmlogicThanks to a comment by Sabai, I discovered LibreELEC 7.0.0 had been (unofficially) ported to Amlogic S905 TV boxes, and tested one devices such as NEXBOX A95X (S905), WeTek Hub, Beelink S905 Mini MXIII, MXQ Pro 4K, and others. If you own an ODROID-C2 board, you can load another LibreELEC 7.0.0 image.

If you are unsure whether your Android TV box is supported, you should first try the SD card method by copying  aml_autoscript, kernel.img,  SYSTEM and 2 md5 files to the root of the SD card, and enter recovery. This is all explained in details in the forum post linked above, and this will not affect your Android installation nor data.

If you’re happy with the results, and don’t plan to use Android anymore, you can flash LibreELEC to the NAND/eMMC flash. The procedure is the same as the SD card method, except the files are different, and you’ll have to copy aml_autoscript, factory_update_param.aml and an update zip file containing LibreELEC firmware to the SD card.

The developers have already fixed many bugs, but at the time of writing there are still a few known issues for the TV box version:

  • Reboot and poweroff may take a long time or don’t work at all when using Broadcom WiFi
  • No multichannel PCM audio
  • Jerky playback of some 29.97fps videos and some Live TV channels
  • CEC is still a bit buggy

There are also some unsupported features such as SSV6051 WiFi, front LED/segment displays, and built-in DVB tuners.

You can report other bugs on LibreELEC forums. If you’ve tried it on your own Amlogic S905 TV boxes, it might be nice to report success or failure in comments too.