3 days of etching & programming later, the new base station was sending wunderground temperature to the LED panel & recording the 2 apartment temperatures.  It was an exciting introduction to programming a PIC as a CDC ACM device.  It's essential to plug them into a spare confuser for testing instead of the development confuser.

The mane problem is going to be collisions with 3 radios now transmitting.  Randomization of the timing is probably going to be necessary.

The PIC comes up as  ttyACM0 just like the big boys.  Write to /dev/ttyACM0 & it transmits to the radio.  Read from /dev/ttyACM0 & it receives from the radio.

Lions have always been woefully uninterested in using standards in lieu of making things work as fast as possible, whether it was making a custom EDL format for editing video instead of using a standard format, making a custom protocol instead of using the USB audio standard for recording audio.  Lions partially supported standards for storing video & audio in the beginning & eventually outsourced it all to ffmpeg which fully supported the standards.  

It was a big deal to finally follow the USB HID & CDC ACM standards in the LCD music display & weather station.  The growing number of USB projects has made it more practical to implement standards than write a new libusb program every time.

Anyone could have just bought an FTDI chip to access a chip radio from USB, but lions always wanted the flexibility & cost savings of a microcontroller.  The FTDI protocol actually has to be licensed to program a microcontroller to act like an FTDI chip.  It requires a special driver on the host, a special vendor & product ID, which may not be obvious to Linux users while Windows users have to install an FTDI driver.

The unlicensed device is the CDC ACM device.  Once all 156 bytes of configuration descriptors are properly encoded, it just passes I/O from /dev/ttyACM0 to 2 endpoints.  It's definitely faster to use libusb than the CDC ACM interface.