T3.6 USB Host - Bluetooth

[KurtE]

Bluetooth support for Teensy 3.6 Host Shield Library.

A few of us (@mjs513, @defragster, and myself) have been working to add Bluetooth support the library

Currently in the Fork/Branch: https://github.com/KurtE/USBHost_t36...WIP2-Bluetooth

Hopefully soon we will merge some of the WIP code into the main code, that gets installed when you install Teensyduino.

We are making some good progress and have some device working, including some keyboards, some Mice and some Joysticks.

<First pass to get hardware list ???>

Status	USB Type	Reference	Comment
DONGLES
Good	Bt Dongle	CSR 4.0 Bt Dongle	Tim , Kurt, Mike
0xFF Bypass Good	Bt Dongle	PANBT400 Plugable Bt 4.0 Low Energy	Tim
Connects	Bt Dongle	TechKey 4.0 EDR	Mike, Kurt
Fails	Bt Dongle	TechKey 5.0 EDR	Tim, Mike, Kurt
Connects	Bt Dongle	Kinivo BTD-400 BT 4.0 Low Energy	Mike
Connects	Bt Dongle	ZEXMTE Bluetooth USB Adapter CSR 4.0	Kurt
DEVICES
Connects	Bt M	Logitech M557 Bluetooth Mouse	Tim
USB/Unify dongle/Fails BT	Bt M	Logitech MX Anywhere 2S Wireless Mouse	Kurt
Connects	Bt M	TeckNet 2600DPI Bluetooth Wireless Mouse	Kurt
Connects	Wireless	Logitech Wireless Mouse M325	Have to Pair first with Logitech Unifying Rcvr App; Mike
Connects	Wireless	AmazonBasics Wireless Mouse	Mike
Bt **, USB Spews	PS3_Joy Bt&USB	Sony PS3 Controller	Kurt
Connects	PS3_Joy Bt&USB	DualShock 4 PS4 Controller	Mike, Kurt
Bt **, USB Spews	PS3_Joy Bt&USB	JAMSWALL PS3 Controller	Tim
Connects	PS3_Joy Bt&USB	DualShock 4 PS4 Controller	Mike
Bt **, USB Spews	PS3_Joy Bt&USB	KLNO PS39 PS3 Controller	Mike
Connects most works	Bt KBD/M/Tch	Rii i8+ BT Wireless Touchpad Keyboard	Tim
Connects most works	Bt KBD/M/Tch	Rii Mini Bluetooth Wireless Touchpad Rechargable Keyboard	Kurt
works	Bt KBD/M/Tch	Kinesis Freestyle2 Blue Wireless Bluetooth Ergonomic Keyboard	Kurt
Initial Connect	Bt KBD	Logitech Bt Multi-Device Keyboard K480	Tim
Connects	Bt	MSFT BT Keyboard 6000	Tim
Connects	Bt	Aerb Mini BT Keyboard W Mouse	Mike
Connects	USB	Extreme 3D Pro Joystick	Mike
Connects	USB	Logitech G Pro Flight X56 Rhino HOTAS	Mike
HUBS
Connects	USB	AmazonBasics 4 Port USB 3.0 Powered Hub	Has to be powered; Tim, Mike
	...
Status	USB Type	Reference	Comment

Need to Edit: above table, but so far I have had working some of the hardware:

