Bluetooth and FreeBSD

sidetone

sidetone

Someone asked, and I'll post this here...
How did you get a usb bluetooth dongle to work? I gather that FreeBSD only has support for v1.1 and my bluetooth dongles are version v4.0. Any thoughts or advice is welcome
Click to expand...

I've never gotten it to work. I've only gotten remote devices (as in apart from the dongle) to show up, but they didn't show up as Bluetooth devices. I don't remember the output status of my Bluetooth dongle (it was either version 3 or 4).

Avoid building the base from /usr/src/ (source), and there will be less impediments: removing features through src.conf may strip away components that Bluetooth may need.

There's a possibility that Bluetooth V1 in the base could be used with version 4 of Bluetooth devices with v1.1 features.


When people say they got Bluetooth to work in these forums, the context in which they're referring to isn't often specific. I see lack of mention of which version driver is used and which version of dongle and components are used. To know, you can look up the source in the /usr/src/ directory or online. A developer once told me that Bluetooth of higher versions worked (which had power saving capabilities available in version 4), but I couldn't follow this, and this may have been inaccurate.

I don't know how familiar you are with hardware configuration on FreeBSD or other OS's. Play around with the commands kldload and kldstat. Check your /dev directory, and there's some manpages on FreeBSD to look at for Bluetooth V1.1.


Does anyone have information related to this, or updates?
 

These are my notes from 2016...​

Hardware​

  • Xbee board with an HC-06 bluetooth module
  • Jaluino Bee v2.1 board with PIC18F27J53 microcontroller
  • USB Bluetooth adapter (Mac Mini has one built-in but not usable from FBSD)
Setup

To connect wirelessly:
  1. If your kernel does not have the Bluetooth device drivers compiled into the kernel, you should be able to load them as kernel modules. Before attaching a device, you need to load the drivers into the kernel:
    • # kldload ng_ubt
  2. If the Bluetooth device is present in the system during system startup, load the module from /boot/loader.conf:
    • ng_ubt_load="YES"
  3. Plug in your USB dongle. The output similar to the following will appear in /var/log/messages:
    ubt0: <vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/19.15, addr 7> on uhub2
  4. ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
  5. ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294

  6. The /etc/rc.d/bluetooth script is used to start and stop the Bluetooth stack. It is a good idea to stop the stack before unplugging the device, but it is not (usually) fatal. Since FreeBSD 5.5, there is an entry in devd.conf which sets up the Bluetooth stack when a device is plugged in. If you stop the stack at any time (eg restart it), you can start it again without re-plugging the USB Bluetooth adapter with:
    • # /etc/rc.d/bluetooth start ubt0
  7. Check for Bluetooth devices in range with:
    • # hccontrol -n ubt0hci inquiry
      Inquiry result, num_responses=1
      Inquiry result #0
      • BD_ADDR: 28:cf:da:02:e5:ae
        Page Scan Rep. Mode: 0x1
        Page Scan Period Mode: 0x2
        Page Scan Mode: 00
        Class: 3a:01:04
        Clock offset: 0x4b34
      • Inquiry result, num_responses=1
      Inquiry result #0
      • BD_ADDR: 00:11:06:14:03:12
        Page Scan Rep. Mode: 0x1
        Page Scan Period Mode: 0x2
        Page Scan Mode: 00
        Class: 00:1f:00
        Clock offset: 0x500b
      • Inquiry complete. Status: No error [00]
  8. The first address is the USB Bluetooth adapter and the second address is the Bluetooth Xbee.
  9. Check you can ping the USB Bluetooth adapter and the Bluetooth Xbee:
    • # l2ping -a 28:cf:da:02:e5:ae
      • 44 bytes from 28:cf:da:02:e5:ae seq_no=1 time=40.234 ms result=0 44 bytes from 28:cf:da:02:e5:ae seq_no=2 time=51.189 ms result=0 44 bytes from 28:cf:da:02:e5:ae seq_no=3 time=35.241 ms result=0
      • # l2ping -a 00:11:06:14:03:12
      • 4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=14.022 ms result=0 4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=25.685 ms result=0 4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=27.683 ms result=0
  10. The hcsecd(8) daemon is responsible for handling of all Bluetooth authentication requests. You need to add an entry for the Bluetooth Xbee to /etc/bluetooth/hcsecd.conf (note you can't use a name for bdaddr here, it must be a numeric address):
    • device {
      • bdaddr 00:11:06:14:03:12;
        name "BlueXbee";
        key nokey;
        pin "1234";
        }
  11. Now start hcsecd by running:
    • # /etc/rc.d/hcsecd start
  12. You may need to execute the following command to ensure that some devices will pair:
    • # hccontrol -n ubt0hci write_authentication_enable 1
  13. The following line can be added to the /etc/rc.conf file to have hcsecd started automatically on system start:
    • hcsecd_enable="YES"
  14. To find the name of a Bluetooth device given its address, execute:
    • # hccontrol -n ubt0hci remote_name_request 00:11:06:14:03:12
      • BD_ADDR: 00:11:06:14:03:12 Name: BlueXbee
  15. The rfcomm_sppd(1) utility implements the Serial Port profile. A pseudo tty is used as a virtual serial port abstraction. To connect to a remote device Serial Port service (ie our Bluetooth Xbee):
    • # rfcomm_sppd -a 00:11:06:14:03:12 -t /dev/ttyp7
      • rfcomm_sppd[36607]: Starting on /dev/ttyp7...
  16. The flashing connection LED on the Bluetooth Xbee should now be lit solid to indicate a valid connection.
  17. To list the connected devices, execute:
    • # hccontrol -n ubt0hci read_connection_list
      • Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
        00:11:06:14:03:12 0 ACL 0 MAST NONE 0 0 OPEN
  18. To talk to the Bluetooth Bee, execute:
    • # cu -l ttyp7
  19. You should now see the 0101 pattern repeating, and pressing 0-5 on the keyboard should slow down or speed up the flashing user LED on the Bluetooth Bee. HINT: To exit from cu, type ~ followed by CTRL-D.
  20. Once you tire of typing Bluetooth addresses, you can setup /etc/bluetooth/hosts
    :-)
 
