New USB Host library for Teensy 4.x

J

jmarsh

Well-known member
I've written a new USB Host support library for Teensy 4.x boards: https://github.com/A-Dunstan/teensy4_usbhost

Key features:
- dynamic driver instantiation, e.g. can support any number of hubs or other devices since driver objects can be created as needed
- transparent support for using any type of memory (DTCM/OCRAM/EXTMEM/SDRAM), all cache operations are taken care of
- supports both synchronous and asynchronous transfers (using std::function callbacks)
- makes an effort to return errors using errno
- fully supports isochronous endpoints / transfers (both full and high speed). These are commonly used by devices that deliver realtime data such as audio input/output DACs, or webcams:
WtDhRYN.jpeg


It makes use of a threading library (which is a modified version of AtomThreads) which is written to be as minimally intrusive as possible; you can use the synchronization objects it provides if you want, but otherwise its existence can be ignored. It's a submodule of the git repository so do a "submodule init" after cloning it.

For the time being the only available documentation is in the examples and the included drivers; there's still a lot of code to be cleaned up before it starts being documented properly.
 
Last edited:
Exellent work:D Tried the USBHost storage "basic.ino" on a FAT32 formatted USB stick through a HUB. Result:
Code: 
Found a FAT32 partition.
Checking free space... Done.
Bytes free: 30812176384 of 30927306752 (99%)
--- FILE LISTING BEGIN ---
DIRECTORY: /
Modified: 07:21:22 Mar 27 2021    Size: 10845    Name: dfs_ext.c
Modified: 07:21:22 Mar 27 2021    Size: 1147    Name: dfs_ext.h
Modified: 17:47:14 Oct 15 2023    Size: 2127672    Name: dosemu_1.4.0.7+20130105+b028d3f-2build1_amd64.deb
Modified: 17:05:52 Nov 7 2023    Size: 45123    Name: fail.jpg
Modified: 20:39:04 Oct 29 2023    Size: 2379894    Name: ff15.zip
Modified: 20:39:22 Oct 29 2023    Size: 8151962    Name: ffsample.zip
Modified: 20:23:44 Feb 6 2024    Size: 9430734    Name: fltk-master.zip
Modified: 17:41:14 Oct 28 2023    Size: 16688    Name: fontcnvt
Modified: 17:41:02 Oct 28 2023    Size: 955    Name: fontcnvt.c
Modified: 16:15:22 Dec 10 2023    Size: 92613306    Name: FreeRTOSv202212.01.zip
Modified: 19:15:56 Feb 4 2024    Size: 946    Name: libpng3_1.2.54-1ubuntu1.1+1~ppa0~jammy0_amd64.deb
Modified: 19:17:28 Feb 4 2024    Size: 116466    Name: libpng12-0_1.2.54-1ubuntu1_amd64.deb
Modified: 19:11:32 Feb 4 2024    Size: 19036    Name: libpng_1.2.54-1ubuntu1.1+1~ppa0~jammy0.debian.tar.xz
Modified: 00:21:22 May 16 2022    Size: 4096    Name: sansurf.fnt
Modified: 17:41:22 Oct 28 2023    Size: 22050    Name: sansurf.h
Modified: 07:21:22 Mar 27 2021    Size: 1211    Name: SConscript
--- FILE LISTING COMPLETE ---

USB Drive may now be removed, press return to scan again
Can't wait to test with all of the other features...

EDIT: Did anybody mention CD/DVD usage:
Code: 
Found 1 USB Storage devices
Found a USB Mass Storage device 0x20206ce0, has 1 logical units
USB 0x20206ce0:0 Vendor: PBDS, Product: CDRWDVD DH-48C2S
USB 0x20206ce0:0 LBA count: 23340, LBA size: 2048
Found 1 partitions
USB 0x20206ce0:0 Partition 0: Type ISO9660, start 0 - end 23187

Press return to search again
Again, Nice work...
 
Last edited:
Looks like fun.
Who knows, maybe it can replace the USBHost_t36... I always wanted to use something like threads, but...

Note: If I try to clone it using Windows github desktop it gives me a real strange error message.
Maybe the submodule... Will investigate later.

