Install Build Prerequisites

To build all Python modules the following libraries need to be installed. Simply copy-and-paste the following line:

sudo apt install zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev

Build Python

Download the latest version of Python, build, and install:

1. Download the latest Python, version 3.9.1, from https://www.python.org/downloads/.
2. Untar the file (we’ll assume it’s downloaded to the default ~/Downloads):

   tar xvf Downloads/Python-3.9.1.tar.xz

3. Make a build directory at the same level as the untarred source directory. In my case I named the build directory build-python-3.9.1
4. Change directory into the build directory.
5. From within the build directory execute the configure script:

   ../Python-3.9.1/configure --enable-optimizations

6. Run make with all active cores:

   make -j $(nproc)

   On my machine I enabled all six cores of the Jetson Xavier NX. Running with fewer cores will result in a longer build time.

7. Install into the alternate location for this version of Python:

   sudo -H make altinstall

8. Check for the alternate location with which python3.9. It should return /usr/local/bin/python3.9.

I created a Python 3.9.1 virtual work environment, something I highly recommend. I do that to keep the stock and newly installed environments distinct from one another. These are the specific steps I used to create that virtual Python environment.

1. In your home directory create a work folder. On my system I named it ‘vpython’. Change directory (cd) into it.
2. Then create a Python VE:

   python3.9 -m venv 39

3. While you’re there you might as well update pip. Always count on the pip bundled with any version to be out of date with the official version. Using my environment as an example:

   $HOME/vpython/39/bin/python3.9 -m pip install --upgrade pip

Now you’re ready to use the latest Python.

Install PyQt5

I use Python library PyQt5. In order to do that you must install Ubuntu’s Qt5 support libraries as well as the Python module.

1. Install Ubuntu Qt5 support: sudo apt install qt5-default
2. Enable Python 3.9 virtual environment: source $HOME/vpython/39/bin/activate
3. Install Python PyQt5: pip install PyQt5

You’re pretty much free to use Python 3.9 with PyQt5 at this point.

Note that these directions also apply to installation on the Jetson Nano on the same Jetpack version.

I managed to build LiteIDE X37.1 from the GitHub sources by following the projects clear, simple directions. They were:

$ git clone https://github.com/visualfc/liteide.git$ cd liteide/build$ ./update_pkg.sh$ ./build_linux_qt4.sh## Run it. While within the build folder from above: ##$ cd liteide/bin$ ./liteide

They are part of the website’s installation directions. The website is here: http://liteide.org/

The directions were written for Ubuntu 16.04, but they work just as well for Ubuntu 18.04. It should be noted that Qt5 doesn’t need to be installed. Just start with the git clone of the source and go from there. I’m running it out of where it was built. I haven’t run the installation and for my uses I don’t intend to.

For the record I have the latest version of Go, 1.14.3 for linux-arm64 (ARMv8).

This isn’t the first time I’ve built this tool. I built an earlier version under Raspbian Buster on the Raspberry Pi 4. It built and worked fine there, too.

As for usefulness, it is quite useful, at least for my purposes. In the example above it found all my files under the default GOPATH (go env GOPATH) and I was able to quickly navigate to my work and open one of my files I developed on the Raspberry Pi. It’s my hope to build and attempt to run the software and Adafruit hardware I used on the Raspberry Pi.

Right now I’m in the process of fulfilling a promise I made to my wife to clean out a good portion of our house and begin to do some home improvements. I’ve accrued a lot of “homeowner dept” that I need to pay down quite a bit. I’m retired and back to living in the regular world. These little reports will be short and sweet, and perhaps infrequent. But I won’t mind. I do all of this because I enjoy it, when I feel like it. Not because I have to. And that’s alright.

1. Download the source from https://www.python.org/downloads/. In this post it was Python 3.8.3
2. Untar the file:

   tar xvf Downloads/Python-3.8.3.tar.xz

3. Make a build directory at the same level as the source directory. In this case it was named build-python-3.8.3
4. Change directory into the build directory.
5. From within the build directory execute the configure script:

   ../Python-3.8.3/configure --enable-optimizations

6. Run make:

   make -j 4

7. Install into the alternate location for this version of Python:

   sudo -H make altinstall

8. Check for the alternate location with ‘which python3.8’. It should return ‘/usr/local/bin/python3.8’.

Python 3.8.3 will build and be functional as is, but if you want all the features to build for Python you’ll need to install a list of additional libraries in order to enable all the features, or at least as many as you care about.

My list of imported libraries for this build includes:

• libgdm-dev
• libnss3-dev
• libssl-dev
• libsqlite3-dev
• libreadline-dev
• libbz2-dev
• libdb-dev, libdb++-dev (Berkeley db)
• libgdbm-dev

Why the additional libraries? Because this is what happened when I built in my unique environment the first time (First run).

# First runPython build finished successfully!The necessary bits to build these optional modules were not found:_bz2  _dbm  _gdbm  _hashlib  _sqlite3  _ssl   _tkinter  readline To find the necessary bits, look in setup.py in detect_modules() for the module's name.The following modules found by detect_modules() in setup.py, have beenbuilt by the Makefile instead, as configured by the Setup files:_abc  atexitpwdtime   Could not build the ssl module!Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381# Second runPython build finished successfully!The necessary bits to build these optional modules were not found:_tkinter   To find the necessary bits, look in setup.py in detect_modules() for the module's name.The following modules found by detect_modules() in setup.py, have beenbuilt by the Makefile instead, as configured by the Setup files:_abc  atexitpwdtime   

It took two attempts, the first to have make list the modules that wouldn’t be built at the end of a full build. I went looking in both the Bash script function ‘detect_modules()’ as well as on the web, and managed to install support for everything I cared about. The only module I didn’t care to build was tkinter. Tkinter is the interface to the Tk GUI toolkit. I use PyQt5 instead, so found no need to build it. Your needs, of course, may vary, and it may come to pass I need a package that uses Tcl/Tk GUI. But I doubt that.

Once Python 3.8.3 was built I created a virtual environment according to the directions here: https://docs.python.org/3/library/venv.html . Just as I didn’t want this latest version installed over the stock Python 3.6.9, I’m using a virtual environment to keep usage of 3.8.3 from corrupting the stock environment. In my environment I create an alias to execute ‘activate’. One nice feature of a virtual environment is that ‘python’ points to Python 3.8.3.

More to come…

Earlier I installed all the bits and bobs necessary to build Visual Studio Code on JP44, and managed to get it up and running, mostly. That is, it would open and edit files, it handled syntax highlighting for the sources I cared about, and at least it allowed me to install two extensions. The big problem is that after that first extension installation, the extension list is now empty, meaning I can’t install any others. And I wrote I’d probably stick with it regardless.

Then I remembered I’d extended and configured both Vim and Emacs into very useful tools on my RPi4. I powered up the RPi4 and copied my Vim and Emacs configuration files over to the Jetson Nano and JP44. Easy, right?

For Vim there wasn’t an issue. Everything ran just fine. Emacs installed from the repo was different. I knew I had a problem when the following line in my .emacs file failed on startup with the local emacs:

(global-display-line-numbers-mode)

