BeagleBoard.org BBB Wireless BBBWL-SC-562 - Review

Table of contents

RoadTest: BeagleBoard.org BBB Wireless BBBWL-SC-562

Author: hlipka

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Plain BBB, RaspBerry Pi

What were the biggest problems encountered?: Documentation is sometimes spare, and difficult to find.

Detailed Review:

First, let me thank Element14 for the chance to participate in this road test. I always wanted a BBB but never came around to purchase one, but got one for the X-mas event from E14 - and this gave me the idea which I proposed for this review.

The plan for this road test was to use the wireless version of the BBB as logic analyzer. I started some work on this project with the regular BBB, but the need for all the cabling made its setup quite awkward (especially Ethernet cable are rigid and clunky). The idea was that with a wireless version, I could power the BBB from a rechargeable battery, would not need a network cable and so could use it as a handheld tool.

The basis for this was the 'BeagleLogic' project, which implements a 100MHz, 14-channel LA with up to 320MB sample memory. There is an additional BeagleLogic cape which acts a voltage translator so you can sample signals up to 5V. The Sigrok software supports the BeagleLogic, so this seemed like a nice combination.

So this review will me in three parts: first the general review of the BeagleBone Black wireless (and a comparision with the regular BBB), followed by what I did and learned during the project. The last part will  be a roundup to put everything into perspective.

The BeagleBone Black classic and wireless

Especially when compared with a generation 1 Raspberry Pi, the BBB is quite powerful. It has a fast processor core, 512MB memory, comes with eMMC flash on board and provides more GPIOs. The form factor is about the same, the BBB is only some millimeters smaller.

Both the BeagleBones and the RasPi come without standoffs (so be careful with anything sharp or metallic under them), but the BBB has more parts and connectors on the bottom. So it seems more vulnerable, and it also means it not as stable (and wiggles around when pushing the buttons). Generally the RasPi looks less crowded, which is surprising since it has more connectors (apart from the second GPIO header).

When comparing both generations of the BeagleBone Black, the differences are quite large. Not only replaces the wireless BBB the RJ45 socket with a WiFi chip and two antennas. It also comes with a new CPU which includes the 512MB main memory, and increases the on-board flash memory from 2GB to 4GB. Nonetheless they are supposed to be compatible in terms of software and hardware.

Unfortunately none of the BBB boards have a revision number of them. For the BBB Wireless its easy - its the first of its kind (so its on revision A5). But for the regular BBB there are already 10 revisions available, and they are not all compatible (e.g. Rev. C comes with 4GB flash on board).

That the BBB exposes more GPIOs than the RasPi is nice for development, but it comes at the expense of having less other connectors. It sports only a single USB port for devices, so you probably need an additional USB hub (especially when you want to use it as a desktop computer). Also, the connectors are places close together. I especially had problems with the mini-HDMI connectors. It is placed so close to the USB port that one needs to be careful with selecting a USB cable because otherwise they won't fit both at the same time.

 

Having a Debian Linux pre-installed on the internal eMMC flash is really nice, since it means you can start right away working with the BBB. When starting up, it registers itself as a dummy network adapter with the host PC so you can connect to it via network.

 

Speaking of the network: as long as you use the GUI (a LXQt desktop) setting up a wireless connection is rather easy - just start the Connman GUI and you can configure this easily (and for Ethernet with the regular BBB, its just using DHCP so you don't need to do anything). But if you don't want to use the GUI (as I need to do with the BeagleLogic - more on that later) documentation get scarce. There are some comments in /etc/network/interfaces that imply that you can set up connman with a static WiFi connection, but thats it. As of writing this, the official BeagleBone pages (http://beagleboard.org/) do mention the BBB Wireless, but there is no documentation linked (and the quick start guide that come in the box just links to the beaglebone.org home page). The official wiki also has no direct links, but at least has some basic information. Even the "Getting Started" page which you get when accessing the BBBW from your browser just talks about the regular BeagleBone...

 

Startup into the desktop takes a while, and as far as I can tell there seems to be no output on HDMI until the GUI has started up (where the RPi shows you the boot log). But the board LEDs gives information about access to flash memory and CPU activity, so you know when its working, and when it stopped.

The supplied Debian boots into a LXQt desktop, which is easy to use and comes with a small selection of programs (browser, file manager, terminal, image viewer, some configuration tools). Performance seems to be OK, but the desktop wasn't why I wanted to work with it BBB. What was strange though is that there is a constant 10% load on the CPU, caused by the process lxqt-panel. When there is no activity this should be much closer to zero.

The BeagleLogic project

You always need to read the fine print on the projects you want to work with. The BeagleLogic is a fascinating project - it uses the programmable hardware (called PRU - programmable real-time unit) of the BBB to implement a 100MHz logic analyzer. Its drawback is that it needs to disable the HDMI output of the board to get to the GPIO ports it needs (and if you want to use all 14 pins you also need to disable the onboard eMMC flash memory). When I found out about this it rules out using the BBB with an external monitor. So using BeagleLogic requires the use of a host computer. The proposed solution is to use the Sigrok CLI for capturing (or even doing the capture using the dd command line tool), then to transfer the capture file manually to the PC and then view it there. This is quite complex and destroys the flow. So my idea was to run the Pulseview GUI application on the BeagleBone, and use the X11 networking capabilities to have it show up on the PC. This would make capturing seamless, and allow to use the capture and trigger configuration of Pulseview instead of the command line.

 

The BeagleLogic project provides a complete system image with all the needed software (BeagleLogic driver and configuration, Sigrok CLI) compiled and installed. After download, extract is (using the 7z extractor), and then write it to the SD card (sudo dd if=bone-debian-8.4-lxqt-4gb-armhf-2016-04-10-4gb.img of=/dev/sde bs=1M status=progress - but make sure to use the correct target partition, otherwise you might delete one of your hard disks).

Then put the SD card back into the BBB, hold the boot button (the one labeled S2) pressed and (re-)apply power (a reset is not enough). The need to select the SD card as boot source is one of the thing I don't like on the BBB. it would be much nicer if there either was a jumper for selection, or when the boot loader could automatically boot from SD card when it found a system image. Another thing - make sure your power supply is able to deliver 2 amps, and use a good USB cable. Otherwise voltage might drop too far during boot, and the BBB might crash. Even then it seems the BBB is sensitive to the the kind of SD card I'm using, sometimes it just doesn't boot up properly (from my three SD cards, one did not work on the BBB from the start, and a second one now refuses to boot even though it worked previously).

 

To be sure you booted up the correct image, check the /opt folder (with ls /opt) - there must be a BeagleLogic folder. When its there, a capture can be run via

sigrok-cli -d beaglelogic -c samplerate=<samplerate> -o outputfile.sr

and the resulting file can be viewed with PulseView.

Unfortunately, when you want to try this on the BBB Wireless, there is another fineprint: the new SOC with its included wireless chip seems to be supported only by the new 4.4.x kernels, but the BeagleLogic require the older 3.8.x kernels. The reason for that is something called "device tree overlay", and is the mechanism by which one can access all the hardware peripherals in a generic way, without needing too much kernel support. Unfortunately the inner working of the DTO have changed, and BeagleLogic did not kept pace (the changes were quite incompatible). I tried to install a 3.8.x kernel on a current debian image for the BBBW, which succeeded first - but it crashed on the first boot.

So that means I need to use a wireless dongle on the regular BBB, which has kind of the same result (but probably needs more power).

 

Compiling all the Sigrok tools

I decided to skip the wireless setup for a while. The documentation states which adapters are supported well, but is silent about configuration from the command line. There are some hints about using 'connman' in /etc/network/interfaces, but thats it. So I relied on the wired Ethernet connection and the serial console.

 

The latter is one of the things to like about the BBB: there is a serial connector on the BeagleBone, which fits the standard FTDI adapter boards. Plug one in (unfortunately you can't use a cape anymore), and you get a boot log and a terminal. This can be used to interact with the BBB even when there is no network connection (or you don't use the USB tethering). It also allows to see when something goes wrong during boot (note: it uses 115200 baud, 8N1).

 

Getting the sigrok sources to compile properly (including the Pulseview GUI) took a while and is nit straightforward, so I wrote down the detailed steps separately. But essentially its:

  1. Enlarge the partition on the SD card so there is room for all the files
  2. Create a swap file to increase the available main memory (esp. compiling Pulseview needs more than what is available)
  3. install all the needed development packages and sources
  4. Download the source files
  5. compile and install everything in the correct order

 

I still remember more than 20 years ago running Doom remotely via X11, from a machine more than 100km away. Today, installations are more secure and so by default its not possible to have remote X applications showing up on your desktop (which is a shame). Doing so involves three steps (assuming you are running Linux - on Windows you first need a X server such as XMing):

  1. have your X server (thats the program showing the windows on your machine) accept remote connections. It might be configured to forbid this explicitly (by setting the '-nolisten tcp' parameter), or it might be a parameter to start listening
    1. grep -r 'nolisten tcp' /etc/, this resulted in one hit in /etc/X11/xinit/xserverrc for me - remove this parameter
    2. or look in /etc/sddm.conf, section [XDisplay], and set ServerArguments=-listen tcp
    3. or look in /etc/lightdm/lightdm.conf (on newer Ubuntus, you need a file /usr/share/lightdm/lightdm.conf.d/100-custom.conf), have a section

      [SeatDefaults]
      xserver-allow-tcp=true
      xserver-command=X -listen tcp

  2. After restarting the X server, you allow remote connections via xhost + (you can restrict this to specific IPs)
  3. and on the BBB, you run
    export DISPLAY=YOUR_DESKTOP_IP:0
    xterm
    and you should get a terminal window

If this works, then you can start pulseview the same way, it will run on the BBB but show up on your desktop.

 

There is a quite recent project call XPRA, which provides a faster alternative to remote X11. Its a little bit tricky to install on the BBB (you need a big list of additional dependencies to compile from source - I can add the exact steps when requested), but provides a quite snappy user experience afterwards.

Unfortunately, BeagleLogic and PulseView don't play that nice together:

  • the capture configuration allows only to select a sample rate, but not a sample depth
  • there is no trigger configuration
  • and it crashes once in a while

So it seems that while my initial idea of having a standalone logic analyzer which shows its user interface on a remote PC seems feasible, it won't provide the features and user experience I would like. This leaves me wondering whether I should invest my time into getting Pulseview more stable (and maybe the missing features running) and the wireless network configured properly. It might be a better investment to just buy a CY7C68013A module, which for 4 EUR provides about the same feature set (but only at 24MHz).

This is not really a fault of the BeagleBone, but the struggle with getting the wireless setup running from the command line, and its incompatibilities between the older and newer kernels add to the frustration.

Just as a reference, here are the parts that were supposed to go into that project:

The second board is the BeagleLogic breakout which serves as a voltage translator and buffer (trying to save the BBB when something should go wrong). The battery on the button is the LiPo battery from an old Sony tablet - in fact its three cells in parallel. The were supposed to be stacked onj top of each other, and then they are only a little bit larger than the BBB. There is another nice feature: the BBB sport a (unpopulated) battery connector, which means it can be powered directly from a LiPo battery. No additional hardware is needed - the TPS65217 PMIC on the BBB provides charger functionality.

 

Wrapup

I ended up with mixed feelings. One one hand, the BeagleBone Black (and especially the Wireless version I did test specifically) fells really nice. Its quite fast and comes in a nice form factor. It felt more snappy than a Pi2 (though I did not do any performance comparisons). It provides a lot of GPIO connections which makes it ideal for embedded projects. It also comes, on-board, with all the programming capabilities to make use of that hardware (by using the Cloud9 IDE which allows to program the BBB in JavaScript). The great support for LiPo batteries makes it ideal for portable applications.

 

On the other hand, there are several shortcomings which make it more difficult to use. For a small desktop system, a single USB port is just not sufficient - you always need an additional USB hub (which eats into your money and your space). And while documentation is quite good for GUI usage, its getting more sparse when you are looking for anything command line. Granted, the official RPi documentation is also quite limited, but there is a much larger community out there (and the typical setup is nearer to the usual Debian and Ubuntu systems, which adds to the available documentation).

 

The PRU in the used SoC is a great invention, but the changes in the Linux kernel (from 3.8 to 4.4) make its usage by applications more difficult. Such compatibility problems are really rare in the Raspberry world, whereas the large number of different BeagleBone variants make this world more complicated (even for the BBB there are several different production versions, and not all are compatible).

Oh, and making it so difficult to boot from SD card is also a big minus. Not all distributions come with support for flashing itself to the internal eMMC, and the SD card also makes it quite easy to change the operating system (which helps during development).

 

So my wishes would be: add the little bit of extra documentation, and make it easier accessible. Compatibility of the BBBW with older kernel version would be great (or make the provided APIs compatible between different versions), since there are probably also other projects which rely on such features. For future board revisions, more USB ports would be great, since it would make using it as a desktop much easier. (And since its wireless you can mount it at the back of a monitor and probably also power it from there, so you don't need additional cables).

Anonymous