But looks like great stuff!
 
wwatson said:
EDIT: Did anybody mention CD/DVD usage:
Code: 
Found 1 USB Storage devices
Found a USB Mass Storage device 0x20206ce0, has 1 logical units
USB 0x20206ce0:0 Vendor: PBDS, Product: CDRWDVD DH-48C2S
USB 0x20206ce0:0 LBA count: 23340, LBA size: 2048
Found 1 partitions
USB 0x20206ce0:0 Partition 0: Type ISO9660, start 0 - end 23187

Press return to search again
Click to expand...
The CD stuff is a bit of fun... when I get around to it I want to write an ISO9660 filesystem library, so the files can actually be accessed. But in the meantime there's an example that can use CD drives to play audio, and if they have an SPDIF port on the back you can connect it to the Teensy to hear it over USB. The speedtest example can also do digital audio extraction, although it's very basic and doesn't do any verification like a proper extraction app should.
 
KurtE said:
Looks like fun.
Who knows, maybe it can replace the USBHost_t36... I always wanted to use something like threads, but...

Note: If I try to clone it using Windows github desktop it gives me a real strange error message.
Maybe the submodule... Will investigate later.

But looks like great stuff!
Click to expand...
Something you might want to look at is the jpg_server example, for the camera stuff you were working on - it uses QNEthernet to set up a basic webserver to stream continuous jpeg images. You could reuse the EthernetClient related functions to stream images from an OV2640 (or other camera that does mjpg format).
 
jmarsh said:
I've written a new USB Host support library for Teensy 4.x boards: https://github.com/A-Dunstan/teensy4_usbhost

Key features:
- dynamic driver instantiation, e.g. can support any number of hubs or other devices since driver objects can be created as needed
- transparent support for using any type of memory (DTCM/OCRAM/EXTMEM/SDRAM), all cache operations are taken care of
- supports both synchronous and asynchronous transfers (using std::function callbacks)
- makes an effort to return errors using errno
- fully supports isochronous endpoints / transfers (both full and high speed). These are commonly used by devices that deliver realtime data such as audio input/output DACs, or webcams:
WtDhRYN.jpeg


It makes use of a threading library (which is a modified version of AtomThreads) which is written to be as minimally intrusive as possible; you can use the synchronization objects it provides if you want, but otherwise its existence can be ignored. It's a submodule of the git repository so do a "submodule init" after cloning it.

For the time being the only available documentation is in the examples and the included drivers; there's still a lot of code to be cleaned up before it starts being documented properly.
Click to expand...
This library may bridge one of the great chasms I've been facing in developing USB_UVC cameras for the Teensy: The lack of host support for Isochronous reception from UVC cameras. I've managed to develop drivers for some FLIR thermal imaging cameras only because they use bulk endpoints for image data transfer. All the other cameras I've tested want isochronous endpoints. This will be another continuing education project to keep me busy for the next few months! (As if the USB probe/commit protocols weren't enough to keep me busy!)

I applaud your efforts and look forward to exploring the code.
 
Funnily enough, the few cameras I've tested with work fine without even doing any probing/committing... if you just activate the alternate interface without doing any setup they're happy to deliver packets from the streaming endpoint using the default format. That also bypasses activating their "privacy" LED that is meant to indicate when the camera is active...
 
KurtE said:
Note: If I try to clone it using Windows github desktop it gives me a real strange error message.
Maybe the submodule... Will investigate later.
Click to expand...
I tested cloning with github desktop just now and I didn't get any error message, it just stalled indefinitely at the submodule. So I filed an issue.
You can clone the TeensyAtomThreads library by itself: https://github.com/A-Dunstan/TeensyAtomThreads
Luckily I included a check in the usb library that will look for it as an external library if the submodule in the local tree isn't present:
Code: 
// prefer submodule version if it is present
#if defined __has_include && __has_include("TeensyAtomThreads/TeensyAtomThreads.h")
#include "TeensyAtomThreads/TeensyAtomThreads.h"
#else
#include <TeensyAtomThreads.h>
#endif
 