Mouse:
Tecknet …
MSFT Sculpt Mouse (m#1497)
Logitech Mouse M557

Keyboard:
rii, and Rii i8+
logitech K400+, K480 Triple Select
MSFT Mobile 6000

Joysticks
PS3 (including a clone or two) **
PS4

** For PS3 controller it must be USB paired in advance - plug in cable to PS3 - then Bt Dongle to see non-zero BDADDR:
To initiate Bt pair - while on USB:: Hold select button and press PS button to set controller associate.

[KurtE]

EDIT: Moved the information from first post to here...

I thought I would mention, I have started to play with trying to get some Bluetooth support into the USBHost_t36 library.

I am starting off by capturing some USB host packets on a Linux machine (I have tried both RPI and UP boards)... I captured the data using the Saleae Logic Analyzer using the USB LS/FS protocol analyzer. And then I exported data both as both Control Transfer and then packets... Which both show interesting information:

Like the Control one shows data like:

USB RESET Time: 0.

USB RESET Time: 0.73058123

SETUP address: 0x00 time: 1.07142073
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0100 Descriptor=DEVICE, Index=0x00
	wIndex=0x0000
	wLength=0x0040
DATA time: 1.071503388
	<data IN packet NAKed by device. Time: 1.071506484>
	<data IN packet NAKed by device. Time: 1.0727303>
	<data IN packet NAKed by device. Time: 1.073980492>
	<data IN packet NAKed by device. Time: 1.075230622>
	<data IN packet NAKed by device. Time: 1.076481314>
	<data IN packet NAKed by device. Time: 1.077732194>
	<data IN packet NAKed by device. Time: 1.078981136>
	<data IN packet NAKed by device. Time: 1.080231266>
	<data IN packet NAKed by device. Time: 1.08149002>
Descriptor time: 1.082735942
	bLength=0x12
	bDescriptorType=0x01 DEVICE
	bcdUSB=0x0200 2.00
	bDeviceClass=0xE0 Wireless Controller
	bDeviceSubClass=0x01
	bDeviceProtocol=0x01
	bMaxPacketSize0=0x40
	idVendor=0x0A12 Vendor=Cambridge Silicon Radio, Ltd
	idProduct=0x0001
	bcdDevice=0x8891 88.91
	iManufacturer=0x00
	iProduct=0x02
	iSerialNumber=0x00
	bNumConfigurations=0x01
STATUS time: 1.08287707
	ACK

USB RESET Time: 1.08288432

SETUP address: 0x00 time: 1.181359474
	bmRequestType=0x00 Data direction=No data, Type=Standard, Recipient=Device
	bRequest=0x05 SET_ADDRESS
	wValue=0x0009 Address=0x09
	wIndex=0x0000
	wLength=0x0000
STATUS time: 1.181514874
	<status IN packet NAKed by device. Time: 1.18151795>
	ACK

SETUP address: 0x09 time: 1.201370644
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0100 Descriptor=DEVICE, Index=0x00
	wIndex=0x0000
	wLength=0x0012
DATA time: 1.201519378
	<data IN packet NAKed by device. Time: 1.201522462>
Descriptor time: 1.202748756
	bLength=0x12
	bDescriptorType=0x01 DEVICE
	bcdUSB=0x0200 2.00
	bDeviceClass=0xE0 Wireless Controller
	bDeviceSubClass=0x01
	bDeviceProtocol=0x01
	bMaxPacketSize0=0x40
	idVendor=0x0A12 Vendor=Cambridge Silicon Radio, Ltd
	idProduct=0x0001
	bcdDevice=0x8891 88.91
	iManufacturer=0x00
	iProduct=0x02 CSR8510 A10
	iSerialNumber=0x00
	bNumConfigurations=0x01
STATUS time: 1.202892308
	ACK

SETUP address: 0x09 time: 1.20307517
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0600 Descriptor=DEVICE_QUALIFIER, Index=0x00
	wIndex=0x0000
	wLength=0x000A
DATA time: 1.203141396
	<data IN packet NAKed by device. Time: 1.20314453>
	STALL

SETUP address: 0x09 time: 1.20456747
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0600 Descriptor=DEVICE_QUALIFIER, Index=0x00
	wIndex=0x0000
	wLength=0x000A
DATA time: 1.204647044
	<data IN packet NAKed by device. Time: 1.20465016>
	STALL

SETUP address: 0x09 time: 1.20605957
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0600 Descriptor=DEVICE_QUALIFIER, Index=0x00
	wIndex=0x0000
	wLength=0x000A
DATA time: 1.206141828
	<data IN packet NAKed by device. Time: 1.206144916>
	STALL

SETUP address: 0x09 time: 1.207574602
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0200 Descriptor=CONFIGURATION, Index=0x00
	wIndex=0x0000
	wLength=0x0009
DATA time: 1.207644478
	<data IN packet NAKed by device. Time: 1.207647608>
Descriptor time: 1.208874532
	bLength=0x09
	bDescriptorType=0x02 CONFIGURATION
	wTotalLength=0x00B1
	bNumInterfaces=0x02
	bConfigurationValue=0x01
	iConfiguration=0x00
	bmAttributes=0xE0 Self powered, Remote wakeup supported
	bMaxPower=0x32 100mA
STATUS time: 1.209015474
	ACK

SETUP address: 0x09 time: 1.209187438
	bmRequestType=0x80 Data direction=Device to host, Type=Standard, Recipient=Device
	bRequest=0x06 GET_DESCRIPTOR
	wValue=0x0200 Descriptor=CONFIGURATION, Index=0x00
	wIndex=0x0000
	wLength=0x00B1
DATA time: 1.20926723
	<data IN packet NAKed by device. Time: 1.209270364>
Descriptor time: 1.210499786
	bLength=0x09
	bDescriptorType=0x02 CONFIGURATION
	wTotalLength=0x00B1
	bNumInterfaces=0x02
	bConfigurationValue=0x01
	iConfiguration=0x00
	bmAttributes=0xE0 Self powered, Remote wakeup supported
	bMaxPower=0x32 100mA
Descriptor time: 1.210505786
	bLength=0x09
	bDescriptorType=0x04 INTERFACE
	bInterfaceNumber=0x00
	bAlternateSetting=0x00
	bNumEndpoints=0x03
	bInterfaceClass=0xE0 Wireless Controller
	bInterfaceSubClass=0x01
	bInterfaceProtocol=0x01
	iInterface=0x00
...
UP address: 0x09 time: 1.439796772
	bmRequestType=0x20 Data direction=Host to device, Type=Class, Recipient=Device
	bRequest=0x00 (Class request)
	wValue=0x0000
	wIndex=0x0000
	wLength=0x0004
DATA time: 1.439914692
	byte=0x45
	byte=0x0C
	byte=0x01
	byte=0x02
STATUS time: 1.44004041
	<status IN packet NAKed by device. Time: 1.440043528>
	ACK
...

So for example it shows the command packets that are sent... But does not show the Data packets that are sent/received on the other endpoints...
The Packets format shows all of that information, plus the stuff above in more cryptic format:

1.439792206000000,SETUP,0x09,0x00,,,0x13
1.439795440000000,DATA0,,,,0x20 0x00 0x00 0x00 0x00 0x00 0x04 0x00,0x2CBF
1.439803986000000,ACK,,,,,
1.439914026000000,OUT,0x09,0x00,,,0x13
1.439917258000000,DATA1,,,,0x45 0x0C 0x01 0x02,0x85AA
1.439923050000000,ACK,,,,,
1.440039746000000,IN,0x09,0x00,,,0x13
1.440042862000000,NAK,,,,,
1.440395872000000,IN,0x09,0x01,,,0x05
1.440398990000000,DATA0,,,,0x0E 0x04 0x01 0x45 0x0C 0x00,0x231A
1.440406204000000,ACK,,,,,
1.440499478000000,SOF,,,0x3A4,,0x0D
1.440895984000000,IN,0x09,0x02,,,0x16
1.440899116000000,NAK,,,,,
1.441271024000000,IN,0x09,0x00,,,0x13
1.441274118000000,DATA1,,,,,0x0000
1.441277340000000,ACK,,,,,
1.441405744000000,IN,0x09,0x01,,,0x05
1.441408868000000,NAK,,,,,
1.441420774000000,SETUP,0x09,0x00,,,0x13
1.441424008000000,DATA0,,,,0x20 0x00 0x00 0x00 0x00 0x00 0x03 0x00,0x1CBD
1.441432492000000,ACK,,,,,
1.441499600000000,SOF,,,0x3A5,,0x12
1.441544160000000,OUT,0x09,0x00,,,0x13
1.441547394000000,DATA1,,,,0x58 0x0C 0x00,0xEC0A
1.441552494000000,ACK,,,,,
1.441664214000000,IN,0x09,0x00,,,0x13

So you can see where it sent the Command packet: 0x45 0c 01 02 Which I have found are Bluetooth HCI commands:
0c -> OGF=3 (0c>>2), OCF=0x45 one parameter of 0x02...

Actually this looks pretty good when fed into Excel...

So started Bluetooth init code to emulate some of this. Right now I am feeding in the same commands and getting same results back. I am only partially there.
I think the most recent documents are up at: https://www.bluetooth.com/specificat...-specification
I have started off, finding most of the information in an earlier version of the HCI section up at: http://affon.narod.ru/BT/bluetooth_app_c10.pdf

There are several of the packets, that the Linux sends, that I have not figured out yet. Including:

			// 0x02 0x20 0x00 => 0x0E 0x07 0x01 0x02 0x20 0x00 0x00 0x00 0x00 (OGF=8???)
			// 0x03 0x20 0x00 => 0x0E 0x0C 0x01 0x03 0x20 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
			// 0x1C 0x20 0x00 => 0x0E 0x0C 0x01 0x1C 0x20 0x00 0xFF 0xFF 0xFF 0x1F 0x00 0x00 0x00 0x00

The first part is the command and second part are the returned values... In particular in these cases the 0x20>>2 comes out to 0x8 and so far I have not found any manuals that describe what OGF=8 is...

Edit: Looks like these are for LE devices at least by the one document I found: http://dev.ti.com/tirex/content/simp..._HCI_Guide.pdf


Currently I have the code outputting very verbose information:

USB Host Testing
960
BluetoothController claim this=1fff45e0 vid:pid=a12:1
    9 4 0 0 3 e0 1 1 0 7 5 81 3 10 0 1 7 5 2 2 40 0 1 7 5 82 2 40 0 1 9 4 1 0 2 e0 1 1 0 7 5 3 1 0 0 1 7 5 83 1 0 0 1 9 4 1 1 2 e0 1 1 0 7 5 3 1 9 0 1 7 5 83 1 9 0 1 9 4 1 2 2 e0 1 1 0 7 5 3 1 11 0 1 7 5 83 1 11 0 1 9 4 1 3 2 e0 1 1 0 7 5 3 1 19 0 1 7 5 83 1 19 0 1 9 4 1 4 2 e0 1 1 0 7 5 3 1 21 0 1 7 5 83 1 21 0 1 9 4 1 5 2 e0 1 1 0 7 5 3 1 31 0 1 7 5 83 1 31 0 1 
    rxep=1(16) txep=2(64)
HCI_RESET called (03 0c 00 )
*** Device HID1 a12:1 - connected ***
  product: CSR8510 A10
control callback (bluetooth): 1 : 3 c 0 
BT rx_data(6): e 4 1 3 c 0 
    Command Completed! 
03 10 00 )
control callback (bluetooth): 2 : 3 10 0 
BT rx_data(14): e c 1 3 10 0 ff ff 8f fe db ff 5b 87 
    Command Completed! 
