[Bluez-devel] sco / csr final notes

[Bluez-devel] sco / csr final notes

[Simon Vogl]

well now I have a heuristic that works most of the time. Looking at the
transmitted data, I wonder if there could be a big endian/little endian
switch that is toggled randomly in the firmware for the 16bit sco data.

Is there a lucky person with a developer kit out there who is able
to confirm this?
Thanks,
Simon


--=20
_______________________________________________________________________
Dr. Simon Vogl
Institut f=C3=BCr Pervasive Computing, Johannes Kepler Universit=C3=A4t L=
inz
Altenberger Stra=C3=9Fe 69, A-4040 Linz, Austria

Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: vogl@soft.uni-linz.ac.at,  http://www.soft.uni-linz.ac.at/








-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco / csr final notes

[Marcel Holtmann]

Hi Simon,

> well now I have a heuristic that works most of the time. Looking at the
> transmitted data, I wonder if there could be a big endian/little endian
> switch that is toggled randomly in the firmware for the 16bit sco data.
> 
> Is there a lucky person with a developer kit out there who is able
> to confirm this?

please remind us about what your are talking, because it seems that at
least I forgot it. If you think you found a bug and you are able to
reproduce it, you should make a detailed description, so the CSR guys
can fix it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco / csr final notes

[Simon Vogl]

oh, sorry: well, after trying for weeks, I see always the same behavior of
the sco data: after a connect of the sco channel, the data is either byte-swapped
or offset by one byte, but no indication in any header etc. can be found why
this is the case.

The original assumption that there might be packets with a byte (or more)
missing has not turned out to be right (could not find an indication of this).

Anyway, as a workaround, I have implemented a small signal analysis function that
tests, in short, if the incoming signal is gaussian or even distributed (the latter
is an indication for a byte swap) - upon which I adapt the output accordingly.
(the code is at http://www.soft.uni-linz.ac.at/_wiki/tiki-index.php?page=ProjectBluezHandsfree)

Marcel, do you I can bug with this at csr?
Simon

Simon

Marcel Holtmann wrote:
> Hi Simon,
> 
> 
>>well now I have a heuristic that works most of the time. Looking at the
>>transmitted data, I wonder if there could be a big endian/little endian
>>switch that is toggled randomly in the firmware for the 16bit sco data.
>>
>>Is there a lucky person with a developer kit out there who is able
>>to confirm this?
> 
> 
> please remind us about what your are talking, because it seems that at
> least I forgot it. If you think you found a bug and you are able to
> reproduce it, you should make a detailed description, so the CSR guys
> can fix it.
> 
> Regards
> 
> Marcel
> 


-- 
_______________________________________________________________________
Dr. Simon Vogl
Institut für Pervasive Computing, Johannes Kepler Universität Linz
Altenberger Straße 69, A-4040 Linz, Austria

Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: vogl@soft.uni-linz.ac.at,  http://www.soft.uni-linz.ac.at/

Re: [Bluez-devel] sco / csr final notes

[Steven Singer]

Simon Vogl wrote:
> oh, sorry: well, after trying for weeks, I see always the same behavior of
> the sco data: after a connect of the sco channel, the data is either byte-swapped
> or offset by one byte, but no indication in any header etc. can be found why
> this is the case.

Is the problem that the link spontaneously changes from correct to noisy
in the middle of a link, or is it that when you start up a link it's
either OK for the durection of the link, or noisy for the duration of
the link and then when you tear it down and start a fresh link, the next
one is, independently, correct our noisy?

If it's the latter case, is the first link after a full reset (BCCMD
reset or power cycle - not merely an HCI reset) ever noisy?

> Marcel, do you I can bug with this at csr?

You should use the CSR public newsgroups (follow the links from the CSR
web site), though, in practice, making enough noise on this mailing list
will eventually attract the attention from someone at CSR (there are
several people here who subscribe).

	- Steven
-- 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: [Bluez-devel] sco / csr final notes

[Simon Vogl]

Steven Singer wrote:
> Simon Vogl wrote:
> 
>>oh, sorry: well, after trying for weeks, I see always the same behavior of
>>the sco data: after a connect of the sco channel, the data is either byte-swapped
>>or offset by one byte, but no indication in any header etc. can be found why
>>this is the case.
> 
> 
> Is the problem that the link spontaneously changes from correct to noisy
> in the middle of a link, or is it that when you start up a link it's
> either OK for the durection of the link, or noisy for the duration of
> the link and then when you tear it down and start a fresh link, the next
> one is, independently, correct our noisy?
> 
> If it's the latter case, is the first link after a full reset (BCCMD
> reset or power cycle - not merely an HCI reset) ever noisy?
> 
the latter is the case. Whenever a fresh sco link starts, I have a 50% chance of
getting the wrong byte order..

I still have to try how it reacts after a cold reset, as I dont have a developer kit -
I just downloaded the bccmd spec, and I need to write a small piece of software to
transmit this command.... But I will tell you as soon as I know.