When I added the submodule I used the ssh (git@) URL instead of the web (HTTPS: ) URL. Changing it to https has let github desktop check out the repo without any issues.
 
Last edited:
A while ago I bought a $5 USB wifi/bluetooth adapter from aliexpress. They seem to be very plentiful, advertised under a few different brands but usually including a mention of AX900, Wifi6 and Bluetooth 5.3 or 5.4. I thought it would be a realtek chipset but it turns out it's from AIC, although from what I've seen the hardware's original source may be Ceva/RivieraWaves. There doesn't seem to be any public datasheets available but there are several third-party maintained out-of-tree linux drivers based on an SDK from AIC, including firmware that seems to still be getting regular updates.

Uploading firmware to initialize a USB device isn't out of the ordinary but this one has a few tricks up its sleeve. To begin with here's how the device presents itself when you first plug it in (debug output from my USB Host library):
Code: 
!!! Enumeration begin !!!
Port 0:0 bDeviceClass 00 bDeviceSubClass 00 bDeviceProtocol 00 bMaxPacketSize 64
New Endpoint<0x20204680> type 0
New Device<0x20204640>: address 1, port 0, hub 0, speed 2, control_packet_size 64
Port 0:0 successfully set address 1
Device<0x20204640> control callback 0x20204b08 result 4
Device<0x20204640> number of supported languages: 1
Device<0x20204640> using language 0409 for strings
Device<0x20204640> control callback 0x20204c68 result 18
Device<0x20204640> Device Descriptor 0x20204400:
   bcdUSB 0200
   bDeviceClass 00
   bDeviceSubClass 00
   bDeviceProtocol 00
   idVendor A69C
   idProduct 5721
   bcdDevice 0200
   iManufacturer 1
   iProduct 2
   iSerialNumber 3
   bNumConfigurations 1
Device<0x20204640> control callback 0x20204b08 result 16
Device<0x20204640> string index 1: aicsemi
Device<0x20204640> control callback 0x20204ee8 result 16
Device<0x20204640> string index 2: Aic MSC
Device<0x20204640> control callback 0x20205208 result 18
Device<0x20204640> string index 3: 20200203
Device<0x20204640> control callback 0x202054a8 result 9
Device<0x20204640> control callback 0x20204b08 result 32
Device<0x20204640> Configuration 1:
    wTotalLength 32
    bNumInterfaces 1
    iConfiguration 0
    bmAttributes 80
    bMaxPower 50
Interface 0, Length 23:
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass 08
    bInterfaceSubClass 06
    bInterfaceProtocol 50
    iInterface 4
     Endpoint 02:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 82:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
Interface 0 is a "standard" looking device - the problem is it's a mass storage (disk) device, which is not at all what we want. It seems there's an internal 4MB flash chip that is preloaded with a FAT filesystem containing windows drivers - not particularly useful in this case. How do we get this device to stop pretending it's a disk? Write a custom driver that sends an eject command. The moment the device receives the eject request, it disconnects and reconnects as something new:
Code: 
!!! Enumeration begin !!!
Port 0:0 bDeviceClass 00 bDeviceSubClass 00 bDeviceProtocol 00 bMaxPacketSize 64
New Endpoint<0x20204640> type 0
New Device<0x20204600>: address 1, port 0, hub 0, speed 2, control_packet_size 64
Port 0:0 successfully set address 1
Device<0x20204600> control callback 0x20204ac8 result 4
Device<0x20204600> number of supported languages: 1
Device<0x20204600> using language 0409 for strings
Device<0x20204600> control callback 0x20204c28 result 18
Device<0x20204600> Device Descriptor 0x20204560:
   bcdUSB 0200
   bDeviceClass 00
   bDeviceSubClass 00
   bDeviceProtocol 00
   idVendor A69C
   idProduct 8D80
   bcdDevice 0100
   iManufacturer 1
   iProduct 2
   iSerialNumber 3
   bNumConfigurations 1