HCI_Read_Local_Version_Information called (01 10 00 )
control callback (bluetooth): 3 : 1 10 0 
BT rx_data(14): e c 1 1 10 0 6 bb 22 6 a 0 bb 22 
    Command Completed! 
    Local Version: 6
HCI_Read_BD_ADDR called (09 10 00 )
control callback (bluetooth): 4 : 9 10 0 
BT rx_data(12): e a 1 9 10 0 13 71 da 7d 1a 0 
    Command Completed! 
   BD Addr:13:71:da:7d:1a:0
HCI_Read_Buffer_Size called (05 10 00 )
control callback (bluetooth): 5 : 5 10 0 
BT rx_data(13): e b 1 5 10 0 36 1 40 a 0 8 0 
    Command Completed! 
HCI_READ_CLASS_OF_DEVICE called (23 0c 00 )
control callback (bluetooth): 6 : 23 c 0 
BT rx_data(9): e 7 1 23 c 0 0 0 0 
    Command Completed! 
HCI_Read_Local_Name called (14 0c 00 )
control callback (bluetooth): 7 : 14 c 0 
BT rx_data(16): e fc 1 14 c 0 43 53 52 38 35 31 30 20 41 31 
    Command Completed! 
    Local name: CSR8510 A1
BT rx_data(16): 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 0
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(16): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
BT rx_data(14): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
    Local name continue: 
HCI_Read_Voice_Setting called (25 0c 00 )
control callback (bluetooth): 9 : 25 c 0 
BT rx_data(8): e 6 1 25 c 0 60 0 
    Command Completed! 
HCI_Read_Number_Of_Supported_IAC
38 0c 00 )
control callback (bluetooth): 10 : 38 c 0 
BT rx_data(7): e 5 1 38 c 0 2 
    Command Completed! 
HCI_Read_Current_IAC_LAP called (39 0c 00 )
control callback (bluetooth): 11 : 39 c 0 
BT rx_data(10): e 8 1 39 c 0 1 33 8b 9e 
    Command Completed! 
HCI_Set_Event_Filter_Clear called (05 0c 01 00 )
control callback (bluetooth): 12 : 5 c 1 0 
BT rx_data(6): e 4 1 5 c 0 
    Command Completed! 
Write_Connection_Accept_Timeout called (16 0c 02 00 7d )
control callback (bluetooth): 13 : 16 c 2 0 7d 
BT rx_data(6): e 4 1 16 c 0 
    Command Completed!

I still have not gotten to the place yet were it scans for devices and/or connects... A long ways to go.

As a different approach, I thought I would also look to see how the Arduino USB Host adapter 2 does it's initialization. My quick look through the code, they appear not to do appear to do the full complete stuff the linux driver does... I tried earlier hooking up the larger version of the adapter (TinyOS) to to one of my older T3.2 boards that I had Arduino headers and it did not init... It did on an Arduino Mega 128. Wondered if it maybe was trying to only get the SPI from the programmer adapter... So I purchased a micro version: https://www.amazon.com/gp/product/B01EWW9R1E
Yesterday I tried hooking up to Teensy 3.6. following the connections shown at: https://www.circuitsathome.com/mcu/t...-host-library/

So far the Teensy 3.5 does not want to fully init... It hangs in the usb::init() call on trying to read in a flag... Has anyone done this recently?

My first look at the SPI signals between the two boards, looked corrupted. In particular, the CS pin did not appear to be correct. Even when I removed the connection of it to the Adapter, it did not hold a solid high go to low for output of bytes... It sort of was toggling around.. I will retry with the Saleae Pro 8 at higher speeds to verify this as it is running SPI at 25mhz...

I am not sure how much time to use here on this, as I could do captures from Arduino Mega... Yes Should post picture May rewire with using solid core wires instead of jumpers...

But tempted to hack the usb host library 2 plus the spi4teensy3 library, to maybe simplify and simply see if you can use SPI.transfer() instead of talking at register level... Or maybe just debug...
Likewise controlling the CS pin would be nice if it simply did digitalWriteFast()... Instead of doing semi register stuff.. But again maybe barking up wrong tree...

Anyway back to debugging the two setups...

quick update: Probably talking to myself...

I tried moving the USB Host adapter to be run by T3.6 instead, also hooked up faster logic analyzer...


The SPI signal looks better on the Logic Analyzer. Not sure if I had bad connections or T3.5 issue... BUT it still does not init properly... Still think there may be issue with custom SPI code... Maybe someone needs to take a closer look (probably me)...

It is not properly detecting that the unit reset...
That is the call within spi.init() to reset() is failing. That templated function is doing:

template< typename SPI_SS, typename INTR >
uint16_t MAX3421e< SPI_SS, INTR >::reset() {
        uint16_t i = 0;
        regWr(rUSBCTL, bmCHIPRES);
        regWr(rUSBCTL, 0x00);
        while(++i) {
                if((regRd(rUSBIRQ) & bmOSCOKIRQ)) {
                        break;
                }
        }
        return ( i);
}

The regRd loop is failing... the bmOSCOKIRQ is equal 1.

regRd on Teensy is doing:

