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

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

[grpmind+bluez.users]

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:

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).

2. How can I configure the two to talk at the assymetric 723kbps rate? 
 
Thanks for any help you can give.
 
Matt


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

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?

> 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 ;)

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

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Michel Planques]

Hi Marcel,

l2test is a good tool to generate Bluetooth traffic between 2 linux
stations. You can also use the PAN profile with bnep protocol and a
TCP/UDP traffic generator : I suggest iperf (it works on Linux and
Windows). I followed these two methods and the results were similar.

I had some bad experiences with the packet type choosen by my dongle's
link manager. I had to force the packet type to DH5 reach the maximum bit
rate.



Michel.

> 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?
>
>> 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 ;)
>
>> 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.
>
> 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

Hi Michel,

> l2test is a good tool to generate Bluetooth traffic between 2 linux
> stations. You can also use the PAN profile with bnep protocol and a
> TCP/UDP traffic generator : I suggest iperf (it works on Linux and
> Windows). I followed these two methods and the results were similar.

of course l2test is one of the best tools, but in case of some iPAQ's
you have the problem that the UART is too slow and you will never reach
the full Bluetooth bandwidth ;)

> I had some bad experiences with the packet type choosen by my dongle's
> link manager. I had to force the packet type to DH5 reach the maximum bit
> rate.

This is one of the biggest problem with bad link managers. I have seen
this very often :(

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[grpmind+bluez.users]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[grpmind+bluez.users]

Marcel wrote:

> please run "hcitool info <bdaddr>" to show us what kind of Bluetooth
> chip is inside. I think it is a Zeevo one.

$ hcitool info 00:04:3E:81:90:E0
Requesting information ...
        BD Address:  00:04:3E:81:90:E0
        Device Name: Pocket_PC
        LMP Version: 1.1 (0x1) LMP Subversion: 0x8d
        Manufacturer: Telencomm Inc. (18)
        Features: 0xff 0xff 0x05 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link>
                <HV2 packets> <HV3 packets> <u-law log> <A-law log>
                <CVSD> <power control>

The folks at handhelds.org think it's a Zeevo:
http://www.handhelds.org/platforms/hp/ipaq-h22xx/tc2k_public.pdf

> It can happen, because some link managers only does this right when they
> are connected to there own dongles.

Do you know which dongles have bad link managers?

Thanks for your help.

Matt


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[grpmind+bluez.users]

Steven Singer wrote:

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

Steve's right. What I meant by "all this" was everything I had written,
not just the part about rssi, lq, and tpl.

> 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).

Not presently, because it is running Pocket PC 2003. (If there is a way to
tell with PPC, let me know.) Hopefully soon Linux will be running well
on it and then maybe I could tell you; it is booting but not everything
works yet. Maybe http://michaelo.free.fr/pda/h2210/starterkit/bootlog
would give you an idea.

This is an ipaq 2215, which has Intel's PXA255 processor, which according
to the docs has a 920Kbps interface. But I suppose that doesn't mean HP
hooked it up optimally.

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

Could I use hcidump to tell what's going on?

Matt


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

Hi Matt,

> > please run "hcitool info <bdaddr>" to show us what kind of Bluetooth
> > chip is inside. I think it is a Zeevo one.
> 
> $ hcitool info 00:04:3E:81:90:E0
> Requesting information ...
>         BD Address:  00:04:3E:81:90:E0
>         Device Name: Pocket_PC
>         LMP Version: 1.1 (0x1) LMP Subversion: 0x8d
>         Manufacturer: Telencomm Inc. (18)
>         Features: 0xff 0xff 0x05 0x00 0x00 0x00 0x00 0x00
>                 <3-slot packets> <5-slot packets> <encryption> <slot offset>
>                 <timing accuracy> <role switch> <hold mode> <sniff mode>
>                 <park state> <RSSI> <channel quality> <SCO link>
>                 <HV2 packets> <HV3 packets> <u-law log> <A-law log>
>                 <CVSD> <power control>
> 
> The folks at handhelds.org think it's a Zeevo:
> http://www.handhelds.org/platforms/hp/ipaq-h22xx/tc2k_public.pdf

it is a Zeevo chip, but it is the old generation and I had not very good
experiences with it.

