Re: [Bluez-users] How to configure a 723kbps connection?

[Steven Singer <steven.singer@csr.com>]

Marcel Holtmann wrote:
> no I don't missed the point here. But the thread was broken and if you
> look at the beginning you see that I already told him that it can be a
> problem with a too slow UART. This is true for the 3870.

I read Matt's message as that he was asking for confirmation of your
suggestion that the UART baud rate was the most likely limit and that
he should stop wasting his time playing with the packet settings. Given
the information he listed, particularly that the link quality was 255,
I think it's unlikely to be a problem with the Bluetooth link and more
likely to be a problem elsewhere in the system.

The next few messages in the thread were talking about whether the Zeevo
chip was a bad chip or had a bad link manager. This appears to be
irrelevant as the most likely source of the bandwidth limit is the Ipaq
UART.

Although I'm normally quite happy to see our competitors' products
maligned, I think that in this case, the conclusion was unwarranted.

>> Also, although you're right that the RSSI has nothing to do with the
>> chosen packet type, the link quality has a big effect. As the link
>> quality falls, devices will tend to switch automatically from DH
>> packets to the more robust DM packets.
>
> The link quality is problematic, because every chip manufacturer can
> interpret this value different. For CSR this is bound to the BER. Had
> you ever run any test with your chips against the old Zeevo TC2001
> generation?

The spec allows the link quality to be tied to anything, but module
manufacturers will be aware that if they don't have at least some
component of the link quality sensitive to whether DH packets are likely
to get through, they're going to get support calls of the form "why am I
getting only 400 kbps but get_link_quality says the link is perfect?"

However, since the logs Matt gave show him running hcitool to get
the link quality, he must be getting it on the Linux side of the
link which, according to his hciconfig, is a CSR device.

This tells us that the CSR device is has a BER for received packets
that's low enough for DH5 packets to stream at 700 kbps. However, it
tells us nothing about the BER for packets received at the Ipaq end.
The link may not be symmetric. However, even if the link had switched
to DM5 packets, we'd expect to see 470 kbps. To get 265 kbps the link
would have to be atrocious (> 0.4% BER). I think it's unlikely that
we'd have a 0.4% BER one way and < 0.0025% the other way.

There may be other issues. For example, poor choice of L2CAP MTU
could limit the packet types that are allowed (for example, L2CAP
MTUs sigificantly below 150 could limit the data rate). This would
show up on an HCI trace. An HCI trace would also confirm which profile
was being used for the connection.

It may be that the Ipaq is limited in the rate at which it can process
data. This could cause it to assert UART flow control to the Bluetooth
chip, stalling the data flow.

As for testing with Zeevo, it's probably safest if I say nothing. Most
interoperability testing is covered by NDAs.

	- 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
**********************************************************************