/* single host register read    */
template< typename SPI_SS, typename INTR >
uint8_t MAX3421e< SPI_SS, INTR >::regRd(uint8_t reg) {
        XMEM_ACQUIRE_SPI();
#if defined(SPI_HAS_TRANSACTION)
        USB_SPI.beginTransaction(SPISettings(26000000, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
#endif
        SPI_SS::Clear();

#if USING_SPI4TEENSY3
        spi4teensy3::send(reg);
        uint8_t rv = spi4teensy3::receive();
        SPI_SS::Set();
#elif defined(STM32F4)
...

Now the Receive function:

        uint8_t receive() {
                // clear any data in RX/TX FIFOs, and be certain we are in master mode.
                digitalWriteFast(0, !digitalReadFast(0));
                SPI0_MCR = SPI_MCR_MSTR | SPI_MCR_CLR_RXF | SPI_MCR_CLR_TXF | SPI_MCR_PCSIS(0x1F);
                SPI0_SR = SPI_SR_TCF;
                SPI0_PUSHR = SPI_PUSHR_CONT | 0xFF;
                while(!(SPI0_SR & SPI_SR_TCF));
                uint32_t ret = SPI0_POPR;
                Serial.printf("Rec: %x\n", ret);
                return ret;
        }

Note: I hacked this function slightly to save away the SPI0_Popr results and print them, plus the toggle of Digital pin 0...

Now the interesting stuff...
The debug output is showing:

Start
MAX3421e Init Called
MAX3421e After spi init
Rec: 0
Rec: 8
Rec: 8
Rec: 8
Rec: 8

But if you look at the data on the logic analyzer:

Which shows that it should be returning an 11 not an 8 which would cause the stuff to work... Now to figure out what is happening

EDIT: Add in some of the processing I do of Logic Analyzer data to get it to a form that is easier to look at in excel.
A lot of this data is repeated in several places including: https://discuss.saleae.com/t/logic-2...lpha-17/252/17
Likewise: https://forum.pjrc.com/threads/55457...l=1#post200761

Normally I save the data from the analyzer packet mode to file:


then use linux grep in Ubuntu window something like:

grep -B1 ",DATA" USB_Capture_WIndows_XBoxOne_Pair_packets2.txt > u2

Then I load it up in Submlime text and use a regular expression edit to combine lines:
Search (RE):

(.*\b)(IN|OUT|SETUP),0x[0-9A-F]*,(.*)\n.*DATA[0-1],,,(.*\n)

Replace:

$1,$2,$3,$4

[defragster]

Good Work KurtE - Keep it up! Your thread shows 51 Views so you are being watched - by 13 members. Lots of work to analyze the USB - you'll need to get that Man in the Middle Beagle Dog USB thingie Paul uses

[KurtE]

Thanks!

Luckily the Saleae stuff gives me most of the data. Also helps to be able to compare to both Linux and to USB Host shield 2.

I started off trying to emulate the Linux side, but later started to go more toward the host shield side as there are far far fewer configuration messages.

It is taking me awhile to make my way through some of this stuff, as it is hitting lots of things... Also diversions into Robotics stuff...

I have been playing around trying to get my T3.6 to talk to this Bluetooth keyboard/Touchpad combo...
https://smile.amazon.com/gp/product/B00JO80LVW/


So currently working toward a HID protocol setup...

First part was to get the T3.6 host to Connect/Pair to the device: Bluetooth Specification 5: Vol 3, Part E
Currently the code is setup to always have to pair each time... This is the next thing I will change...

Once these were talking, then needed to start using the Logical Link Control and Adaptation Protocol (L2CAP), which is
Vol 3 Part A...

Then once these parts are talking, you then need to setup the HID stuff, which was different PDF file (HID_v1.1.1pdf)...

Again the code is currently pretty hard code in order of things, plus not handling errors and the like, but today I was able to start receiving key data and trackpad data

Currently the code outputs tons of debug data:

USB Host Testing
960
BluetoothController claim this=1fff45e0 vid:pid=a12:1
    9 4 0 0 3 e0 1 1 0 7 5 81 3 10 0 1 7 5 2 2 40 0 1 7 5 82 2 40 0 1 9 4 1 0 2 e0 1 1 0 7 5 3 1 0 0 1 7 5 83 1 0 0 1 9 4 1 1 2 e0 1 1 0 7 5 
    3 1 9 0 1 7 5 83 1 9 0 1 9 4 1 2 2 e0 1 1 0 7 5 3 1 11 0 1 7 5 83 1 11 0 1 9 4 1 3 2 e0 1 1 0 7 5 3 1 19 0 1 7 5 83 1 19 0 1 9 4 1 4 2 e0 
    1 1 0 7 5 3 1 21 0 1 7 5 83 1 21 0 1 9 4 1 5 2 e0 1 1 0 7 5 3 1 31 0 1 7 5 83 1 31 0 1 
      rxep=1(16) txep=2(64) rx2ep=2(64)
HCI_RESET called (03 0c 00 )
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10
control callback (bluetooth): 1 : 3 c 0 
BT rx_data(6): e 4 1 3 c 0 
    Command Completed! 
HCI_WRITE_CLASS_OF_DEV called (24 0c 03 04 08 00 )
control callback (bluetooth): 2 : 24 c 3 4 8 0 
BT rx_data(6): e 4 1 24 c 0 
    Command Completed! 
HCI_Read_BD_ADDR called (09 10 00 )
control callback (bluetooth): 3 : 9 10 0 
BT rx_data(12): e a 1 9 10 0 13 71 da 7d 1a 0 
    Command Completed! 
   BD Addr:13:71:da:7d:1a:0
HCI_Read_Local_Version_Information called (01 10 00 )
control callback (bluetooth): 4 : 1 10 0 
BT rx_data(14): e c 1 1 10 0 6 bb 22 6 a 0 bb 22 
    Command Completed! 
    Local Version: 6
HCI_INQUIRY called (01 04 05 33 8b 9e 30 0a )
control callback (bluetooth): 5 : 1 4 5 33 8b 9e 30 a 
BT rx_data(6): f 4 0 1 1 4 
    Command 401 Status 0
BT rx_data(16): 2 f 1 7d 2b 22 27 97 c0 1 2 0 3c 4 8 d2 
BT rx_data(1): 50 
    Inquiry Result - Count: 1
      BD:7d:2b:22:27:97:c0, PS:1, class: 8043c
BT rx_data(16): 2 f 1 79 22 23 a c5 cc 1 2 0 40 25 0 34 
BT rx_data(1): 11 
    Inquiry Result - Count: 1
      BD:79:22:23:a:c5:cc, PS:1, class: 2540
      Peripheral device
        Keyboard
HCI_INQUIRY_CANCEL called (02 04 00 )
control callback (bluetooth): 100 : 2 4 0 
BT rx_data(6): e 4 1 2 4 0 
    Command Completed! 
HCI_CREATE_CONNECTION called (05 04 0d 79 22 23 0a c5 cc 18 cc 01 00 00 00 00 )
control callback (bluetooth): 101 : 5 4 d 79 22 23 a c5 cc 18 cc 1 0 0 0 0 
BT rx_data(6): f 4 0 1 5 4 
    Command 405 Status 0
BT rx_data(13): 3 b 0 48 0 79 22 23 a c5 cc 1 0 
    Connection Complete - ST:0 LH:48
HCI_AUTH_REQUESTED called (11 04 02 48 00 )
control callback (bluetooth): 110 : 11 4 2 48 0 
BT rx_data(5): 1b 3 48 0 5 
BT rx_data(6): f 4 0 0 11 4 
    Command 411 Status 0
BT rx_data(8): 17 6 79 22 23 a c5 cc 
    Event: Link Key Request 79:22:23:a:c5:cc
HCI_LINK_KEY_NEG_REPLY called (0c 04 06 79 22 23 0a c5 cc )
BT rx_data(6): f 4 0 1 0 0 
    Command 0 Status 0
control callback (bluetooth): 120 : c 4 6 79 22 23 a c5 cc 
BT rx_data(12): e a 1 c 4 0 79 22 23 a c5 cc 
    Command Completed! 
BT rx_data(8): 16 6 79 22 23 a c5 cc 
    Event: Pin Code Request 79:22:23:a:c5:cc
HCI_PIN_CODE_REPLY called (0d 04 17 79 22 23 0a c5 cc 04 30 30 30 30 00 00 00 00 00 00 00 00 00 00 00 00 )
control callback (bluetooth): 130 : d 4 17 79 22 23 a c5 cc 4 30 30 30 30 0 0 0 0 0 0 0 0 0 0 0 0 
BT rx_data(12): e a 1 d 4 0 79 22 23 a c5 cc 
    Command Completed! 
BT rx_data(16): 18 17 79 22 23 a c5 cc 78 d8 9c dc 8b bf fb 83 
BT rx_data(9): 34 29 a8 63 e 22 a5 fd 0 
    Event: Link Key Notificaton 79:22:23:a:c5:cc Type:0
    key:78 d8 9c dc 8b bf fb 83 34 29 a8 63 0e 22 a5 fd 
BT rx_data(5): 6 3 0 48 0 
    Event: HCI Authentication complete(0): handle: 48
L2CAP_ConnectionRequest called(48 20 0c 00 08 00 01 00 02 00 04 00 11 00 70 00 )
tx_data callback (bluetooth): 0 : 48 20 c 0 8 0 1 0 2 0 4 0 11 0 70 0 
BT rx_data(7): 13 5 1 48 0 1 0 

=====================
BT rx2_data(20): 48 20 10 0 c 0 1 0 3 0 8 0 42 0 70 0 0 0 0 0 
    L2CAP Connection Response: ID: 0, Dest:42, Source:70, Result:0, Status: 0
      Control Response
L2CAP_ConfigRequest called(48 20 10 00 0c 00 01 00 04 00 08 00 42 00 00 00 01 02 ff ff )
tx_data callback (bluetooth): 0 : 48 20 10 0 c 0 1 0 4 0 8 0 42 0 0 0 1 2 ff ff 

=====================
BT rx2_data(20): 48 20 10 0 c 0 1 0 4 2 8 0 70 0 0 0 1 2 30 0 
    L2CAP config Request: ID: 2, Dest:70, Flags:0,  Options: 1 2 30 0
      Control Configuration request
L2CAP_ConfigResponse called(48 20 12 00 0e 00 01 00 05 02 0a 00 42 00 00 00 00 00 01 02 a0 02 )
tx_data callback (bluetooth): 0 : 48 20 12 0 e 0 1 0 5 2 a 0 42 0 0 0 0 0 1 2 a0 2 
BT rx_data(7): 13 5 1 48 0 1 0 

=====================
BT rx2_data(22): 48 20 12 0 e 0 1 0 5 0 a 0 70 0 0 0 0 0 1 2 30 0 
    L2CAP config Response: ID: 0, Source:70, Flags:0, Result:0, Config: 201
Set HID Protocol 0 (48 20 05 00 01 00 42 00 70 )
BT rx_data(7): 13 5 1 48 0 1 0 
tx_data callback (bluetooth): 200 : 48 20 5 0 1 0 42 0 70 
L2CAP_ConnectionRequest called(48 20 0c 00 08 00 01 00 02 01 04 00 13 00 71 00 )
tx_data callback (bluetooth): 0 : 48 20 c 0 8 0 1 0 2 1 4 0 13 0 71 0 
BT rx_data(7): 13 5 1 48 0 1 0 

=====================
BT rx2_data(9): 48 20 5 0 1 0 70 0 0 
BT rx_data(7): 13 5 1 48 0 1 0 

=====================
BT rx2_data(20): 48 20 10 0 c 0 1 0 3 1 8 0 43 0 71 0 0 0 0 0 
    L2CAP Connection Response: ID: 1, Dest:43, Source:71, Result:0, Status: 0
      Interrupt Response
L2CAP_ConfigRequest called(48 20 10 00 0c 00 01 00 04 01 08 00 43 00 00 00 01 02 ff ff )

=====================
BT rx2_data(20): 48 20 10 0 c 0 1 0 4 3 8 0 71 0 0 0 1 2 30 0 
    L2CAP config Request: ID: 3, Dest:71, Flags:0,  Options: 1 2 30 0
      Interrupt Configuration request
L2CAP_ConfigResponse called(48 20 12 00 0e 00 01 00 05 03 0a 00 43 00 00 00 00 00 01 02 a0 02 )
tx_data callback (bluetooth): 0 : 48 20 12 0 e 0 1 0 5 3 a 0 43 0 0 0 0 0 1 2 
tx_data callback (bluetooth): 0 : 48 20 12 0 e 0 1 0 5 3 a 0 43 0 0 0 0 0 1 2 a0 2 

=====================
BT rx2_data(22): 48 20 12 0 e 0 1 0 5 1 a 0 71 0 0 0 0 0 1 2 30 0 
    L2CAP config Response: ID: 1, Source:71, Flags:0, Result:0, Config: 201
HCI_WRITE_SCAN_ENABLE called(1a 0c 01 02 )
BT rx_data(7): 13 5 1 48 0 1 0 
BT rx_data(7): 13 5 1 48 0 1 0 
control callback (bluetooth): 130 : 1a c 1 2 

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 3 89 cc c5 a 23 22 79 
HID HDR Data: len: 9, Type: 3
    Combo keyboard/pointing
BT rx_data(6): e 4 1 1a c 0 
    Command Completed! 

=====================
BT rx2_data(18): 48 20 e 0 a 0 71 0 a1 1 0 0 4 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
    Keyboard report type

=====================
BT rx2_data(18): 48 20 e 0 a 0 71 0 a1 1 0 0 0 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
    Keyboard report type

=====================
BT rx2_data(18): 48 20 e 0 a 0 71 0 a1 1 0 0 5 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
    Keyboard report type

=====================
BT rx2_data(18): 48 20 e 0 a 0 71 0 a1 1 0 0 0 0 0 0 0 0 
HID HDR Data: len: 10, Type: 1
    Keyboard report type


=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 8 0 fc ff 0 0 0 0 
HID HDR Data: len: 9, Type: 8
    Unknown report

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 8 0 fc ff 1 0 0 0 
HID HDR Data: len: 9, Type: 8
    Unknown report

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 8 0 fa ff 1 0 0 0 
HID HDR Data: len: 9, Type: 8
    Unknown report

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 8 0 f8 ff 1 0 0 0 
HID HDR Data: len: 9, Type: 8
    Unknown report

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 8 0 f8 ff 0 0 0 0 
HID HDR Data: len: 9, Type: 8
    Unknown report

=====================
BT rx2_data(17): 48 20 d 0 9 0 71 0 a1 3 88 cc c5 a 23 22 79 
HID HDR Data: len: 9, Type: 3
    Combo keyboard/pointing

The debug data shows data going through four different pipes. The control pipe, two different Read pipes and a write pipe.
Some of the commands are sent to Control others to the write... Some things come in on the RX and others come in on the other RX (RX2)...

-----------------------------------------------------------

@Paul and others

Once I add the code to handle both automatically connecting to previously paired device versus always having to pair and trimming down all of the debug output ... I need to start figuring out how to factor some of this code.

That is, the current code is setup with one device which is probably: Bluetooth Core - HID(using L2CAP)

But: I would also like for the Bluetooth code to also support joysticks like PS3 and PS4..

Maybe Serial replacements (might be nice to talk to smart phone)... Maybe Sound? ...

So should we aim toward a single Bluetooth object, which tries to combine everything into the one big object. Or should we do closer to the USB Host shield code, which has a Bluetooth base class and some subclasses (BTHID, PS3BT...)
or closer to our HID stuff, where we have a USBHidParser and then several classes derived from USBHIDInput....
So have a base Bluetooth object and then some bluetooth protocol objects?

Then talking about Bluetooth HID object. We have things like Mouse and Keyboard, and trackpad...
Should we have new objects like: BTKeyboardController so each program that wants keyboard data may have to handle both types of objects, or should the KeyboardController object should also be derived form some Bluetooth object, such that all of the data is funneled through the one object... , likewise for Mouse...

Lots to think about (or just tinker with).
If any one is curious: I pushed up current temporary stuff up to: https://github.com/KurtE/USBHost_t36/tree/Bluetooth-WIP

[KurtE]

Another update:

I have a version of code that now ties the Bluetooth up to keyboard. Added another list like HID list, where the keyboard object derives from. I have the Bluetooth code now call off to the bluetooth Claim code which in the case of my device the keyboard says yes...

Then when I get the keyboard input, with report 1, the keyboard code properly pulls out the keyboard presses and releases and calls off to the standard call back functions

There are several more issues to figure out and then try with this device/current code, some of the outstanding things include:

a) Can the Bluetooth device connect to multiple devices at same time? If so should probably split up bluetooth code up to main lower level code and maybe then a few higher level codes, like:
HID, like Joystick... This also would maybe be like our USB HID code where we may have one lower level bluetooth object, which then may talk to N Bluetooth connection objects, where the connection objects then talk to the device objects: Keyboard, Mouse, Joystick, Serial, ... Note: we may need/want sub-classes of the connection objects as they may use different bluetooth subsystems...

b) When I connect up to lets say a keyboard: and the application code calls off to things like: idVendor, idProduct Or asks for product() string, which values should it return? The local information from the Bluetooth dongle, or the Remote names/values for the device currently connected. I am assuming the later. So far the code that is doing the binding stuff is at least in some cases asking for the remote device name, which I currently just print out. Instead need to use one of our stings and save away...

c) With current device I am not processing the touchpad messages... Not sure if the Mouse objects should support these, or if we should create a touch pad like object...

