It turned out to be a small Google challenge to find a working method for running the Dropbox daemon on an Ubuntu 15.04 server as systemd service. Some sites propose to schedule the dropboxd as cron job. Other sites propose an Upstart script, which was abandoned by Ubuntu this year and replaced by systemd. Then there is the proposed solution to add a script as /etc/init.d/dropbox, which does appear to work at first and then exits at random. Potatoes. Potatos. After the break what I found to be the solution.
I have been struggling to get my HackRF One working again on a new laptop with the latest Ubuntu release. Although being detected as USB device, the hackrf_info utility continued to stop working with the following error:
Found HackRF board 0:
hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000)
Repeatedly starting hackrf_info resulted in a proper response on all occasions except for the first call. The HackRF One was also not functional in other programs. Info from various mailing lists seemed to point to the recentlt introduced hackrf kernel module. However, unloading this module or adding it to a blacklist did not bring a solution for my case. Eventually, it turned out that the firmware of the HackRF does not support USB suspend. All that was needed was to add the USB device ID to a blacklist (/etc/default/tlp) and start TLP again as superuser:
A similar solutions exist in case laptop-mode-tools is used: [Hackrf-dev] HackRF, USB Autosuspend, etc.
I have an HP LaserJet 1320 printer connected to an HP ew2500 JetDirect network interface. Despite the uniform branding, printing from my Ubuntu laptop is too frequently a horrendous experience. Simple text documents typically work well with the standard Postscript drivers, but do not attempt anything beyond that. The outcome of printing a PDF file with graphics is typically the entire content of the paper tray filled with apparently random ASCII characters. How to simply install a printer and get your stuff on paper: LPR, IPP, IPPS, DNS-SD, HTTP, HTTPS, AppSocket:9100, CUPS, HPLIP, PS, PCL3, PCl4, PCL5, PCL6 … WTF! It took me twice quite some time to get the printer working properly, both times finally using a script David Everly hosted back in 2006. Since the original link (http://users.adelphia.net/~david.everly/ppd/hplj1320.sh) no longer works, but the script still does, I will host it here for future use: hplj1320.tar. The produced .PPD file is used with an Appsocket/HP JetDirect connection. Make sure the available printer memory is set in the Installable Options tab of the Printer Properties. Let’s hope manufacturers of printers some day see the benefits of standardization and start to deliver products that simply work … including on Linux.
The Digilent Inc. “Embedded Linux® Hands-on Tutorial for the ZYBO” is available from the Digilent website in PDF format (revision July 17, 2014). Another version of the tutorial is available on instructables.com. The tutorial attempts to get you through quite some steps. A little extra help is sometimes needed to have success. This post will document my findings for future use.
The notes below have been made while going through the tutorial with Xilinx Vivado 2014.4 on an Ubuntu 14.10 64-bit install. The Xilinx SDK is required as part of the Vivado package. Note that both Vivado and the SDK have dedicated settings files (e.g. settings64.sh), which need to be sourced both to set the required environment variables. Continue reading
Several sites are using the TilePic image format to show sections of a larger image. The TilePic file format contains the image data for a limited number of resolutions (zoom levels) and all image parts (tiles) have the same dimensions. The first level contains the full image scaled to a single tile. The second level could contain 4 tiles of the same size, each containing a quarter of the image data at twice the resolution of the first level. The third level then contains 4 tiles for each tile of the second level, resulting in a total of 16 tiles for the full image. The advantage of the TilePic format is that the client only needs to download the specific tiles for the shown part of the image from the level with the correct resolution. The websites usually provide zoom and scroll functions to magnify a part of the image.
Recently I have ordered a FT2232HQ mini-module from the webshop of Future Technology Devices Ltd. for use in an ongoing project with a Xilinx Spartan FPGA. In addition, I ordered a DLP-TH1b data acquisition module as a working application of a FTDI USB UART to play around with. Unfortunately, the source code for Linux systems on the website of DLP Design did not work at all. Opening the black sensor box revealed a Sensirion SHT11 humidity and temperature sensor. The source code has been changed a little using the datasheet of this device and the D2xx programmer’s guide of FTDI. My version is available for download using this link: dlp_th1b.tar.gz.
Several sites are using the Tilepic image format to show sections of a larger image. The Tilepic file format contains the image data for a limited number of resolutions (levels) and all image parts (tiles) have the same dimensions. The first level contains the full image scaled to a single tile. The second level could contain 4 tiles of the same size, each containing a quarter of the image data at twice the resolution of the first level. The third level then contains 4 tiles for each tile of the second level, resulting in a total of 16 tiles for the full image. The advantage of the Tilepic format is that the client only needs to download the specific tiles for the shown part of the image from the level with the correct resolution. The websites usually provide zoom and scroll functions to magnify a part of the image.
Downloading the high-resolution image from the Tilepic file requires some knowledge on the location of the file on the server. This information can be found in the source code of the webpage and may for example be /photo/tilepic/image.tjp. The following script will download all tiles from all levels of the Tilepic image defined by $file.