[Bluez-devel] Question on using HCIDUMP to interpret data monitored from an uart

["Han Hoekstra" <Han.Hoekstra@WirelessValue.nl>]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

Hello all,
 
I have a question about using hcidump to translate serial logged HCI
communication to readable form.
 
The situation is this, I have 8 embedded devices of which 1 is the master
and the other 7 are slave devices in a piconet and they communicate to each
other via RFCOMM. The master sets up a connection to all 7 slaves in the
beginning of the communication process and then communicates with all 7. But
there is a problem that the communication stops after some time and we want
to check what is going on.
The embedded devices are Linux based systems with a CSR bluecore, the main
processor communicates with the Bluecore via a serial link running the BCSP
protocol. The Bluecore is running the lower layers of the stack and talking
HCI to the host processor which is running BlueZ.
 
What we have now to monitor communications is one device that has the serial
connection between Bluecore and Linux host processor routed to 2 external
serial ports for monitoring. So it is possible to capture all communications
between the Bluecore and the Linux host processor. We already have software
that strips the BCSP protocol and saves the raw data in the format of a
hcidump save file, but there is some extra data in the packets stored in the
file that we don't know where it comes from, but is required by hcidump to
translate the data into readable form. We have already found out about the
time-stamp and direction fields, but there is other data that we suspect is
state information added by the BlueZ stack and we don't know what that is.
 
Is it possible to somehow feed the data from the serial port to hcidump and
have hcidump translate that data to readable form or is there some extra
data reaquired that is generated by the BlueZ stack ?
 
Does anyone have any idea if this is feasable ?
 
BTW. it is not possible to run hcidump on the embedded device, because there
is no way to create files on it and the CPU is to slow to handle the extra
load (probably).
 
Greetings,
   Han
 
---
Han Hoekstra
Wireless Value B.V.
Waanderweg 30a
7812 HZ  Emmen
Tel: +31-591-633200
 

[-- Attachment #2: Type: text/html, Size: 4189 bytes --]