d) The keyboard code was crashing when I pressed the caps lock. Turns out it was then trying to update keyboard leds by sending message back to the DEVICE... So I needed to detect that we are connected by BT and not use that code. But there is a way to do this using BT. So need to figure out how to setup the back channel to update the LEDS.

e) When I turn off all DEBUG code, how to handle some logical states, like: if the user wishes to do a PAIRING to new device, then probably need way to tell, the application code that we are in that state, such that, the app can decide on how to tell the user to make their device detectable. Likewise, when the user may need to enter a KEYCODE...

Not sure if/who might be interested in all of this stuff. If anyone wishes to play with keyboard... Could clean up and make it so you can try... Current code is up on github in the Bluetooth-WIP branch.
Also not sure which device to try next. May try one of the Joysticks (PS4 or PS3...) Or maybe look around to see if I have something I can make a Serial replacement like connection...

[KurtE]

Thought I would mention, that I am still playing around here...

Right now playing with PS4(DS4) controller connecting up wirelessly... I do have it such that I can bind to it and some of the times I am getting it to the point where I am receiving basic Joystick packets (LX, LY, RX, RY, <3 bytes of buttons> LThumb, RThumb... I have some hooks into the USB Host joystick code to receive these messages. Soon will direct those to call of to the Users functions...

What I am not trying to figure out, is how to know what is connected to me. That is I so far I have code that knows that a GamePad is connected.

I can ask for the remote name, which is returning: Wireless Controller

I can ask for remote version information, which is returning: 48 0 5 45 0 0 0
Not sure if the 2 byte vendor ID gives me anything. The version of 0 does not say much...

What I would like to be able to do, is to know that the is the PS4 and then maybe have the Joystick code be able to ask the bluetooth code to configure the joystick for full data, like what is done is the USB code for the PS4...

Hopefully soon will figure some of this out... But too many other distractions!

Anyone else have more Bluetooth and USB... Knowledge?

Kurt

[mattrcampbell]

Thought I would mention, that I am still playing around here...

Right now playing with PS4(DS4) controller connecting up wirelessly... I do have it such that I can bind to it and some of the times I am getting it to the point where I am receiving basic Joystick packets (LX, LY, RX, RY, <3 bytes of buttons> LThumb, RThumb... I have some hooks into the USB Host joystick code to receive these messages. Soon will direct those to call of to the Users functions...

What I am not trying to figure out, is how to know what is connected to me. That is I so far I have code that knows that a GamePad is connected.

I can ask for the remote name, which is returning: Wireless Controller

I can ask for remote version information, which is returning: 48 0 5 45 0 0 0
Not sure if the 2 byte vendor ID gives me anything. The version of 0 does not say much...

What I would like to be able to do, is to know that the is the PS4 and then maybe have the Joystick code be able to ask the bluetooth code to configure the joystick for full data, like what is done is the USB code for the PS4...

Hopefully soon will figure some of this out... But too many other distractions!

Anyone else have more Bluetooth and USB... Knowledge?

Kurt

Kurt this is great work! I have played around a bit with it and have been able to write the start of a driver for the Nintendo Wiimote. While looking into the massive amount of features and options for the device, I can't help but wonder if it might be better to figure out how to add Teensy 3.6 USB host support to the USB_Host_Shield library, or even to work off of a fork of that project. The Wii driver alone is over 1200 lines of code! That project has tons of users and if we were able to leverage all that code for the devices they support it would be awesome!

Just curious if you have given that any thought?


https://github.com/felis/USB_Host_Shield_2.0

[KurtE]

Thanks for the feedback...

I keep meaning to get back to this. I have sort of dropped working on this for awhile as I was not sure anyone was interested. So I have been spending my time on some other projects like the Well monitor board, 3d Printing, Turtlebot 3 waffle... And it is now spring and lots to do outside!

It should be mentioned, that @Paul is the main owner of this. I am just trying to help out as much as possible. When I was last playing with it, I did have it at least partially working with the BT Keyboard/Mouse combo. I also had it working with a PS4 remote, and maybe PS3? I would need to double check that one.

As for Host shield 2, code I have wondered about trying to get it to work with this, at least as an option. As part of this I have tried to get some of their shields working with a T3.6

It was not working the last time I tried... Probably should debug it... Then maybe get an idea on how hard it would be to adapt to not using the adapter but going directly the the T3.6 built in USB support. I also have one of their other shields, that when I tried it, it did not work with the Teensy I tried, but is working with a standard Arduino...

Also wondering about differences in the library usage patterns and what Paul thinks? That is, with our current stuff, we try to allow you to plug in some class of object, like a Serial Adapter and hopefully allow you to use many different ones without having to change the code, likewise the Joystick. Where the USB Host shield code is setup where you need to set it specifically for which hardware you are exactly trying to work with. Example there is different drivers for PS3 vs PS4, actually there are two different ones for each of these, (directly plugged into USB vs Bluetooth). I know there are also ones for WII... Maybe that is sufficient, but would be nice if I did not have to change everything depending on which one I was using. Again more of a question for Paul.

But maybe I will again first see if I can figure out why my mini host shield is not working.

[mattrcampbell]

Thanks for the feedback...

I keep meaning to get back to this. I have sort of dropped working on this for awhile as I was not sure anyone was interested. So I have been spending my time on some other projects like the Well monitor board, 3d Printing, Turtlebot 3 waffle... And it is now spring and lots to do outside!

It should be mentioned, that @Paul is the main owner of this. I am just trying to help out as much as possible. When I was last playing with it, I did have it at least partially working with the BT Keyboard/Mouse combo. I also had it working with a PS4 remote, and maybe PS3? I would need to double check that one.

As for Host shield 2, code I have wondered about trying to get it to work with this, at least as an option. As part of this I have tried to get some of their shields working with a T3.6

It was not working the last time I tried... Probably should debug it... Then maybe get an idea on how hard it would be to adapt to not using the adapter but going directly the the T3.6 built in USB support. I also have one of their other shields, that when I tried it, it did not work with the Teensy I tried, but is working with a standard Arduino...

Also wondering about differences in the library usage patterns and what Paul thinks? That is, with our current stuff, we try to allow you to plug in some class of object, like a Serial Adapter and hopefully allow you to use many different ones without having to change the code, likewise the Joystick. Where the USB Host shield code is setup where you need to set it specifically for which hardware you are exactly trying to work with. Example there is different drivers for PS3 vs PS4, actually there are two different ones for each of these, (directly plugged into USB vs Bluetooth). I know there are also ones for WII... Maybe that is sufficient, but would be nice if I did not have to change everything depending on which one I was using. Again more of a question for Paul.

But maybe I will again first see if I can figure out why my mini host shield is not working.

I have order a shield and I am going to play around with that as well.

I dug into the code a ton over the weekend and made a little progress. I must admit to finding myself going in circles trying to understand how the initialization and inheritance of all the classes works. For instance, even though JoystickController implements HIDParser, I can't use USBHIDParser::sendPacket because it need to have been initialized with USBHIDParser::claim. But only BluetoothController::claim is called?

[KurtE]

Yep - It is as clear as mud

I assume you are looking at my Bluetooth branch: https://github.com/KurtE/USBHost_t36/tree/Bluetooth-WIP

It has been probably a month since I looked at it, so I am a bit rusty... Also at that point I may have also broken some stuff...

It gets sort of interesting to try to make one top level class Joystick to work with a variety of joysticks as the underlying code can be very different:

If memory serves me right, there are three different flavors of joysticks here:

a) Originally USB connected joysticks where are defined as HID devices (in same way as Mouse and Keyboard)... Things like Teensy, PS3, PS4 work this way when plugged into USB

In these cases, a HID object (USBHIDParser) will try to claim the device. It will then look through the HID report classes and ask each object which is derived from USBHidInput) if it would like to claim a collection or not. It can claim the collection either at the device level or at the Report level. So when the Joystick object is claimed this way, it needs to rely on the USBHIDParser object to actually talk to the device. Most of the time it simply receives information from it. (hid_input_begin, hid_input_data, hid_input_end). But I added a back door (It remembers the handle to the device), that it may want to use. Example to set the LEDS and rumble on these joysticks.

