Marcel Holtmann wrote:
> Hi,
>
>> I'd like to configure a linux box using a USB bt dongle to talk to an ipaq
>> at 723kbps for streaming video. So two questions:
>
> what iPAQ is this?
2215 running ppc2003
>> 1. How can I tell at what rate the two bluetooth devices are talking? I
>> could use l2test if I could run linux on the ipaq, but I can't (yet).
>
>
> Buy a protocol analyser
Ok. ;-)
>> 2. How can I configure the two to talk at the assymetric 723kbps rate?
> In general this is not needed, because the link manager should choose
> the best package types for you.
I think it's not working for me. Here's my setup:
linux 2.6.2 + USB bluetooth dongle (Actiontec); no other USB devices
connected
# hciconfig -a
hci0: Type: USB
BD Address: 00:20:E0:3A:2E:57 ACL MTU: 2000:32 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN AUTH ENCRYPT
RX bytes:1717240 acl:19853 sco:0 events:99969 errors:0
TX bytes:25192308 acl:134411 sco:0 commands:57 errors:0
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: HOLD SNIFF PARK
Link mode: ACCEPT MASTER
Name: 'sermons.desiringGod.org-0'
Class: 0x000104
Service Classes: Unspecified
Device Class: Computer, Desktop workstation
HCI Ver: 1.1 (0x1) HCI Rev: 0x322 LMP Ver: 1.1 (0x1) LMP Subver: 0x322
Manufacturer: Cambridge Silicon Radio (10)
(The default ACL MTU is 192:8; I tried cranking it up to no avail.)
For a poor man's throughput test I'm downloading a 7M mpeg file, both
through Pocket IE and by having Pocket TV stream it from my 100Mbps LAN.
I'm running "nload -o 800 -t 250 xl0" and watching the outgoing avg in
kbit/s.
No matter what I do, the average caps out at about 265kbps. I've tried all
the following in various combinations:
hcitool cpt ipaqbdaddr dh5
hcitool cpt ipaqbdaddr dm5
hciconfig hci0 ptype dh5
hciconfig hci0 ptype dm5
hciconfig hci0 aclmtu 2000:32
Running "hcitool cpt ipaqbdaddr dm1" does slow the transfer down, but
nothing gets it going faster than 265kbps. I think I have a good link:
# hcitool rssi 00:04:3E:81:90:E0
RSSI return value: 0
# hcitool lq 00:04:3E:81:90:E0
Link quality: 255
# hcitool tpl 00:04:3E:81:90:E0
Current transmit power level: -8
Does all this mean that my ipaq has a slow UART?
Matt
P. S. Most of the ipaq 2215 docs are available at http://www.handhelds.org/platforms/hp/ipaq-h22xx/.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Steven,
> 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.
we know for sure that the 3870 has the problem with a too slow UART, but
the 3970 can go with full speed. So I assume that HP won't had this
problem with their newer 2xxx generation, but who knows :(
> 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.
Thanks for this explanation. It is good to know how and when the link
manager decides what packet types to use ;)
> 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.
Matt, please run "hcidump -w <file>" (as root) and post it to the list,
so Steven can take a look at it.
> 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.
It is possible, because they no longer can use BCSP and have to deal
with bit errors on H4.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
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.
http://www.mimesweeper.com
**********************************************************************
Hi Steven,
> >> # hcitool rssi 00:04:3E:81:90:E0
> >> RSSI return value: 0
> >> # hcitool lq 00:04:3E:81:90:E0
> >> Link quality: 255
> >> # hcitool tpl 00:04:3E:81:90:E0
> >> Current transmit power level: -8
> >>
> >>
> >> Does all this mean that my ipaq has a slow UART?
> >
> > No, because the link quality and the RSSI has nothing to do with the
> > choosen packet type.
>
> Marcel, I don't think this is what Matt meant. I think he was asking
> that given that the link quality and power levels are good and given
> that he can't get more that 265 kbps regardless of packet type, is it
> likely that he's being limited by some component of the system other
> than the Bluetooth link - such as the UART baud rate on the Ipaq.
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.
> Is there an easy way to find out what baud rate the Ipaq is using?
> That would answer the question straight away. 265 kbps over the air
> is equivalent to roughly 350 kbps over the UART (assuming one start bit,
> one stop bit, no parity and large HCI packets).
He said that it run Windows, so I can't tell :(
> 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?
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
> Matt wrote:
>> # hcitool rssi 00:04:3E:81:90:E0
>> RSSI return value: 0
>> # hcitool lq 00:04:3E:81:90:E0
>> Link quality: 255
>> # hcitool tpl 00:04:3E:81:90:E0
>> Current transmit power level: -8
>>
>>
>> Does all this mean that my ipaq has a slow UART?
>
> No, because the link quality and the RSSI has nothing to do with the
> choosen packet type.
Marcel, I don't think this is what Matt meant. I think he was asking
that given that the link quality and power levels are good and given
that he can't get more that 265 kbps regardless of packet type, is it
likely that he's being limited by some component of the system other
than the Bluetooth link - such as the UART baud rate on the Ipaq.
Is there an easy way to find out what baud rate the Ipaq is using?
That would answer the question straight away. 265 kbps over the air
is equivalent to roughly 350 kbps over the UART (assuming one start bit,
one stop bit, no parity and large HCI packets).
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.
- 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.
http://www.mimesweeper.com
**********************************************************************
Hi Matt,
> > what iPAQ is this?
>
> 2215 running ppc2003
please run "hcitool info <bdaddr>" to show us what kind of Bluetooth
chip is inside. I think it is a Zeevo one.
> > In general this is not needed, because the link manager should choose
> > the best package types for you.
>
> I think it's not working for me. Here's my setup:
It can happen, because some link managers only does this right when they
are connected to there own dongles.
> linux 2.6.2 + USB bluetooth dongle (Actiontec); no other USB devices
> connected
>
> # hciconfig -a
> hci0: Type: USB
> BD Address: 00:20:E0:3A:2E:57 ACL MTU: 2000:32 SCO MTU: 64:8
> UP RUNNING PSCAN ISCAN AUTH ENCRYPT
> RX bytes:1717240 acl:19853 sco:0 events:99969 errors:0
> TX bytes:25192308 acl:134411 sco:0 commands:57 errors:0
> Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: HOLD SNIFF PARK
> Link mode: ACCEPT MASTER
> Name: 'sermons.desiringGod.org-0'
> Class: 0x000104
> Service Classes: Unspecified
> Device Class: Computer, Desktop workstation
> HCI Ver: 1.1 (0x1) HCI Rev: 0x322 LMP Ver: 1.1 (0x1) LMP Subver: 0x322
> Manufacturer: Cambridge Silicon Radio (10)
>
> (The default ACL MTU is 192:8; I tried cranking it up to no avail.)
Don't change the MTU. This is not a value you can change. Leave it alone
until you really know what it does.
> For a poor man's throughput test I'm downloading a 7M mpeg file, both
> through Pocket IE and by having Pocket TV stream it from my 100Mbps LAN.
> I'm running "nload -o 800 -t 250 xl0" and watching the outgoing avg in
> kbit/s.
>
> No matter what I do, the average caps out at about 265kbps. I've tried all
> the following in various combinations:
>
> hcitool cpt ipaqbdaddr dh5
> hcitool cpt ipaqbdaddr dm5
> hciconfig hci0 ptype dh5
> hciconfig hci0 ptype dm5
> hciconfig hci0 aclmtu 2000:32
>
> Running "hcitool cpt ipaqbdaddr dm1" does slow the transfer down, but
> nothing gets it going faster than 265kbps. I think I have a good link:
The Bluetooth 1.2 spec makes it clear that the DM1 will be always
allowed not matter what you give as packet types.
> # hcitool rssi 00:04:3E:81:90:E0
> RSSI return value: 0
> # hcitool lq 00:04:3E:81:90:E0
> Link quality: 255
> # hcitool tpl 00:04:3E:81:90:E0
> Current transmit power level: -8
>
>
> Does all this mean that my ipaq has a slow UART?
No, because the link quality and the RSSI has nothing to do with the
choosen packet type.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users