Persistent /dev/tty* names for GPS and Scanse Sweep

This details for this post are stolen from here; I’ve just tweaked it into my context.

The problem it solves is that both GPS and Sweep are USB UART /dev/ttyUSB? devices, and which is which is indeterminate and will change between boots.  The stolen solution below sets up a symlink to each device based upon the device attributes such that the code only ever refers the symlink i.e. ttySWEEP and ttyGPS rather than trying to guess the correct /dev/ttyUSB? underlying these symlinks.  I’ll hand you over now to my edition of the original author’s post:

Persistent names for usb-serial devices

I own a bunch of devices that appear as /dev/ttyUSB? in the system e.g. GPS and Scanse Sweep.  As I plug them in and pull them out from the USB ports, they get names like /dev/ttyUSB0 or ttyUSB1. Sadly the device names are not persistent — whether the Sweep pops up as /dev/ttyUSB0 or /dev/ttyUSB1 depends on the order in which are the devices discovered by the kernel. That makes things difficult — it usually requires a trial and error approach to find out what the hell is the GPS board’s tty name this time.

Wouldn’t it be nice to have persistent, descriptive device name for each of these toys? Like /dev/ttyGPS and /dev/ttySWEEP?

usb-serial devices

To distinguish between them we need some other unique identifier — in this case a vendor, product and serial number. These are the messages recorded at the end of /var/log/messages when Sweep (for example) is plugged in:

May 13 06:22:27 general kernel: [ 30.629485] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
May 13 06:22:27 general kernel: [ 30.756984] usb 1-1.4: New USB device found, idVendor=0403, idProduct=6015
May 13 06:22:27 general kernel: [ 30.757006] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 13 06:22:27 general kernel: [ 30.757019] usb 1-1.4: Product: FT230X Basic UART
May 13 06:22:27 general kernel: [ 30.757031] usb 1-1.4: Manufacturer: FTDI
May 13 06:22:27 general kernel: [ 30.757044] usb 1-1.4: SerialNumber: DO004VY5

UDEV rules

Now with the list of identifiers in hand let’s create a UDEV ruleset that’ll make a nice symbolic link for each of these devices. UDEV rules are usually scattered into many files in /etc/udev/rules.d. Create a new file called 99-usb-serial.rules and put the following lines in there:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="011806AE", SYMLINK+="ttyGPS"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="DO004VY5", SYMLINK+="ttySWEEP"

By now it should be obvious what these lines mean. Perhaps just a note for the last entry on each line — SYMLINK+=”ttySWEEP” means that UDEV should create a symlink /dev/ttySWEEP pointing to the actual /dev/ttyUSB* device. In other words the device names will continue to be assigned ad-hoc but the symbolic links will always point to the right device node.

Right back to me – this is a preemptive strike for when I add the Scanse Sweep to Hermione’s existing GPS.  However, that’s not going to happen until the Garmin LiDAR-Lite stops f’ing up the I2C (again), and I’ve tested all the varients of the GPS flight plan code.

Who broke my WAP?

In the previous post, I’d reported that a single hostpad now worked with both the RealTek and Broadcom drivers.  I’m sure I tested this otherwise I wouldn’t have said it, yet one day later, my WAP stopped working with both WiFi dongles; my iPad can not longer connect to Zoe.  Layer 2 MAC connection are working fine with either WiFi dongle, but Layer 3 IP connections no longer connect.  Until I’ve resolved this, all testing of the camera motion has stalled.

As a result blogging is likely to stall for a while, rather than me blogging frustrated swearing online!

Super duper WiFi dongles

I have a range of WiFi dongles I use with my various RPi projects, which I thought I’d share as my choices have evolved as my requirements got more refined.

First off is the Edimax Nano dongle – an absolute cracker – tiny, yet supports soft AP (WAP).  The only reason I moved on from here is the drone needs 360 degrees line of sight meaning I wanted a dongle with antenna to achieve better reach and signal strength.

That led me to these Edimax EW-7612UAn V2 dongles.  They support soft AP (WAP) although I didn’t have that requirement yet.  They worked great, until I realized that when in flight, even with the antenna, the signal would be poor due to its position on the drone blocking line of sight to the controller.  It also suffered during the couple of gravel crashes the drone took.  So I needed a detachable antenna that I could attach between the drones legs.

Which brought me to the EDUP range – my first purchase was the EP-MS150N.  A cracking dongle with a small body, small USB connector, 150m range and detatchable antenna allowing for a separate wired antenna.  Lovely jubbly – except they seemed to vanish from Amazon and ebay shortly after I found them (partly my fault), and they don’t support soft AP / WAP.  So when I came to setting up my test WAP, these didn’t work.

On the plus side that did lead me to the EDUP site and to the EP-MS15003 – a cracking dongle – like the MS150N but double the range and with soft AP support.  But unavailable outside of China / HongKong – shame.

Which finally led me to the EDUP EP-MS1537 – also 300m range, soft AP support, and available on ebay (from HongKong), so I ordered a couple and they’re on there way now  from China.

But I’m impatient, and liked the white colouring of the EP-MS15003, it’s smaller size and cropped USB plug, so carried on grubbing around on google and found these guys in Hong Kong stocking the EP-MS15003, and offering DHL delivery at a sensible price meaning delivery within a week rather than a month.  Sorted!

One week later, it’s arrived and installed and running the drone WAP like a dream.

P.S. All the above dongles use the Realtek chipset, so, where soft AP is supported, can be used as a WAP using these instructions if you need a bridge to the internet, or mine, if you want your WAP to be in a completely isolated secure network like I want for the drone.