b) USB Joystick which don't follow the typical rules and have their own USB code. In particular the XBOX One controller. This one has code in place to try to claim it using the ::claim method. In this case the code has to deal with setting up the RX and TX pipes and control all of the configuration stuff.

c) and Now the Bluetooth stuff I am experimenting with. I have sort of setup some of the bluetooth stuff like the HID, but there are a lot of different sub-flavors of Bluetooth... But in our case here we are assuming a certain Bluetooth device class. (2500 or 500).

And assuming the Joystick claims the Bluetooth object, it would then receive data through: process_bluetooth_HID_data

As for then being able to send data back to the device... Like the Hid Parser: I think btdevice is supposed to be the back pointer in this case... Although it looks like most cases are commented out right now. There would need to be a callback function like thee was added for HID, in order for me to send back information like to be able to set the rumble or the like. I believe this was about when I left off...

[knightshade]

It has been a bit since I've followed up to see what has been going on with USB Host support for the Teensy....
I had been hoping to see support for PS3 Move Navigation controllers (as seen in UHS 2.0).

Hopefully I'll be able to find some down time soon to play with this.

[mjs513]

@KurtE
Created a pull request for your BT WIP2 branch

Mike

[KurtE]

Thanks, I pulled it in... Hopefully the new controller will there today... We may brave it and see how bad the roads are

[mjs513]

Hi KurtE

Hope you didn't go out today = roads sound a little to dangerous.

Ok heres what I just finished playing with:
1. Tried to get rumble to work no luck - even found that the scid's do change as you progress through the connection process based on the command being sent to the controller. I even tried adding CRC's per this post: https://github.com/chrippa/ds4drv/pu...bd52d3e193665d. So that was a bust
2. Tried my PS3 on BT but cant figure out how to get it to pair. All I did was hit the ps3 button

[mjs513]

Ok - this morning i reloaded the BT joystick sketch and now its not working again. Something strange is going on.

[KurtE]

Hi Mike,

Off-topic...
We went out yesterday and made it to town... But the private mailbox had not processed all of the packages that came in as they were closed the previous day as well... While we were heading down our road, a neighbor was trying to make it back up in his all wheel driver Subaru, and would get stuck, get out a come along and attach to a tree, pull himself out of ditch, try again... But we hoped that we would be fine coming back with our all wheel drive car with offroad setting... Well we had zero traction on the ice at the entrance to our street.... So we decided to play it safe and park at the bottom of the hill and walk the half mile home... Hopefully today we will rescue the car. Worst case I think I may have a set of chains... Currently temp around 31 degrees...

Back on topic:

1) Rumble... Will look at that when I get the PS4 controller... It is now sitting in a box at our PMB in town. Hopefully will get back to town soon... May want to double check things like how big the message is... Sometimes they seem to be picky on how many bytes are sent to them.

2) I don't believe PS3 controllers can be paired over BT... I believe you can only do it over USB. There are utilities (sixpair) that I have seen for Ubuntu, and I believe I have seen them for Windows as well... I believe the sources for sixpair can be found at: git clone https://github.com/falkTX/qtsixa.git
Old document on it: https://help.ubuntu.com/community/Sixaxis
Not sure if anyone has done it for Arduino, like for the Arduino Usb host shield...
When I tried earlier, I put both on a RPI and used the sixpair command to hopefully update both....

[mjs513]

Hi Mike,

Off-topic...
…. Well we had zero traction on the ice at the entrance to our street.... So we decided to play it safe and park at the bottom of the hill and walk the half mile home... Hopefully today we will rescue the car. Worst case I think I may have a set of chains... Currently temp around 31 degrees...

Back on topic:

1) Rumble... Will look at that when I get the PS4 controller... It is now sitting in a box at our PMB in town. Hopefully will get back to town soon... May want to double check things like how big the message is... Sometimes they seem to be picky on how many bytes are sent to them.

2) I don't believe PS3 controllers can be paired over BT... I believe you can only do it over USB. There are utilities (sixpair) that I have seen for Ubuntu, and I believe I have seen them for Windows as well... I believe the sources for sixpair can be found at: git clone https://github.com/falkTX/qtsixa.git
Old document on it: https://help.ubuntu.com/community/Sixaxis
Not sure if anyone has done it for Arduino, like for the Arduino Usb host shield...
When I tried earlier, I put both on a RPI and used the sixpair command to hopefully update both....

Just be careful out their. Always preferred snow over ice - at least you have a little more traction.

1. UHS2 uses a packet size of 79 but for usb we used 32 and it work - tried that too but no luck.
2. I saw sixaxis referenced but wasn't sure how that worked. Now I get understand thanks to your explanation.

Going to solder the USB header onto a T3.6 and try the changes I made on that as a sanity check. When you get the PS4 may want to check that i added the code correctly for the PS4 functions. Maybe something the way i referenced it. Grepwin and CodeCompare are becoming my best friends lately

EDIT: NON ISSUE on not working anymore - had to push the T4 back in. All is good

[KurtE]

Yep - I have had times when something was not working and found that the pogo pins had pushed the chip up and some were no longer making good connection.

Looked some more at PS3 and stuff... Noticed that usb host shield 2 code had way to do binding by giving the PS3 object the BDADDR of the host... so looking at that.

Thought I would print out the address of my dongle... So thought I would add member function to return it from the class:

class BluetoothController: public USBDriver {
public:
...
    const uint8_t* 	myBDAddr(void) {return my_bdaddr_;}

And hacked on your sketch to print it out...

        if (drivers[i] == &bluet) {
          const uint8_t *btaddr = bluet.myBDAddr();
          Serial.printf("  BDADDR: :%x:%x:%x:%x:%x:%x\n", btaddr[0], btaddr[1], btaddr[2], btaddr[3], btaddr[4], btaddr[5]);
        }

This is when it detects that the BT dongle is plugged in... And it printed out:

USB Host Testing
960
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10
  BDADDR: :0:0:0:0:0:0

The problem is that the initialization code is sort of Async... We output one message at a time, wait for the response. And the message is several down in list... So hacked the code some more and when the above code is run, I remember the millis() and then check to see if not zero and a second had passed:

  // Curious about bt address after a second
  if (time_bt_connect && ((millis()-time_bt_connect) > 1000)) {
    time_bt_connect = 0;
    const uint8_t *btaddr = bluet.myBDAddr();
    Serial.printf("  BDADDR: :%x:%x:%x:%x:%x:%x\n", btaddr[0], btaddr[1], btaddr[2], btaddr[3], btaddr[4], btaddr[5]);
  }

And it then printed: BDADDR: :13:71:da:7d:1a:0

I am thinking of adding a member to check to see if there are still any pending init messages, sort of like deviceReady()...

[mjs513]

Looked some more at PS3 and stuff... Noticed that usb host shield 2 code had way to do binding by giving the PS3 object the BDADDR of the host... so looking at that.

I was poking around this morning and noticed that after you mentioned about pairing it post #17. Figured I would leave that alone until I finished with the PS4 issues. I did notice that you should be able to get the accel and gyros readings out as well using report 0x11. Have to check to see what is in the current code - looks like you request report 0x01 (ref http://eleccelerator.com/wiki/index....k_4#HID_OUTPUT)

EDIT: I found this in ds4frv:

class HidrawBluetoothDS4Device(HidrawDS4Device):
    __type__ = "bluetooth"
    report_size = 78
    valid_report_id = 0x11
    def set_operational(self):
        self.read_feature_report(0x02, 37)

Struggling to find that in the library, really the equivalent.

[KurtE]

I picked up my PS4 today Weather is warmer plus we ran up and down our road with our tractor, which helped break up some of the ice... Then went to town picked up stuff... And made it up our hill.

Now trying to discover state of things... If I run the mouse sketch with it plugged into usb, I get lots of data, plus pressing left or right buttons (L2/R2) I get rumble...

I have not tried to bind it with this app yet... If I run the JoystickBT app, I am not getting the rumble even plugged in USB...

With the JoystickBT app with debug stuff enabled I was getting lots of output, but did not get anything when debug stuff turned off... Will try again...

[mjs513]

Glad you made it out today. Hope the nice weather holds for you until its all gone. Now you can have fun your PS4

Now trying to discover state of things... If I run the mouse sketch with it plugged into usb, I get lots of data, plus pressing left or right buttons (L2/R2) I get rumble..

Same here with my PS4. So far so good.

I have not tried to bind it with this app yet... If I run the JoystickBT app, I am not getting the rumble even plugged in USB...

Yeah, you probably wouldn't. Think if you run the sketch with bluetooth constructor uncommented as in the JoystickBT app it probably overrides the connected version. Just a guess.

Also as a heads up since I couldn't figure out how to identify it as a PS4 controller when connected to bluetooth the joystickBT.ino calls separate PS4 functions, at least for now while testing. When i checked the DS4 controller is identified as a gamepad?

With the JoystickBT app with debug stuff enabled I was getting lots of output, but did not get anything when debug stuff turned off... Will try again...

Not sure what you mean here.

EDIT: Think there are different control/report commands you have to use when using Bluetooth to the DS4, for output from and input to.

EDIT: I know I did mention in the other thread, but I checked rumble function using the mini usb host shield and it did work from there. I think we need to figure out what the correct command sequence is and verify the function we need to send the packet. I think its the same as in the usb host shield.

[mjs513]

Ok. This is getting frustrating. Went off and ran a few other sketches then came back to Bluetooth. Now its hanging again when I do the debug prints and if I comment them out it gets to the point of connecting to Bluetooth and claiming joystick then nothing again. Something is not right.

[defragster]

Ok. This is getting frustrating. Went off and ran a few other sketches then came back to Bluetooth. Now its hanging again when I do the debug prints and if I comment them out it gets to the point of connecting to Bluetooth and claiming joystick then nothing again. Something is not right.

That does sound very frustrating I glanced at the Bt debug code - it seemed the trace_tt could go in place of those prints for logging in real time and then printing after the event

[mjs513]

That does sound very frustrating I glanced at the Bt debug code - it seemed the trace_tt could go in place of those prints for logging in real time and then printing after the event

Yeah, that was what I was thinking but today is one of those days that I keep getting sidetracked with other projects around the house that I have to get done. Or it could be a power problem since I am coming off a USB2 port on the PC. Have to debug but time is limited today. Probably get to it tonight.

[KurtE]

One thing I was noticing when using the Mouse.ino sketch. And the other one as well. When I have the code in to the bind...

I notice: the debug output:

USB Host Testing
960
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10
BluetoothController::find_driver  driver 20002bf8
Keyboard Controller::claim_bluetooth - Class 2508
  driver 20002e78
Keyboard Controller::claim_bluetooth - Class 2508
  driver 20005978
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
Bluetooth Disconnect*** Device Bluet - disconnected ***
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10

That when the Joystick was making the connection, that the Blutooth controller was disconnected and then reconnected... But the Joystick did not show up as connected.