I checked the version of emacs installed on JP44, and sure enough, it was version 25, one major release back from the version installed on my RPi4 and Raspbian. No, I wasn’t going to change that line (and a few others) back to the older way of doing things. Instead I went over to the Project Emacs page on Savannah ( http://savannah.gnu.org/projects/emacs/ ), followed the directions there to clone from their GitHub repo hosted on Savanah, and went about the business of building an up-to-date emacs.

First time through I was missing a few needed development libraries. I got those installed, got a proper configuration, and then built it. When I fired it up I was horrified to see it was using old school X fonts on everything. Not an anti-aliased font in sight. That just sucked, so I starting looking at the configure output and installing all the necessary libraries emacs needed to support anti aliased fonts. The full list of necessary installs are:

• texinfo
• libxaw7-dev
• libjpeg-dev
• libpng-dev
• libgif-dev
• libtiff-dev
• gnutls-dev
• libncurses-dev
• libfreetype6-dev
• libcairo-dev

Some of those libraries are needed just to get configure to finish at all. They are listed in the order they were installed. After installing the freetype developer library I got the following interesting warning from configure:

configure: WARNING: This configuration uses libXft, which has a number offont rendering issues, and is being considered for removal in thenext release of Emacs.  Please consider using Cairo graphics +HarfBuzz text shaping instead (they are auto-detected if therelevant development headers are installed).

Ok. That’s when I installed libcairo-dev. After that it configured and then built. ‘make install’ puts the binary in /usr/local/bin. When I opened up emacs the second time, it was lovely to behold.

Fonts everywhere are nicely rendered and anti-aliased. You’ll note also that this is emacs version 28, which is fine by me. It works with Go, C/C++, Python, and bash, which is all I really need. I also noticed that emac’s memory footprint is tiny compared to VSCode. Which is ironic considering that in the days when men used Vaxen and 1MiB of memory was considered a luxury, emacs was frowned upon by sysadmins who didn’t like how too many emacs sessions could tax those mighty Vaxen. Now I run it on a $100 quad-core 64-bit computer with 4GiB of memory because it’s lean and mean compared to other equivalent tools. My how the times have changed.

If you want to know more about this version of the Jetson Nano Developer Kit software, there is this:

https://forums.developer.nvidia.com/t/jetpack-4-4-developer-preview-l4t-r32-4-2-released/120592

The Developer Preview seems to have some of its own oddities. For example, I discovered that Python’s pip wasn’t installed. Pip’s needed to install a set of tools I’ll talk about next. But in the mean time, you need to follow these directions to install pip for Python3:

https://pip.pypa.io/en/stable/installing/

Once pip is installed you need it to install a set of Python-based tools known as jetson_stats. Included in that collection is jtop. You can follow the directions on the GitHub repository here:

https://github.com/rbonghi/jetson_stats/wiki

Note that the latest Jetson Nano Developer Kit is still based on Ubuntu 18.04.4. I’ve looked around and it would appear that migrating to Ubuntu 20.04, the current LTS, is some ways off. Which for me isn’t a problem as there’s plenty to work with as is.

{"nameShort": "Code - OSS","nameLong": "Code - OSS","applicationName": "code-oss","dataFolderName": ".vscode-oss","win32MutexName": "vscodeoss","licenseName": "MIT","licenseUrl": "https://github.com/Microsoft/vscode/blob/master/LICENSE.txt","win32DirName": "Microsoft Code OSS","win32NameVersion": "Microsoft Code OSS","win32RegValueName": "CodeOSS","win32AppId": "{{E34003BB-9E10-4501-8C11-BE3FAA83F23F}","win32x64AppId": "{{D77B7E06-80BA-4137-BCF4-654B95CCEBC5}","win32UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32x64UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32AppUserModelId": "Microsoft.CodeOSS","win32ShellNameShort": "C&ode - OSS","darwinBundleIdentifier": "com.visualstudio.code.oss","linuxIconName": "com.visualstudio.code.oss","licenseFileName": "LICENSE.txt","reportIssueUrl": "https://github.com/Microsoft/vscode/issues/new","urlProtocol": "code-oss","extensionsGallery": {"serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery","cacheUrl": "https://vscode.blob.core.windows.net/gallery/index","itemUrl": "https://marketplace.visualstudio.com/items"},

In spite of starting with a fresh pull, the build ran much faster due to having all the npm packages already in place. Starting VSCode took the same amount of time as before. When it finally finished the first start, the extensions gallery was visible. Isn’t it lovely to behold?

So then I decided to install three extensions; C/C++, Go, and Python. We’ll lead off with the Python extension because that’s what always seems to bubble up to the top when we first open the extensions gallery.

After installing the first three extensions, I closed and re-opened VSCode. First problem is that the C/C++ extension won’t work on ARM.

I removed the C/C++ extension, then decided to see what else I could find in the extensions gallery. Except, when I removed the extension and opened the gallery, the gallery was empty. Restarting VSCode wouldn’t bring it back. It’s now empty.

Oh well. At least I can still edit C/C++ source files, with decent syntax highlighting, as shown below.

I will continue to use this version of VSCode for the time being. I suppose I could outfit Vim the same way I’ve done on Raspbian, or install Emacs and extend it as well. But I really do like the VSCode environment, and am slow to give it up even with the problems it appears to exhibit here. So far it behaves quite well as a source editor, probably the best of all the editors I’ve mentioned (and far better than gedit). I could also help the community by debugging further, or going back to the last branch release and trying that to see how it works. Getting npm set up fits with other projects I have in mind, so it definitely isn’t a waste for me. But I don’t want to get pulled down a deep rabbit hole working on VSCode for Ubuntu ARM on the Jetson Nano. The primary purpose of the Nanos are in support of embedded machine learning development.

Who knows where this will eventually lead…

My second Jetson Nano Developer’s Kit arrived Monday. Following Nvidia’s directions I had their version of Ubuntu up and running in about thirty minutes. I’ve mounted the Noctua NF-A4x20 5V PWM fan on top with nylon ties, exactly like the first. One reason for buying the B01 is it now comes with two MIPI CSI camera connectors on the edge, CAM0 (right) and CAM1 (left). All versions before this had only one, CAM0. The power selection block is now further inboard, and wonder of wonders, it comes with a shorting block. In the photo the shorting block is in place to select the barrel connector and I have a 5VDC 4A power supply connected via the barrel connector.

A minor editorial comment: I’ve now installed and worked with two Jetson Nano boards, the A02 and B01. In both instances I never once encountered any issues configuring, installing the OS and software tools, or attaching devices. This is counter to the insanely stupid complaints I read on Amazon where a number of knuckleheads gave the board 1 star and bitched about how terrible the Jetson Nano was. The boards are great and work just fine. But you can’t be an idiot around them, or you will break them.

Rather than give screen shots running software you already know about, this is a screen shot where I downloaded and built Visual Studio Code. VSCode for ARM isn’t provided from the same source as all other operating systems. There is a third-party DEB file, built from a year-or-two-older version of VSCode, but no thanks. Instead, I followed the directions here ( “Building Visual Studio Code on Jetson Nano”, https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). I made one major modification to Clarence’s directions, and that was to install NodeJS version 12 instead of 10 using setup_12.x. That’s because the current LTS is version 12. Nevertheless it built, and I was gob-smacked when it came up with the introductory screen the first time I ran it. I was then able to open Bash, C/C++, and Python source files.

The only issue right now is I can’t install any extensions. The extension list is empty. There is a fix I have not tried yet, but which I will the next time I build VSCode. I’m building on my Crucial MX500 .5TiB SSD, so I have plenty of space to just re-clone and re-build with that fix on Clarence’s web page. I wanted to see if it would at least build without errors before I made any modifications to the product.json file. Since it obviously does work, the next step is to try and get the extensions working.

I am so happy to have this building and working on any ARM-based system.

In case you’re curious we’re running with standard Ubuntu 18.04.4.

This is the fully built Visual Studio Code version, from trunk. Note that it’s version greater than the current official installable release, which is 1.44.2.

That wasn’t a problem with Raspbian Buster up until just recently. Before that time, I had an entry for my SSD in fstab that started out like this:

/dev/sda1 ...

It worked just fine, until one day after a recent update that included the kernel, it didn’t. No warning that this was going to happen, none at all. After the update and subsequent reboot, the Raspberry Pi refused to boot, and instead dropped me into a prompt waiting for me to log in as root to fix the problem. Oh, wait, root is disabled by default in Raspian, so that just put me in an endless boot loop.

It took two attempts rebuilding a minimal boot micro SDXC before I finally figured out what was happening. Fortunately, that second micro SDXC card was a new one with a minimal Raspbian system, so it didn’t take too much effort to see that adding the entry to /dev/sda1 was causing it to fail to boot. Fortunately for me I have other Linux systems (my ten-year-old Samsung R580 running Ubuntu 18.04.04 came to the rescue) that allowed me to mount both micro SDXC cards, edit fstab and remove the entries. Once removed, both micro SDXC cards booted just fine in the Raspberry Pi 4.

Once I got back in I enabled root with ‘sudo passwd root’ and gave it a password. Now, if I have a problem where a Raspbian boot failure wants to dump me into the root account in single user mode, I can actually log in at that point.

The other problem was getting the USB SSD to mount. Here’s what I did to fix that. But first, a tiny bit of background.

The kernel in Raspbian buster uses what’s now known as a PARTUUID to identify a storage device instead of the old school device name in /dev. To find out what that PARTUUID is, you have to run this command at the command line in a terminal window:

pi@rpi4-4-01:~ $ sudo blkid/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="69D5-9B27" TYPE="vfat" PARTUUID="d9b3f436-01"/dev/mmcblk0p2: LABEL="rootfs" UUID="24eaa08b-10f2-49e0-8283-359f7eb1a0b6" TYPE="ext4" PARTUUID="d9b3f436-02"/dev/sda1: LABEL="SSD" UUID="ad89d540-a007-4d0a-887b-0b0dbefe3e8e" TYPE="ext4" PARTUUID="937a0120-01"/dev/mmcblk0: PTUUID="d9b3f436" PTTYPE="dos"

Since I already know the label on my SSD is “SSD” it’s quickly identifiable in blkid’s output. Copy the PARTUUID at the end of the entry, and use that in the fstab entry for the drive, like so:

PARTUUID=937a0120-01 /ssd ext4 defaults,auto,users,rw,nofail,x-systemd.device-timeout=30 0 0

Note that the quotes are not added to the entry. Also note all the flags I use, especially the shortened timeout (systemd.device-timeout=30) to shorten the wait during boot in case the SSD isn’t plugged in. The default is 90 seconds.

The primary reason I want the SSD mounted is because that’s where I put swap. In /etc/dphys-swapfile I add the following line:

# where we want the swapfile to be, this is the default#CONF_SWAPFILE=/var/swapCONF_SWAPFILE=/ssd/swap

I want my swap on the SSD because testing has shown the SSD is an order of magnitude faster than the boot micro SDXC. I use the Raspberry Pi 4’s as development and native build machines, rather than set up an emulation and cross-compile tool chain on my Mac. Believe it or not, it’s a lot simpler the way I have it set up. This is a decent compromise that doesn’t require me to put the entire OS on the SSD and then configure the Raspberry Pi to boot off the SSD. There are some significant problems with that, such as the Rasberry Pi 4 wasn’t set up to do that for quite some time after its release, and the fact that once configured that way, you can’t go back. So I put swap on the SSD, then cd onto a work area on the SSD and develop and build away.

This all gets back to the bigger question: why did this change, and when did it change? I use the same type of setup, and the same SSD, on the Jetson Nano, and it’s running a tweaked version of Ubuntu 18.04.04, complete with the Ubuntu graphical desktop. The fstab entry for that is the regular device entry, /dev/sda1.

Oh well. I just keep reminding myself that this is just a hobby, and I’m retired.

What is jetson_clocks, you ask? Let’s do a quick rundown.

nvidia@jnano-01:~$ file `which jetson_clocks`/usr/bin/jetson_clocks: Bourne-Again shell script, ASCII text executablenvidia@jnano-01:~$ jetson_clocksError: Run this script(/usr/bin/jetson_clocks) as a root usernvidia@jnano-01:~$ sudo jetson_clocks --helpMaximize jetson performance by setting static max frequency to CPU, GPU and EMC clocks.Usage:jetson_clocks.sh [options]  options,  --show display current settings  --store [file] store current settings to a file (default: ${HOME}/l4t_dfs.conf)  --restore [file]   restore saved settings from a file (default: ${HOME}/l4t_dfs.conf)  run jetson_clocks.sh without any option to set static max frequency to CPU, GPU and EMC clocks.nvidia@jnano-01:~$

Not much to the script operationally, and in order to use it, even for help, you need to preface it with sudo. That can get quite annoying if you accept how this Ubuntu’s /etc/sudoers file is set up, so here’s how to fix this Ubuntu from asking for your password every time you invoke sudo. On the %sudo line, add NOPASSWD: to the line as shown:

# Allow members of group sudo to execute any command%sudoALL=(ALL:ALL) NOPASSWD:ALL

If you’re new to Linux or uncomfortable in general with messing with such configurations, then leave it alone. I have fat-fingered NOPASSWD in the past and screwed up my ability to invoke sudo, which can be quite annoying if you don’t have root access.

With that out of the way, you’ll note that there’s four ways to invoke jetson_clocks. The most common way is without any command-line switches. That turns on the fan at full RPM, and will generate the most noise. Yes, the fan is very quiet, but in a quiet room you can still hear the white noise of the spinning fan. You can turn down the RPM by invoking --store and then --restore.

If you store with no other arguments then the text output is stored in ~/l4t_dfs.conf. That’s the good news. The bad news is that you had to use sudo to get that file, and the ownership is root. To change that to your regular ownership (nvidia in this example) you would need to invoke sudo chown nivdia:nvidia l4t_dfs.conf. I used the username nvidia in this example because that’s how I set up the initial account. You can call your initial login account ‘george’ or ‘ringo’ or whatever fits best for you. It’s that local username (and by the way, the group name as well) that you want to change ownership of that file to. Once it’s changed, open it up in an editor. I use vi/vim, but gedit is also provided. Whatever editor you want to use, open it up:

/sys/devices/system/cpu/cpu0/online:1/sys/devices/system/cpu/cpu1/online:1/sys/devices/system/cpu/cpu2/online:1/sys/devices/system/cpu/cpu3/online:1/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1428000/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq:1428000/sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq:1428000/sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq:1428000/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:1/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:1/sys/devices/system/cpu/cpu1/cpuidle/state0/disable:1/sys/devices/system/cpu/cpu1/cpuidle/state1/disable:1/sys/devices/system/cpu/cpu2/cpuidle/state0/disable:1/sys/devices/system/cpu/cpu2/cpuidle/state1/disable:1/sys/devices/system/cpu/cpu3/cpuidle/state0/disable:1/sys/devices/system/cpu/cpu3/cpuidle/state1/disable:1/sys/devices/57000000.gpu/devfreq/57000000.gpu/min_freq:921600000/sys/devices/57000000.gpu/railgate_enable:0/sys/kernel/debug/clk/override.emc/clk_state:1/sys/devices/pwm-fan/target_pwm:128/sys/devices/pwm-fan/temp_control:0

At the bottom of the file, on the line with target_pwn, the default is 255 when you save it. To change it to a more reasonable value, such as 128, simply do that and save it back out. Then execute sudo jetson_clocks --restore and it will use that file to set the fan RPM to the lower value, which in this case is 1/2 what the maximum is. The fan will slowly slow down to the new value, and it will get very, very quiet.

Once again, note that restarting the Nano will stop the fan from spinning. You have to explicitly restart the fan.

As I wrote in the last post, the Noctua fan was just sitting on top of the GPU’s heat sink. I’ve attached it more permanently to the heat sink with four self-locking nylon miniature cable ties from NET Electronics, Inc, Part number 04-08189. I routed the fan’s power cable such that it is now held tight to the fan itself, to keep it from being accidentally hooked and knocking the whole Nano assembly around. I am, if anything, clumsy.

Note that the fan does not start automatically. As I documented in the last post, you turn the fan on by executing ‘sudo jetson_clocks’ in a console window.

So far the fan has kept the processors nicely cool. Here’s a screen shot of jtop running in a window.

The output is a bit cryptic, but down towards the middle find the CPU and GPU temperatures and note they’re sitting around the mid-20s (Centigrade). I’m not sure what A0 stands for, and I know that PMIC doesn’t have a thermal sensor, so the software is constantly interpreting its temperature as a red 100°C. There’s not much going on at this time, so not much computational workload. I can say that before the fan was even placed on the heat sink, all those temperatures were sitting a good 5- to 10°C higher, especially A0.

One other odd observation. I’ve seen two how-tos about adding this fan to the Nano, and in both instances the fan was mounted so it was blowing air down onto the heat sink. I mounted it so that it pulls air up through the heat sink, which is the way I used to mount fans in big Intel boxen. I believe my mounting direction is better. They also used long screws, and one how-to even went so far as to thread the four holes in the heat sink and using M3 machine screws to mount the fan. I didn’t have any machine screws, but I had all those thin cable ties. Those cable ties work just fine.

You’re looking at the fully filled connector edge of my Jetson Nano. Starting from the left, there’s the barrel connector for the 5V 4A switching power adapter, the HDMI cable to the back of the monitor, then a TP-LINK WiFi dongle, with the USB connector beneath it for my Apple aluminum keyboard with built-in two port USB 2 hub. On the right are the final two USB 3 ports, with the Coral TPU Accelerator plugged in the top and a Crucial 500GB SSD plugged in the bottom. Let’s now take this apart, figuratively speaking.

Power

The Nano is capable of being powered from two sources; via micro USB on the far right or the barrel jack power connect on the far left. I started with a micro USB power supply specifically for the Raspberry Pi 3B (5v 2.5A) and it worked great for just getting the Nano up and running. I soon switched to the barrel jack power with a 5V 4A power supply (Shenzhen GEAO Technology Co. Ltd, Model GEO241DA-0540) I’d purchased years ago along with a BeagleBoneBlack SBC. In the photo above you’ll see I have shorted J48, the power select jumper block. Which leads me to my first negative comment.

I don’t know who at Nvidia made the decision not to include a shorting block for J48, but it was short sighted on someone’s part. If you’re going to run the Nano at full power and with all the USB ports filled then you need to select the barrel power connector as I’ve done. They could have avoided a lot of end-user annoyance and bad press if they’d placed a shorting block onto J48 along with a note on the single cardboard card that comes with the Nano that the board is set up to use the barrel jack, and to pull it off if they want to power from micro USB.

I got past this easily because I have an old Plano blue-and-grey ABS plastic tackle box I’ve had with me since college (decades ago), just filled with all sorts of odds and ends from my electronic hardware projects over the years. I went looking and sure enough, in one corner of the top tray there was a small collection of these left over from my days building IBM PC, PC XT, and PC AT clones, when they were needed for configuration strapping on ancient bronze-age motherboards and peripheral cards.

WiFi Networking

The Nano, unlike the Raspberry Pi 3 and 4, does not come with built-in WiFi. If you want WiFi, you can spend upwards of US$25 and get a special WiFi card that plugs into the GPU card, and comes with two big ol’ antenna. Which is a bit annoying if you don’t want those two big ol’ antenna lying around (literally) while in use, unless you want to spend more bucks getting a case that can physically mount everything. So I went back into my collection of bits and bobs and dug out this TP-Link USB adapter (150Mbps Wireless N Nano USB Adapter, model TL-WN725N) and plugged it right in. Ubuntu found it immediately and away we went configuring WiFi and bringing it up.

It’s a bit harder for me to ding the designers for the lack of built-in WiFi considering all the silicon already around in the environment. The main question is where would you put it so that it would work reliably. The boards pretty tightly packed, and the daughter GPU card with its heat sink pretty much precludes putting a WiFi adapter on the top surface of the bottom card. Right now, for my work, consuming a USB port with a WiFi dongle is the best compromise. If I want more sophistication or if I really need that USB port back, then I’ll look at the other WiFi solution for the Nano. But until then, the dongle works just fine.

Keyboard

Now we get to the reason for the title of this post. I’ve been using a Logitech MK710 wireless keyboard, bundled with an M510 mouse, since the Raspberry Pi 3. The key feature of this combination is that they both share a single wireless dongle, and thus save a precious USB port on the board. And it worked wonderfully when the only ports used on the Nano were for keyboard/mouse and WiFi.

Then I discovered that if I plugged anything else into the two empty ports the mouse stopped working. The keyboard was still operational, but the mouse would not move the cursor on the desktop. No playing with moving everything around changed the behavior. The workaround for now was to reach back into my cabinet and pull out my Apple aluminum USB wired keyboard, model A1243.

The Apple keyboard has one really nice feature, a built-in two port USB hub. I thus have a wireless mouse (Logitech M325) plugged into the side of the keyboard, keeping the Nano’s USB port usage down to a minimum, just as before. Now when I plug other devices, such as the Coral TPU Accelerator and Crucial 500GB SSD into the other two open USB ports, it all works together.

This isn’t the only board where this problem has appeared. I’ve seen the same problem on the Raspberry Pi 4 with Raspbian Buster, but not nearly as bad. On the Raspberry Pi 4 I can switch the mouse off and then on again to get it working for a while, before it stops moving the desktop cursor yet again. I can’t prove it definitively but this has all the earmarks of a Linux kernel driver bug in combination with this particular Logitech keyboard. I believe this to be a recent issue/bug that’s shown up in the Linux kernel, and perhaps is unique to just the ARM build, but it is a recent repeatable problem across at least two different ARM platforms.

Fan and TPU and SSD

The fan running on the top of the heat sink is the recommended NF-A4x20 5V PWM Noctua fan, and it works a treat. I don’t know what drugs the critics of this fan are taking, but there’s nothing more to using this than plugging it into the purpose build J15/Fan connector on the motherboard and enabling it with ‘sudo jetson_clocks’. It immediately fires right up and keeps the entire board nice and cool. Mine is just sitting on top of the heat sink. When I get around to it I’ll find a more permanent way to physically affix the Noctua to the heatsink. For now it keeps everything nice and cool just sitting there and I can barely hear it spinning. Winning all around. So much winning…

The last two items are for a later post. I’ve spent enough time on this post and I’m beginning to ramble.

I turned 66 earlier this month and in the process hit official retirement age. Guys who are rich enough usually go out and get something really blingy, like a new set of golf clubs or a deep sea fishing set, or something equally expensive and self-indulgent. Me, I went out and spent a whole $99 on the Jetson Nano. I figured if I was going to be “retired” then I’d go back in time and work with what got me started many decades ago, an embedded system. I started out as an electrical engineer and wrote assembly language drivers and test routines for embedded systems. As time went along, I drifted deeper into writing software as the hardware side of the business moved out of Atlanta and to places like Dallas and Silicon Valley. I never went with them because I’d traveled to those places and they weren’t as enjoyable as Atlanta and the South. And I can’t knock software development as it helped pay the bills and raise a family. Now I don’t need to do that anymore and I can go back and do what really scratches my intellectual itches.

This embedded system is a whole lot different, and a whole lot more powerful, than the embedded systems I stared with in the early 1980s. Everything about the Jetson Nano is incredibly advanced from the systems available in the 1980s, starting with the 64-bit quad core ARM processor to the 128 core nVidia graphics co-processor being used for machine learning. And all for a mere $99. And I mean that. The kind of processing power and hardware resources on this board would have ranged from outlandishly expensive to impossible to obtain.

The operating system that is available with this board, a targeted version of open source Ubuntu 18.04 LTS compiled for the ARM Cortex-A57, would have cost additional thousands and been closed source with an NDA to sign on top of that.

This $99 board is a remarkable bargain of a computer. I’ve read the reviews of frustrated users who gave it one star talk about how difficult it to set up and operate. So far my experience has been nearly 100% trouble free. I’ve had a few minor bumps, but it’s been after getting the OS up and running and configuring the system. Experiences so far with this board have been as satisfying, if more so, than all my experiences with the Raspberry Pi from 2 to 4.

Now that I’m “retired” I’ll be dabbling in the uses for this board, as well as with all the other little bits and bobs I’ve been collecting now for some number of years. I’ll be able to sit back and move at my own speed without having to put it aside because I needed to go to sleep and then into work the next morning. I’m an inveterate tinkerer, and Jetson Nano is the ultimate tinkerer’s tool and toy.