Are there any workarounds to connect to HID device using L2CAP in JAVA ME (using JSR-82 specification implementation native to mobile device not BlueCove etc.)?
I know that HID devices usually uses PSMs (Protocol Service Multiplexor) with 0x0011 value. Unfortunately as I found:
Legal PSM values are in the range (0x1001..0xFFFF), and the least significant byte must be odd and all other bytes must be even.
Above explains why javax.microedition.io.Connector connect() method throws exception when I try following code:
Connector.open("btl2cap://600010120296:11");
This page suggests that the restriction was removed in JSR-82 1.2:
Legal PSM values are in the range (0x0005..0xFFFF), and the least significant byte must be odd and all other bytes must be even. When a server connection string does not have a psm parameter, the server PSM value assigned by the implementation must be no less than 0x1001.
And the comment:
Remove reserved ranges from L2CAP PSM values, to allow a Java application to use a Bluetooth protocol that is built on top of L2CAP using a PSM value in the "reserved" range.
Also, the "interrupt endpoint" is PSM 0x13 (that's where keyboards, mice, etc will send unsolicited reports just like they would send on the control channel (0x11) in response to GET_REPORT).
Related
I want to know what does bluetooth transmit when it is just visible, not connected. I googled , I saw it transmit name of the device and mac address but just them ? Can we add some extra datas or can we change them dynamically ?
For classic Bluetooth (i.e. pre Android API level 21), you are restricted with the data that you can send in the inquiry response (which is connection-less data sent over the air). There are three types of inquiry response data that can be sent over the air:-
Inquiry Result:-
Inquiry Result with RSSI:-
Extended Inquiry Result:-
In other words, depending on what the scanning device asks for, the result can be different, and even though in all cases it is not just name and mac address, you cannot add just random extra data to the inquiry response.
For Bluetooth Low Energy (i.e. Android API level 21 and later), advertising data can be dynamic and can be configurable. The minimum advert report can only contain the device's Bluetooth Address (either the public or the random address). In other words, even the name of the device is not a requirement. However, it is usually common to include both the address and the name as this gives more information about the advertising device.
You can read more about this in the Bluetooth Specification v5.2, Vol 6, Part B, Section 2.3.1 (Advertising PDUs). Also have a look at the links below for more information:-
Is a BLE advertisement required to provide a non-empty local name
How BLE works: advertisements
BLE advertising primer
I feel like both are used to identify logical channel that a physical channel is divided into. Is there any difference?
Short answer:
Both terms are relevant to Bluetooth Logical Links definitions.
LT Address is defined in Link Control; it is being used In the packet header.
In general, It allows a Bluetooth (BR/EDR) slave to determine that a certain packet was addressed to it.
LLID is defined in the packet payload header and is used to distinguish between:
ACL-C (Link Management Protocol) message
ACL-U (L2CAP - Logical Link Control and Adaptation Protocol) message
Detailed answer (all page references address the BT Spec 5.0):
LT Address is defined in the Bluetooth Baseband Specification and stands for Logical Transport Address.
It is defined in Link Control layer for the master to be able to address its various slaves within the piconet.
Each slave is assigned with a unique 3-bit LT_ADDR (page 390):
The primary LT_ADDR shall be assigned by the master to the slave when
the slave is activated. This is either at connection establishment or
role switch, when the primary LT_ADDR is carried in the FHS payload.
LLID term is defined in ACL-C and ACL-U (=> L2CAP) logical links:
It is included in the packet payload header to determine if a packet is ACL-C (LMP) or ACL-U (L2CAP):
ACL-C (page 398):
The ACL-C and ASB-C logical links are indicated by the LLID code 11b
in the payload header.
ACL-U (page 399):
For fragmented messages, the start packet shall use anLLID code of
10b in the payload header. Remaining continuation packets shall use
LLID code 01b. If there is no fragmentation, all packets shall use
the LLID start code 10b.
There’s another usage of the LLID term in context of Bluetooth Low Energy (LE) which is not covered here.
The Logical Link Control and Adaptation Layer Protocol (L2CAP) is layered over the Baseband Protocol and resides in the data link layer. It provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.
Fig1: L2CAP architecture block
Link Controller (LC)
The standard data packet used at the LC level comprises an Access Code, Packet Header, Payload Header, Payload and CRC. This standard packet will be used to encompass data to and from the upper-layers of the protocol stack.
Fig1: Packet structure at LC
Packet Header
Header comprises of six fields LT_ADDR,TYPE,FLOW,ARQN,SEQN and HEC
LT_ADDR (Logical Transport Address) : LT_ADDR comprises of a 3-bit field, which denotes an active slave within a piconet (Note: that the master is not assigned a LT_ADDR).
Payload
LLID (Logical Link Identifier) : Within such logical transports, the logical link is identified by the LLID bits in the payload header of baseband packets that carry a data payload.
Ref :
BLE5-Stack User's Guide
Developing Practical Wireless Applications
Bluetooth Specification - Vol 0
For BLE advertising type LOCAL_NAME_COMPLETE, is there a minimum length requirement?
I could not find any length specification in the spec (other than it needs to fit in the advertising packet of 31 bytes minus anything else already in the advertisement packet), but am running into an issue where it may seem that there is. I wanted to confirm here.
According to the BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] section 12.1:
...The Device Name characteristic value shall be 0 to 248 octets in length. A
device shall have only one instance of the Device Name characteristic.
But since the AD packet is limited to 31 bytes then I guess that if it's too big then one should broadcast the shortened name instead of full name (different AD types)
So it seems like there is no limitations on a minimum size. Hope it helped.
I'm implementing a LIN protocol on a Linux SBC that transmits over a UART. I don't have time to develop a complete LIN stack, so I'm just implementing a frame structure for messages as defined by the protocol. The problem is that the protocol requires a "Break" field which makes the slave devices on the bus listen. This field consists of zeros for 13 bit-times. Any ideas how to send zeros 13 bit-times over UART, when serial data transmission requires complete bytes?
Per Wiki:
LIN (Local Interconnect Network) is a serial network protocol used for
communication between components in vehicles. The need for a cheap
serial network arose as the technologies and the facilities
implemented in the car grew, while the CAN bus was too expensive to
implement for every component in the car. European car manufacturers
started using different serial communication topologies, which led to
compatibility problems.
If you would have paid attention at class you would have known that:
Data is transferred across the bus in fixed form messages of
selectable lengths. The master task transmits a header that consists
of a break signal followed by synchronization and identifier fields.
The slaves respond with a data frame that consists of between 2, 4 and
8 data bytes plus 3 bytes of control information.
You should just send an echo of 0x0000 following by CR/LF.
I bought a HM-15 BLE bluetooth module and successefully connected to Arduino. I am able to sent At commands and I would like to use it for scanning for iBeacons and get their major and minor.
Using AT+DISC? I can see the beacon address but I cannot connect to it and now I am stuck on how to retrieve major and minor
Can you help me? Here is the datasheet of the module:
http://www.elecrow.com/download/bluetooth40_en.pdf
Thanks
Bluetooth beacons do not require a connection and you read the identifiers directly from the advertisement.
Read section 19, Start a discovery scan, and learn how to read and decode the bytes in the discovered peripherals. The exact byte layout varies for different beacon types. For AltBeacon, an open source beacon variant, you can see the byte layout here: https://github.com/AltBeacon/spec
To decode a proprietary beacon format, you will need to learn how that beacon layout differs from the example linked above.
Old question, but just for the record, you can use AT-DISI?
This will scan for beacons, including iBeacons and also AltBeacons. The response from HM-10 will include RSSI for each.
PS: I'm assuming HM-15 and HM-10 operate the same way. Probably not exactly a fully reasonable assumption.