> > It can happen, because some link managers only does this right when they
> > are connected to there own dongles.
> 
> Do you know which dongles have bad link managers?

It is not the dongle itself. It is the firmware inside and it is a
problem of both sides. It is safe to fallback to DM1, but this means
that the bandwith will be decreased. If you have chips from the same
manufacturer on both sides everything is almost fine. Personally I
prefer CSR chips, because they cause less troubles. But to decide which
side is doing bad on the link manager, you must use a protocol analyser.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Steven Singer]

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.

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

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

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

Hi Matt,

> > 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.
> 
> Could I use hcidump to tell what's going on?

No. You need a protocol analyser for this.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Paulo Marques]

grpmind+bluez.users@boromir.vpop.net wrote:

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


What profile are you using? LAN or PAN?

If you're using LAN you should really try using PAN. I don't trust the micro$oft 
stack at all. The simpler the profile, the most likely it is to work ok.

> Does all this mean that my ipaq has a slow UART

It's strange... a slow UART should be 230400 or 460800 baud. If it were 230400 
you shouldn't get a bandwidth as high as you're getting. If it were 460800 you'd 
probably be a little higher.

Of course, this is no proof that the UART is in fact the culprit.

-- 
Paulo Marques
Software Development Department - Restinfor, Lda.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"In a world without walls and fences who needs windows and gates?"



-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Matthew Reimer]

Paulo Marques wrote:
> grpmind+bluez.users@boromir.vpop.net wrote:
> 
>>
>> 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:
> 
> 
> 
> What profile are you using? LAN or PAN?

I think I'm using PAN (what PPC2003 and sdptool call "Network Access 
Point"). Is that what you mean?


> If you're using LAN you should really try using PAN. I don't trust the 
> micro$oft stack at all. The simpler the profile, the most likely it is 
> to work ok.
> 
>> Does all this mean that my ipaq has a slow UART
> 
> 
> It's strange... a slow UART should be 230400 or 460800 baud. If it were 
> 230400 you shouldn't get a bandwidth as high as you're getting. If it 
> were 460800 you'd probably be a little higher.
> 
> Of course, this is no proof that the UART is in fact the culprit.

Yes, it is perplexing. I'm waiting to hear back from knowledgeable 
people about how the bluetooth chip is connected.

Matt


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Steven Singer]

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

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

[Marcel Holtmann]

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Matthew Reimer]

Steven Singer wrote:
> 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.

Yes, you read my message correctly.

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

Correct; that was all from the linux side where the CSR device 
(Actiontec USB dongle) is connected.

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

Can I change the L2CAP MTU? Is that different than the ACL MTU that can 
be set via hciconfig? Can I get "an HCI trace" with hcidump, or is that 
what a protocol analyzer would be needed for?

I'm using the NAP profile (sorry for not mentioning that).

> 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

Thanks for your insights!

Matt


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

Hi Matt,

> Can I change the L2CAP MTU? Is that different than the ACL MTU that can 
> be set via hciconfig? Can I get "an HCI trace" with hcidump, or is that 
> what a protocol analyzer would be needed for?

you can change L2CAP MTU, but in case of RFCOMM or BNEP the correct one
will be choosen for you.

Run "hcidump -w <file>" (as root).

> I'm using the NAP profile (sorry for not mentioning that).

The old 3870 and 3970 series only supports LAN access using PPP, but we
will see in your dump file what you are using.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Matthew Reimer]

[-- Attachment #1: Type: text/html, Size: 1601 bytes --]

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

[Matthew Reimer]

Matthew Reimer wrote:
> Marcel Holtmann wrote:
> 
>>Run "hcidump -w <file>" (as root).
>>  
>>
> Ok, it's at http://sermons.desiringGod.org/~mreimer/h2215.dump. It's 
> large (11M), but I thought that it would be better to give you more info 
> than less. This is what I did:
> 
> 1. linux: start hcidump
> 2. ipaq: start a NAP session from PocketPC2003 to the linux box
> 3. ipaq: start PocketIE and began downloading a movie trailer
> 4. ipaq: stopped the download after a minute or so
> 5. ipaq: disconnected the NAP connection, then turned off bluetooth
> 6. linux: stopped the dump
> 
> My Actiontec dongle is 00:20:E0:3A:2E:57 and the ipaq is 00:04:3E:81:90:E0.
> 
> Let me know if there might be sensitive information in this dump so I 
> can respond appropriately. I hope this info helps.
> 
> Matt

BTW, the bluetooth dongle on the linux box was in its normal state:

$ hciconfig -a
hci0:   Type: USB
         BD Address: 00:20:E0:3A:2E:57 ACL MTU: 192:8  SCO MTU: 64:8
         UP RUNNING PSCAN ISCAN AUTH ENCRYPT
         RX bytes:2825848 acl:32991 sco:0 events:161779 errors:0
         TX bytes:42819062 acl:228294 sco:0 commands:117 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)