Device<0x20204600> control callback 0x20204d88 result 16
Device<0x20204600> string index 1: aicsemi
Device<0x20204600> control callback 0x202050e8 result 18
Device<0x20204600> string index 2: AIC Wlan
Device<0x20204600> control callback 0x20205368 result 18
Device<0x20204600> string index 3: 20220103
Device<0x20204600> control callback 0x20205608 result 9
Device<0x20204600> control callback 0x20204ac8 result 32
Device<0x20204600> Configuration 1:
    wTotalLength 32
    bNumInterfaces 1
    iConfiguration 0
    bmAttributes A0
    bMaxPower 250
Interface 0, Length 23:
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass FF
    bInterfaceSubClass FF
    bInterfaceProtocol FF
    iInterface 0
     Endpoint 01:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 82:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
Now the PID (idProduct) has changed to 8D80 and we've got a vendor specific interface with two bulk endpoints. This is a lot more typical of something that expects a firmware upload. So I dug through the available source code and wrote my own uploader, and now once again the device disconnects and reconnects as something new (when the firmware upload complete). This time it has a completely new VID as well as PID:
Code: 
!!! Enumeration begin !!!
Port 0:0 bDeviceClass EF bDeviceSubClass 02 bDeviceProtocol 01 bMaxPacketSize 64
New Endpoint<0x20204640> type 0
New Device<0x20204600>: address 1, port 0, hub 0, speed 2, control_packet_size 64
Port 0:0 successfully set address 1
Device<0x20204600> control callback 0x20204ac8 result 4
Device<0x20204600> number of supported languages: 1
Device<0x20204600> using language 0409 for strings
Device<0x20204600> control callback 0x20204c28 result 18
Device<0x20204600> Device Descriptor 0x20204560:
   bcdUSB 0200
   bDeviceClass EF
   bDeviceSubClass 02
   bDeviceProtocol 01
   idVendor 368B
   idProduct 8D81
   bcdDevice 0100
   iManufacturer 1
   iProduct 2
   iSerialNumber 3
   bNumConfigurations 1
Device<0x20204600> control callback 0x20204d88 result 16
Device<0x20204600> string index 1: AICSemi
Device<0x20204600> control callback 0x202050e8 result 24
Device<0x20204600> string index 2: AIC 8800D80
Device<0x20204600> control callback 0x20205368 result 18
Device<0x20204600> string index 3: 20220103
Device<0x20204600> control callback 0x202054c8 result 9
Device<0x20204600> control callback 0x20204bc8 result 222
Device<0x20204600> Configuration 1:
    wTotalLength 222
    bNumInterfaces 3
    iConfiguration 0
    bmAttributes A0
    bMaxPower 250
Interface 0, Length 30:
    bAlternateSetting 0
    bNumEndpoints 3
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
     Endpoint 83:
        bmAttributes 03
        wMaxPacketSize 0040
        bInterval 4
     Endpoint 84:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 04:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
Interface 1, Length 138:
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0000
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0000
        bInterval 4
Interface 1, Length 23:
    bAlternateSetting 1
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0009
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0009
        bInterval 4
Interface 1, Length 23:
    bAlternateSetting 2
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0011
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0011
        bInterval 4
Interface 1, Length 23:
    bAlternateSetting 3
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0019
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0019
        bInterval 4
Interface 1, Length 23:
    bAlternateSetting 4
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0021
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0021
        bInterval 4
Interface 1, Length 23:
    bAlternateSetting 5
    bNumEndpoints 2
    bInterfaceClass E0
    bInterfaceSubClass 01
    bInterfaceProtocol 01
    iInterface 6
String 6 was already present ("")
     Endpoint 85:
        bmAttributes 01
        wMaxPacketSize 0031
        bInterval 4
     Endpoint 05:
        bmAttributes 01
        wMaxPacketSize 0031
        bInterval 4
Interface 2, Length 37:
    bAlternateSetting 0
    bNumEndpoints 4
    bInterfaceClass FF
    bInterfaceSubClass FF
    bInterfaceProtocol FF
    iInterface 7
     Endpoint 01:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 81:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 02:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
     Endpoint 82:
        bmAttributes 02
        wMaxPacketSize 0200
        bInterval 0
