I am doing research on CAN BUS and CAN Protocol. I want to know that, does each car model has different pinout on OBDII port? Or Is it same on all cars?
P.S. If it differs, is there a database for it?
Wikipedia to the rescue:
OBD-II is an improvement over OBD-I in both capability and standardization. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signalling protocols available, and the messaging format.
Related
I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.
I've been pouring over the BT 4.x (LE) spec trying to figure out if this is possible or not (events without pairing/boding).
Does anyone have an insight (and link to the spec preferably) if it's possible?
As Mike Petrichenko commented, GATT communication is definitely possible without pairing. In fact most GATT servers/clients out there function without the need for pairing/bonding. The only exception is when some characteristics require authentication/authorisation in order to read some data (e.g. a medical device with a Heart rate characteristic).
If you want a specific reference to where this is mentioned in the Bluetooth spec, then I recommend looking at the Core Specification version 5.2, Vol 3, Part C, section 10.2 (LE Security Modes):-
The security requirements of a device, a service or a service request
are expressed in terms of a security mode and security level. Each
service or service request may have its own security requirement. The
device may also have a security requirement. A physical connection
between two devices shall operate in only one security mode.
It is then mentioned that LE security mode 1 has the level No security, and many GATT servers/clients work in this level.
You can test this yourself if you have two phones available. You can use the nRF Connect app to run a GATT server on one and a GATT client on the other. You will see that you can browse the GATT table and read data without having to pair.
Below are a few links that contain more information:-
Is pairing/encryption mandatory to allow a peer to write in GATT
Bluetooth Low Energy GATT security levels
How GAP and GATT work
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
Among the various officially registered Bluetooth device services, which are listed on the Bluetooth.org website, there is no mention of F002 or F003. But I recently was scanning for BLE in public and some unnamed device had these two services. Does anyone here know what device uses F002 or F003? Thanks.
Services in BLE can be adopted or custom. They have UUIDs that are 128bit long but are usually identified by their 16-bit offset:-
Adopted services are those listed by the Bluetooth SIG as
standard Bluetooth UUIDs. They're given a unique number and you have
probably already seen them here. Examples of those include the
Heart Rate (offset 180D), Health Thermometer (offset 1809), Battery
(offset 180F), etc. Those UUIDs are universal and if you see 180D
anywhere it should mean that it's the heart rate service.
Custom UUIDs on the other hand are undefined and in many cases can be just randomly generated. F002 is not an identified offset and therefore can belong to anyone using it for any random service.
I do remember coming across TI sensor tags with a similar UUID so it's worth investigating if you have any of those lying around.
A good read of UUIDs and BLE in general can be found here:-
https://www.safaribooksonline.com/library/view/getting-started-with/9781491900550/ch04.html
I have a bunch of generic beacons from China that I'd like to upgrade to Eddystone. How do I go about doing this?
Some beacon hardware vendors like Estimote and Kontakt.io now support Eddystone™ too. You are able to easily change the broadcasting scheme of your beacon to iBeacon or Eddystone protocol. In the below video by Pushmote URL, you can see how to change Estimote beacons' broadcasting scheme to Eddystone™ protocol:
https://www.youtube.com/watch?v=gX0AlAOB6NU
As it's possible with Estimote and Kontakt.io beacons, it might be possible with yours too. Contact with your hardware manufacturer to see the possibilities.
I am quoting it from here
Generally the "transmit these bytes" instructions are carried out in
firmware on the beacon and can't be controlled in real-time via
software. Many beacon manufacturers have updated their provisioning
applications to allow their devices to broadcast Eddystone frames. For
generic beacons (maybe you mean raw BLE chips? or Arduino/R-Pi sets?)
you'll need to set the bytes to Tx manually since there's no generic
provisioning app (or not that I'm aware of).
Thanks to Michael Ashbridge (aka) mashbridge
Unfortunately, you probably can't. Generic beacons typically don't offer firmware upgrades, and few if any generic vendors offer Eddystone support.
Full disclosure: I am Chief Engineer at Radius Networks, which sells beacons with Eddystone support.