Matt

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

[Matthew Reimer]

Steven Singer wrote:
> 
[snip]
> 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

I think the UART speed hypothesis is right.

I did some further tests and got up to 340kbps over PAN. I think 
Activesync might have been getting in the way in my previous tests where 
I was only getting ~265kbps.

Then I used haret to read the UART registers and this is what I found:

   BTDLL 0x40200000      0x02
   BTDLH 0x40200004      0x00

   So if the baud rate = 14.7456MHz / (16 * (BTDLH << 8 | BTDLL))

then PPC2003 is programming the UART for 460800 bps.

I also got verification from Jamey Hicks at HP/CRL that the bluetooth 
part is hooked up to the pxa255's bluetooth serial port, so there should 
be plenty of bandwidth available there (921.6kbps).

I tried setting the divisor to 1 manually, but then bluetooth wouldn't 
work. Maybe PPC2003 isn't fast enough to handle interrupts at that rate?

I've included the rest of the register dump at the end in case there's 
anything else interesting there. I don't know much about serial 
programming, so I don't know what everything means, but it was 
interesting that DMA requests are disabled. Maybe if PPC2003's 
implementation used DMA, higher throughput could be achieved?

Matt




   BTIER 0x40200004      0x5d    receiver data avail int enabled |
                                 transmit FIFO data req int disabled |
                                 receiver line status int enabled |
                                 modem status int enabled |
                                 char timeout indication int enabled |
                                 NRZ coding disabled |
                                 UART unit enabled
                                 DMA requests are disabled

   BTIIR 0x40200008      0xc1    FIFO mode enable status = reserved (?) |
                                 no int pending
   BTFCR (write only)
   BTLCR 0x4020000c      0x03    DLAB = 0 | set break = 0 | sticky 
parity = 0 |
                                 even parity select = 0 (meaning odd 
parity) |
                                 parity enable = 0 (meaning no parity) |
                                 stop bits = 0 (meaning 1 stop bit) |
                                 word length select = 0x03 (meaning 
8-bit char)

   BTMCR 0x40200010      0x0b    dtr = 1 | rts = 1 | out1 = 0 | out2 = 1 |
                                 LOOP = 0

   BTLSR 0x40200014      0x60    FIFO err status = 0 | transmitter empty 
= 1 |
                                 transmit data req = 1 | break int = 0 |
                                 framing error = 0 | parity error = 0 |
                                 overrun error = 0 | data ready = 0

   BTMSR 0x40200018      0x10    dcts = 0 | ddsr = 0 | teri = 0 | ddcd = 1 |
                                 cts = 1 | dsr = 0 | ri = 0 | dcd = 0

   BTSPR 0x4020001c      0x00
   BTISR 0x40200020      0x00    xmitir = 0 | rcveir = 0 | xmode = 0 |
                                 txpl = 0 | rxpl = 0




-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Paulo Marques]

Matthew Reimer wrote:

> 
> I tried setting the divisor to 1 manually, but then bluetooth wouldn't 
> work. Maybe PPC2003 isn't fast enough to handle interrupts at that rate?
> 

That wouldn't work because the zeevo chip would also have to be configured for 
921.6kbps. AFAIK only modems try hard to autodetected baudrate from the "at" 
command string.

There is probably a good reason for the HP guys to set up the port like that. If 
it would work at 921.6kbps they would probably use the extra bandwidth. This is 
really a shame, because I was thinking of buying a 2215 myself, but I would like 
to have a "full-speed" bluetooth (and Linux support) :(

-- 
Paulo Marques
Software Development Department - Restinfor, Lda.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"In a world without walls and fences who needs windows and gates?"



-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users