Device<0x20204600> control callback 0x202050e8 result 20
Device<0x20204600> string index 6: Bluetooth
Device<0x20204600> control callback 0x20205368 result 10
Device<0x20204600> string index 7: Wlan
Now we're in business; interface 0 looks like a standard USB Bluetooth HCI, interface 1 (with all its alternate settings) are the bluetooth isochronous endpoints and interface 2 is the (vendor specific) wifi/wlan interface. For now I'm ignoring the last one (because writing a wifi driver is a lot of work, even with a reference manual), but testing that the bluetooth HCI is working by reading the host's BD address is relatively simple:
Code: 
HCI interface startup 83 84 04
HCI event response: 0
send read_bd_addr result: 3
HCI event response: 12
BD ADDR: 90:DE:80:17:EF:FE
Success! We have turned this USB chimera into a usable bluetooth host.
 
Wifi work is progressing... I can scan 2.4GHz and 5GHz channels and probe access points:
Code: 
Device<0x20207300> activate configuration 1(-1)
Device<0x20207300> activate interface 00 altSetting 00
New Endpoint<0x20207900> type 3
New Endpoint<0x20207c00> type 2
New Endpoint<0x20207180> type 2
Device<0x20207300> activate interface 01 altSetting 00
activate_endpoint: ISO endpoint has wMaxPacketSize==0, skipping
activate_endpoint: ISO endpoint has wMaxPacketSize==0, skipping
Device<0x20207300> activate interface 02 altSetting 00
New Endpoint<0x20208000> type 2
New Endpoint<0x20205280> type 2
New Endpoint<0x20205400> type 2
New Endpoint<0x20205580> type 2
AIC8800D81 attach 81 01 82 02
Endpoint<0x20207900> interval 8 offset 7 stime 5 ctime 0 s_mask 80 c_mask 00
Device<0x20207300> control callback 0x20204cc8 result 0
Device<0x20207300> new configuration set: 01
Device<0x20207300> activate configuration 1(1)
Device<0x20207300> control callback 0x20204e28 result 0
New interface set: interface 0, altSetting 0
Device<0x20207300> activate interface 00 altSetting 00
RX_THREAD begin 0x202090e0
Device<0x20207300> control callback 0x20207ee8 result 0
New interface set: interface 1, altSetting 0
Device<0x20207300> activate interface 01 altSetting 00
Device<0x20207300> control callback 0x202050e8 result 0
New interface set: interface 2, altSetting 0
Device<0x20207300> activate interface 02 altSetting 00
chip_id=7, chip_mcu_id = 1
is 5g support: 1
Firmware Version: la Dec 05 2025 19:45:42 - g586bc1e8
RF_CALIB: rx_gain_2g_addr 00175A64, rx_gain_5g_addr 00175CF8, txgain_24g_addr 0017683C, txgain_5g_addr 001769C4
MAC Address: 90:DE:80:17:EF:FD
MM VERSION:
    LMAC: 06090101
    MACHW: 0002FDFB 00014047
    PHY: 5EE24111 01020000
    FEAT: 01E877D7
    MAX_STA: 32
    MAX_VIF: 4