> 
>>Marcel, do you I can bug with this at csr?
> 
> 
> You should use the CSR public newsgroups (follow the links from the CSR
> web site), though, in practice, making enough noise on this mailing list
> will eventually attract the attention from someone at CSR (there are
> several people here who subscribe).

I have already, thanks, and will beat the bush shortly. I have to get several other
flaws straight first - I am over an important project deadline already, but that's
a different story :(

Simon

> 
> 	- Steven


-- 
_______________________________________________________________________
Dr. Simon Vogl
Institut für Pervasive Computing, Johannes Kepler Universität Linz
Altenberger Straße 69, A-4040 Linz, Austria

Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: vogl@soft.uni-linz.ac.at,  http://www.soft.uni-linz.ac.at/

Re: [Bluez-devel] sco / csr final notes

[Steven Singer]

Simon Vogl wrote:
> Steven Singer wrote:
>> Is the problem that the link spontaneously changes from correct to noisy
>> in the middle of a link, or is it that when you start up a link it's
>> either OK for the durection of the link, or noisy for the duration of
>> the link and then when you tear it down and start a fresh link, the next
>> one is, independently, correct our noisy?
>> 
>> If it's the latter case, is the first link after a full reset (BCCMD
>> reset or power cycle - not merely an HCI reset) ever noisy?
>> 
> the latter is the case. Whenever a fresh sco link starts, I have a 50% chance of
> getting the wrong byte order..