The JAL code for the microcontroller:

Code: 
-- Title: Blink-a-led with UART output for Jaluino Bee, 18F27J53 based
-- Author: Sébastien Lelong, Copyright (c) 2008..2009, all rights reserved.
-- Adapted-by: Trev
-- Compiler: 2.4o
--
-- This file is part of jaluino  (http://jaluino.googlecode.com)
-- Released under the BSD license (http://www.opensource.org/licenses/bsd-license.php)
--
-- Description: this program blinks a LED for ever... LED is built-in, onboard,
-- connected to pin 13 (RC2) and outputs 0 for LED off and 1 for LED on wirelessly
-- via an inserted bluetooth Xbee. Solder jumpers for serial hardware are set to
-- TX1/RX1 for the default UART.

include jaluino_bee -- jaluino bee defaults
include delay       -- include the delay library

-- Use onboard user LED
onboard_led_direction =  output

-- disable analog I/O
-- enable_digital_io() [included in jaluino_bee.jal]

-- ok, now setup serial i/o
const serial_hw_baudrate = 9_600  -- bluetooth default baudrate
include serial_hardware           -- include the serial i/o library
serial_hw_init()                  -- initialise serial hardware

-- output library
include print                     -- include print library
const byte string1[]="Gday! Gday! Gday!"  -- sign on message

-- output signon message
print_string(serial_hw_data, string1)

-- store received char
var byte rxchar

-- store delay; default (10 x 100ms) 1 second
var byte ndelay = 10

-- LOOP
forever loop
   onboard_led = on    -- turn on LED
   serial_hw_data = 49 -- send "0" via serial port

   delay_100ms(ndelay) -- do delay
   onboard_led = off   -- turn off LED
   serial_hw_data = 48 -- send "1" via serial port

   if serial_hw_read(rxchar)    then
      serial_hw_write(rxchar)   -- echo received character
   end if

   -- check for special received characters and set delay
   if rxchar == "0" then
         ndelay = 10
   elsif rxchar == "1" then
         ndelay = 1
   elsif rxchar == "2" then
         ndelay = 2
   elsif rxchar == "3" then
         ndelay = 3
   elsif rxchar == "4" then
         ndelay = 4
   elsif rxchar == "5" then
         ndelay = 5
   end if

   delay_100ms(ndelay)  -- do delay
end loop
 
trev
Were the instructions you used for a dongle of Bluetooth version 1.x or maybe 2.x? Which Bluetooth version(s) was the dongle of?

Also, if you were aware at the time, which version(s) of Bluetooth were the peripherals of?


Bluetooth 1.1 is the most standard one, which is in FreeBSD's base. ng_ubt(4) in base is for v1.1. Manpages also of note: hccontrol(8), hcsecd(8), hcsecd.conf(5), l2ping(8), cu(1) and rfcomm_sppd(1).

There are (or were) a few Bluetooth 2.x drivers in ports, but they're not standard.

Bluetooth versions 3.x to 5.x possibly work without Bluetooth drivers.
 
The BT HC-06 module specs:
  • Built-in CSR company Bluetooth chip BC417143
  • Bluetooth® Technology v2.0 + EDR
  • TTL data transparent transfer between a host Bluetooth device
  • Compatible with all Bluetooth adapters that support SPP
  • Coverage up to 30 ft / 10 m (Class 2)
  • Built in antenna
  • Power input: +3.1 to 4.2 VDC (bluetooth module)
  • Compact Size
  • Can set the module control parameters and control commands via AT commands
  • The maximum serial baud rate: 1382400 bps, support for hardware flow control transfer
  • Provide seven input and output ports, scalable user IO resources
  • Connection/non-connection status indicators
 
It seems like a Bluetooth version 2.0 dongle worked on the ng_ubt driver, which is for Bluetooth version 1.1. So a 2.0 Bluetooth dongle functioned as a v1.1 Bluetooth capability device?

ng_ubt(4) states:
Code: 
Isochronous USB transfers are broken.  This means that the USB device
     will not be able to transfer SCO data (voice).  USB interrupt transfers
     are implemented as bulk-in transfers (not really a bug).
SCO = synchronous connection oriented

I think it means, this driver allows sound transfer, but not real-time two way audio for communication.
 
According to the BC417143 datasheet:

9.1.1 Key Features of the HCI Stack: Standard Bluetooth Functionality

Bluetooth v2.0 + EDR mandatory functionality:

Adaptive frequency hopping (AFH), including classifier
Faster connection - enhanced inquiry scan (immediate FHS response)
LMP improvements
Parameter ranges

Optional Bluetooth v2.0 + EDR functionality supported:

Adaptive Frequency Hopping (AFH) as Master and Automatic Channel Classification
Fast Connect - Interlaced Inquiry and Page Scan plus RSSI during Inquiry
Extended SCO (eSCO), eV3 +CRC, eV4, eV5
SCO handle
Synchronisation

The firmware was written against the Bluetooth v2.0 + EDR specification.

Bluetooth components:
Baseband (including LC)
LM
HCI

Standard USB v1.1 and UART HCI Transport Layers
All standard radio packet types
Full Bluetooth data rate, enhanced data rates of 2 and 3Mbps(1)
Operation with up to seven active slaves(1)
Scatternet v2.5 operation
Maximum number of simultaneous active ACL connections: 7(2)
Maximum number of simultaneous active SCO connections: 3(2)
Operation with up to three SCO links, routed to one or more slaves
All standard SCO voice coding, plus transparent SCO
Standard operating modes: Page, Inquiry, Page-Scan and Inquiry-Scan
All standard pairing, authentication, link key and encryption operations
Standard Bluetooth power saving mechanisms: Hold, Sniff and Park modes, including Forced Hold
Dynamic control of peers' transmit power via LMP
Master/Slave switch
Broadcast
Channel quality driven data rate
All standard Bluetooth test modes

The firmware's supported Bluetooth features are detailed in the standard Protocol Implementation Conformance Statement (PICS) documents, available from www.csr.com.
Click to expand...

As to the different BT version specifications:

Version 1.0 – 3.0: Bluetooth Classic​


When we talk about each iteration of Bluetooth, three factors help distinguish between the different versions: range, data speed and power consumption. These factors are determined by the modulation scheme and data packet being used. When the first version of Bluetooth came out, it paved the way for the wireless headphones, speakers and game controllers that we use today. However, back then Bluetooth 1.0 was far slower than what we have now. Data speeds capped off at 1 Mbps and the range only reached as far as 10 meters.


The first version of Bluetooth used a modulation scheme called Gaussian Frequency Shift Keying (GFSK). With GFSK, the modulated carrier shifts between two frequencies representing 1s and 0s.


When Bluetooth 2.0 came out, GFSK was taken out in favor of two newer schemes: p/4-DQPSK and 8DPSK, which used changes in the waveforms’ phase to carry information, as opposed to frequency modulation. These two schemes resulted in unprecedented data speeds of 2 Mbps and 3 Mbps, respectively. Bluetooth 3.0 further improved data speeds with the addition of 802.11 for up to 24 Mbps of data transfer, although this was not a mandatory part of the 3.0 specification.


The results were game-changing. Short-range wireless solutions could now provide reliable, high speed connection, opening up to possibilities of major technological advancement in wireless devices.


However, one significant still prevented early versions of Bluetooth from widespread IoT integration: power consumption. Because of the large amount of energy that was required from Bluetooth versions 1.0 – 3.0, also known as Bluetooth Classic, small devices would continue to suffer from short battery life, making early versions of Bluetooth impractical for IoT use.
Click to expand...

All of which suggests to me that ng_ubt(4) should support v2.0 devices (it cerrainly did back in 2016 when I was running some version of FreeBSD 10). The man page hasn't been updated since Dec 2012...
 
I see that ng_ubt supported a v2.0 Bluetooth device. I was wondering if the driver supported the v2.0 dongle under v1.1 functionality or v2.0 functionality. Either way, it supports it enough on some level.

Documentation on Bluetooth hasn't been updated in a while, so I wonder what the functionalities of Bluetooth are, according to what some say rather than what is in many ways outdated documentation.

Maybe versions 1.1 and 2.x work under ng_ubt. I'm starting to think that version 3 and/or 4 don't work. Bluetooth v5.x dongles made for audio only might work in another way, perhaps not as Bluetooth devices.
 
Looking at the code, these are listed as supported devices:

Code: 
)/* List of supported bluetooth devices */
static const STRUCT_USB_HOST_ID ubt_devs[] =
{
        /* Generic Bluetooth class devices */
        { USB_IFACE_CLASS(UDCLASS_WIRELESS),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* AVM USB Bluetooth-Adapter BlueFritz! v2.0 */
        { USB_VPI(USB_VENDOR_AVM, 0x3800, 0) },

        /* Broadcom USB dongles, mostly BCM20702 and BCM20702A0 */
        { USB_VENDOR(USB_VENDOR_BROADCOM),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* Apple-specific (Broadcom) devices */
        { USB_VENDOR(USB_VENDOR_APPLE),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* Foxconn - Hon Hai */
        { USB_VENDOR(USB_VENDOR_FOXCONN),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* MediaTek MT76x0E */
        { USB_VPI(USB_VENDOR_MEDIATEK, 0x763f, 0) },

        /* Broadcom SoftSailing reporting vendor specific */
        { USB_VPI(USB_VENDOR_BROADCOM, 0x21e1, 0) },

        /* Apple MacBookPro 7,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8213, 0) },

        /* Apple iMac11,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8215, 0) },

        /* Apple MacBookPro6,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8218, 0) },

        /* Apple MacBookAir3,1, MacBookAir3,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821b, 0) },

        /* Apple MacBookAir4,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821f, 0) },

        /* MacBookAir6,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x828f, 0) },

        /* Apple MacBookPro8,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821a, 0) },

        /* Apple MacMini5,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8281, 0) },

        /* Bluetooth Ultraport Module from IBM */
        { USB_VPI(USB_VENDOR_TDK, 0x030a, 0) },

        /* ALPS Modules with non-standard ID */
        { USB_VPI(USB_VENDOR_ALPS, 0x3001, 0) },
        { USB_VPI(USB_VENDOR_ALPS, 0x3002, 0) },

        { USB_VPI(USB_VENDOR_ERICSSON2, 0x1002, 0) },

        /* Canyon CN-BTU1 with HID interfaces */
        { USB_VPI(USB_VENDOR_CANYON, 0x0000, 0) },

        /* Broadcom BCM20702A0 */
        { USB_VPI(USB_VENDOR_ASUS, 0x17b5, 0) },
        { USB_VPI(USB_VENDOR_ASUS, 0x17cb, 0) },
        { USB_VPI(USB_VENDOR_LITEON, 0x2003, 0) },
        { USB_VPI(USB_VENDOR_FOXCONN, 0xe042, 0) },
        { USB_VPI(USB_VENDOR_DELL, 0x8197, 0) },
        { USB_VPI(USB_VENDOR_BELKIN, 0x065a, 0) },
};
 
As the Intel Mac mini 2011 (models 5,1 and 5,2) is supported, it's BT is Bluetooth 4.0 and as I happen to have one running FreeBSD, dmesg shows: ugen1.6: <Apple Inc. Bluetooth USB Host Controller> at usbus1. I've never tried to use it though, my BT experiments were carried out with a 2009 Mac mini running FreeBSD.
 
It was a blank Xbee PCB which I bought and to which I soldered a BT HC-06 module for insertion into a Jaluino Bee I'd constructed. See pic - the two rows of horizontal headers on the left were for the Xbee PCB to plug in. It communicated with FreeBSD over BT.
 

Attachments

  • jbee_xbee.png
    jbee_xbee.png
    756.2 KB · Views: 262
You must log in or register to reply here.
Back
Top