Interface added, index #0
scan start response: 1
init done
Scan Result: D4:31:27:C0:79:C4    SSID: "                      Johns Wifi"    freq: 2412    RSSI: -78
Scan Result: 6A:20:51:2D:35:11    SSID: "                                "    freq: 2412    RSSI: -79
Scan Result: 6A:20:51:2D:35:12    SSID: "                                "    freq: 2412    RSSI: -80
Scan Result: 6A:20:51:2D:35:15    SSID: "                     WiFi-2D3514"    freq: 2412    RSSI: -76
Channel Survey: freq 2412MHz    noise -77dBm    busy time 10 / 50ms
Channel Survey: freq 2417MHz    noise -86dBm    busy time 0 / 30ms
Scan Result: C8:D7:19:01:76:33    SSID: "                           DLINK"    freq: 2422    RSSI: -59
Channel Survey: freq 2422MHz    noise -84dBm    busy time 3 / 30ms
Channel Survey: freq 2427MHz    noise -94dBm    busy time 0 / 30ms
Channel Survey: freq 2432MHz    noise -94dBm    busy time 0 / 30ms
Scan Result: D0:DB:B7:B8:EA:08    SSID: "                    NetComm 3922"    freq: 2437    RSSI: -78
Channel Survey: freq 2437MHz    noise -95dBm    busy time 3 / 50ms
Channel Survey: freq 2442MHz    noise -94dBm    busy time 0 / 30ms
Channel Survey: freq 2447MHz    noise -94dBm    busy time 0 / 30ms
Channel Survey: freq 2452MHz    noise -93dBm    busy time 0 / 30ms
Channel Survey: freq 2457MHz    noise -86dBm    busy time 1 / 30ms
Channel Survey: freq 2462MHz    noise -43dBm    busy time 0 / 50ms
Scan Result: 10:2C:B1:87:F5:99    SSID: "                                "    freq: 2467    RSSI: -77
Channel Survey: freq 2467MHz    noise -87dBm    busy time 2 / 30ms
Channel Survey: freq 2472MHz    noise -93dBm    busy time 0 / 50ms
Channel Survey: freq 2484MHz    noise -93dBm    busy time 0 / 30ms
Channel Survey: freq 5180MHz    noise -94dBm    busy time 2 / 50ms
Channel Survey: freq 5200MHz    noise -89dBm    busy time 0 / 30ms
Scan Result: C8:D7:19:01:76:35    SSID: "               Linksys06953_5GHz"    freq: 5220    RSSI: -56
Channel Survey: freq 5220MHz    noise -89dBm    busy time 0 / 50ms
Channel Survey: freq 5240MHz    noise -93dBm    busy time 0 / 30ms
Channel Survey: freq 5260MHz    noise -94dBm    busy time 0 / 30ms
Channel Survey: freq 5280MHz    noise -81dBm    busy time 0 / 30ms
Channel Survey: freq 5300MHz    noise -92dBm    busy time 0 / 30ms
Channel Survey: freq 5320MHz    noise -91dBm    busy time 0 / 30ms
Channel Survey: freq 5500MHz    noise -89dBm    busy time 0 / 30ms
Channel Survey: freq 5520MHz    noise -95dBm    busy time 0 / 30ms
Channel Survey: freq 5540MHz    noise -92dBm    busy time 0 / 30ms
Channel Survey: freq 5560MHz    noise -97dBm    busy time 0 / 30ms
Scan Result: 90:F8:91:DF:DC:CB    SSID: "                          DLINK5"    freq: 5500    RSSI: -89
Channel Survey: freq 5580MHz    noise -89dBm    busy time 0 / 30ms
Channel Survey: freq 5600MHz    noise -96dBm    busy time 0 / 30ms
Channel Survey: freq 5620MHz    noise -95dBm    busy time 0 / 30ms
Channel Survey: freq 5640MHz    noise -95dBm    busy time 0 / 30ms
Channel Survey: freq 5660MHz    noise -95dBm    busy time 0 / 30ms
Channel Survey: freq 5680MHz    noise -100dBm    busy time 0 / 30ms
Channel Survey: freq 5700MHz    noise -100dBm    busy time 0 / 30ms
Channel Survey: freq 5720MHz    noise -96dBm    busy time 0 / 30ms
Channel Survey: freq 5745MHz    noise -96dBm    busy time 0 / 30ms
Channel Survey: freq 5765MHz    noise -94dBm    busy time 1 / 50ms
Scan Result: D0:DB:B7:B8:EA:09    SSID: "                    NetComm 3922"    freq: 5785    RSSI: -91
Channel Survey: freq 5785MHz    noise -93dBm    busy time 1 / 50ms
Channel Survey: freq 5805MHz    noise -95dBm    busy time 2 / 50ms
Channel Survey: freq 5825MHz    noise -95dBm    busy time 0 / 30ms
Scan on virtual interface #0 complete    status: 0    found: 10
 
Yes, UGREEN and Tenda are listed in the driver source code. I'd say that device does support bluetooth but it just isn't enabled in the windows drivers (it has a very minor quirk that makes it non-standard).
 
You must log in or register to reply here.
Back
Top