• Added USB-C adapter / bridge

    CarbonCycle • 11/19/2020 at 00:20 • 0 comments

    Updated the CircuitPython repo to include a new option for this sensor.   The sensor does not output ASCII over serial, rather it is binary data.  This can lead to discomfort for some users who would rather have formatted ASCII that can be immediately consumed in a terminal or parsed by a program.    To address this use-case, I selected a device that is inexpensive ($5) yet has enough resources to host a CircuitPython interpreter and space left over to perform the binary to ASCII conversion.    A user may customize the python code to their desired behavior, including fan management.

    A bonus ( for me ) is the USB-C port that is native on my MacPro.

    XIAO CircuitPython code

  • Finding the same device consistently

    CarbonCycle • 10/07/2018 at 04:09 • 0 comments

    When you plug a USB device in it can be enumerated to different device names by the operating system.  To fix this problem for this sensor on linux, I changed attributes that make the connection unique.

    First - find the VID and PID for the USB device:

    pi@GUIdev:~ $ lsusb
    Bus 001 Device 008: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
    Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
    Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    In this case the Vendor ID is 10c4   The Product ID is ea60

    Since I changed the serial number field - this will be unique.

    pi@GUIdev:~ $ udevadm info --name=/dev/ttyUSB0 --attribute-walk  | grep serial
        SUBSYSTEMS=="usb-serial"
        ATTRS{serial}=="ZH03B180904"
        ATTRS{serial}=="3f980000.usb"



    Now I have an attribute to tell udev what to do.  I create a file in /etc/udev/rules.d with a name like "99-dustsensor.rules".  In that file I tell udev what device name to create when it sees this device plugged in:

    SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="ZH03B180904" SYMLINK+="dust-sensor"

    To test the new rule:

    pi@GUIdev:/dev $  sudo udevadm trigger

    pi@GUIdev:/dev $ ls -al dust-sensor

    lrwxrwxrwx 1 root root 7 Oct  6 21:04 dust-sensor -> ttyUSB0

    Now, every time I plug in my dust sensor, it shows up at

    /dev/dust-sensor

  • Oops. Ran out of serial ports on the Pi.

    CarbonCycle • 10/04/2018 at 05:54 • 0 comments

    My favorite sensor platform is Mycodo, that runs on the Raspberry Pi.  And when you use sensors on the Pi, you run out of serial ports quickly.  And I'm coming across more and more sensors that work best via the serial port.  So I have a simple modification of a common USB-UART bridge that solves my serial port count problem.

    I chose the CP2102 because one nagging problem that does come up with USB devices is having a consistent device name to reference.  Every time you plug in a device, you may not end up with the same tty port.  Random port assignments take the joy out of plug and play.

    The way to fix the random port assignment is to have something in the USB attributes that is unique to that device.  When you purchase these boards, they all have the same information.  You really don't want to change VID and PID because then the driver will note recognize the device and once again, sad face. It doesn't plug and play.

    Fortunately Silicon Labs, the maker for CP2102 has a tool they offer that allows you to modify some of the fields in the EEPROM USB attributes like power consumed, Product Name and Serial Number.  This allows modifications on the host udev  configuration so that the USB device ends up with a consistent device name.

    The other attribute you can set is power consumed in milliamperes. This is important for power budget calculations done by host devices and some powered hubs.  If the onboard 3.3v is used, you are limited to less than 100mA in any case.  I usually specify 20% above what I have measured as worst case power draw for the attached sensor device.