Assuming it never happens for the first link, then it might be known issue
H16.169 (aka. B.104). This is present in 16.4 firmware and is fixed in
16.14. The following is the documentation of this issue from the 16.14
release note (I've marked the relevant section with >>>chevrons<<<):

------------------------------------------------------------------------
Appendix D – Issues Addressed Relative to HCI 16.4

[...]

ID:          B.104, H16.169
Severity:    High
Description:

If a system routes HCI SCO channels over USB, there is a high
probability that if two SCO channels are opened, and then one of them is
closed, then the firmware will crash. This problem has not been seen if
only one SCO channel is routed over USB. There is a related, but
technically independent, problem. >>>If a USB SCO link is closed, and
then a new USB SCO link is opened, it is possible for the second link’s
from-air audio to be badly distorted.<<<

The audio distortion problem occurs only where both SCO links use 16-bit
samples. The distortion occurs where the host does not collect all of
the bytes from the last HCI SCO packet of the first SCO link. The second
SCO link reuses the first link’s endpoint, and the link’s data
incorrectly starts with the first link’s few uncollected bytes. >>>This
can be an odd number of bytes, misaligning all subsequent 16-bit samples
by one byte.<<<

The same audio distortion misalignment can result from a race hazard
within the chip, even if the host takes all of the link’s trailing
bytes when closing the SCO link. In practice, the race hazard is the
primary cause of this problem arising. The distortion issue is similar
to issue H13.154, but that issue concerned from-host SCO USB traffic.

(HCI builds’ release notes have never claimed support for SCO over USB,
mainly because of the lack of suitable test equipment, so it is arguable
whether this issue should be categorised as being of “high” importance.)

Remedy
Both problems have been substantially improved in HCI 16.14. This avoids
the issue that causes the chip to crash. The same defensive code also
avoids the audio distortion problem.
------------------------------------------------------------------------

I think this confirms your observations. The error is a missing byte and
not an endian-ness switch. Upgrading your firmware should fix the
problem, otherwise, swallowing a byte when you notice the problem should
also ressurect the audio quality. Alternatively, you could always switch
to 8 bit samples.

Release notes are available on the CSR support web site if you have
suitable access permissions.

	- Steven
-- 



**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: [Bluez-devel] sco / csr final notes

[James Courtier-Dutton]

Steven Singer wrote:
> Simon Vogl wrote:
> 
>>Steven Singer wrote:
>>
>>>Is the problem that the link spontaneously changes from correct to noisy
>>>in the middle of a link, or is it that when you start up a link it's
>>>either OK for the durection of the link, or noisy for the duration of
>>>the link and then when you tear it down and start a fresh link, the next
>>>one is, independently, correct our noisy?
>>>
>>>If it's the latter case, is the first link after a full reset (BCCMD
>>>reset or power cycle - not merely an HCI reset) ever noisy?
>>>
>>
>>the latter is the case. Whenever a fresh sco link starts, I have a 50% chance of
>>getting the wrong byte order..
> 
> 
> Assuming it never happens for the first link, then it might be known issue
> H16.169 (aka. B.104). This is present in 16.4 firmware and is fixed in
> 16.14. The following is the documentation of this issue from the 16.14
> release note (I've marked the relevant section with >>>chevrons<<<):
> 
> ------------------------------------------------------------------------
> Appendix D – Issues Addressed Relative to HCI 16.4
> 
> [...]
> 
> ID:          B.104, H16.169
> Severity:    High
> Description:
> 
> If a system routes HCI SCO channels over USB, there is a high
> probability that if two SCO channels are opened, and then one of them is
> closed, then the firmware will crash. This problem has not been seen if
> only one SCO channel is routed over USB. There is a related, but
> technically independent, problem. >>>If a USB SCO link is closed, and
> then a new USB SCO link is opened, it is possible for the second link’s
> from-air audio to be badly distorted.<<<
> 
> The audio distortion problem occurs only where both SCO links use 16-bit
> samples. The distortion occurs where the host does not collect all of
> the bytes from the last HCI SCO packet of the first SCO link. The second
> SCO link reuses the first link’s endpoint, and the link’s data
> incorrectly starts with the first link’s few uncollected bytes. >>>This
> can be an odd number of bytes, misaligning all subsequent 16-bit samples
> by one byte.<<<
> 
> The same audio distortion misalignment can result from a race hazard
> within the chip, even if the host takes all of the link’s trailing
> bytes when closing the SCO link. In practice, the race hazard is the
> primary cause of this problem arising. The distortion issue is similar
> to issue H13.154, but that issue concerned from-host SCO USB traffic.
> 
> (HCI builds’ release notes have never claimed support for SCO over USB,
> mainly because of the lack of suitable test equipment, so it is arguable
> whether this issue should be categorised as being of “high” importance.)
> 
> Remedy
> Both problems have been substantially improved in HCI 16.14. This avoids
> the issue that causes the chip to crash. The same defensive code also
> avoids the audio distortion problem.
> ------------------------------------------------------------------------
> 
> I think this confirms your observations. The error is a missing byte and
> not an endian-ness switch. Upgrading your firmware should fix the
> problem, otherwise, swallowing a byte when you notice the problem should
> also ressurect the audio quality. Alternatively, you could always switch
> to 8 bit samples.
> 
> Release notes are available on the CSR support web site if you have
> suitable access permissions.
> 
> 	- Steven

Just out of interest, how does one upgrade the firmware on a USB device 
using a CSR chip ?

I have this device: -

bash-2.05b# hciconfig hci0 version
hci0:   Type: USB
         BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
         HCI Ver: 1.1 (0x1) HCI Rev: 0x135 LMP Ver: 1.1 (0x1) LMP 
Subver: 0x135
         Manufacturer: Cambridge Silicon Radio (10)

bash-2.05b# hciconfig hci0 revision
hci0:   Type: USB
         BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
         HCI 13.10
         Chip version: BlueCore01b
         Max key size: 56 bit
         SCO mapping:  HCI



Cheers
James



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco / csr final notes

[Marcel Holtmann]

Hi James,

> Just out of interest, how does one upgrade the firmware on a USB device 
> using a CSR chip ?
> 
> I have this device: -
> 
> bash-2.05b# hciconfig hci0 version
> hci0:   Type: USB
>          BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
>          HCI Ver: 1.1 (0x1) HCI Rev: 0x135 LMP Ver: 1.1 (0x1) LMP 
> Subver: 0x135
>          Manufacturer: Cambridge Silicon Radio (10)
> 
> bash-2.05b# hciconfig hci0 revision
> hci0:   Type: USB
>          BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
>          HCI 13.10
>          Chip version: BlueCore01b
>          Max key size: 56 bit
>          SCO mapping:  HCI

you need a *.dfu firmware file from your dongle manufacturer.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] sco / csr final notes

[James Courtier-Dutton]

Marcel Holtmann wrote:
> Hi James,
> 
> 
>>Just out of interest, how does one upgrade the firmware on a USB device 
>>using a CSR chip ?
>>
>>I have this device: -
>>
>>bash-2.05b# hciconfig hci0 version
>>hci0:   Type: USB
>>         BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
>>         HCI Ver: 1.1 (0x1) HCI Rev: 0x135 LMP Ver: 1.1 (0x1) LMP 
>>Subver: 0x135
>>         Manufacturer: Cambridge Silicon Radio (10)
>>
>>bash-2.05b# hciconfig hci0 revision
>>hci0:   Type: USB
>>         BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8  SCO MTU: 64:8
>>         HCI 13.10
>>         Chip version: BlueCore01b
>>         Max key size: 56 bit
>>         SCO mapping:  HCI
> 
> 
> you need a *.dfu firmware file from your dongle manufacturer.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 

The dongle manufacturer is Mitsumi, and I cannot find any firmware files 
for it.
Does anyone know of any url that might have updated firmware for this 
device ?

Cheers
James

Re: [Bluez-devel] sco / csr final notes

[Marcel Holtmann]

Hi James,

> The dongle manufacturer is Mitsumi, and I cannot find any firmware files 
> for it.
> Does anyone know of any url that might have updated firmware for this 
> device ?

I already talked to Mitsumi and they don't plan to provide firmware
updates for their dongles.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel