[Bluez-devel] BECI

[Bluez-devel] BECI

[Andreas Merkle]

Hi Marcel,

is there any plan to support the upcoming BECI (Bluetooth Embedded Control 
Interface)? I know its not a working group at the moment but maybe next year.






-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Marcel Holtmann]

Hi Andreas,

> is there any plan to support the upcoming BECI (Bluetooth Embedded Control 
> Interface)? I know its not a working group at the moment but maybe next year.

I heard of this new interface, but unfortunately I haven't seen the
specification, yet. However I am pretty sure that we are going to
support it as soon as we have hardware to test it with.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Juergen Wichmann]

Hi all,

BECI is designeated as a Profile orientated Interface situated on top of profiles and protocols
to interact with aplications.
So its not a question of hardware.
However since a working group has not been established yet no specs exist.

br
Juergen Wichmann

> -----Original Message-----
> From: bluez-devel-bounces@lists.sourceforge.net
> [mailto:bluez-devel-bounces@lists.sourceforge.net]On Behalf Of Marcel
> Holtmann
> Sent: Tuesday, November 28, 2006 5:25 AM
> To: BlueZ development
> Subject: Re: [Bluez-devel] BECI
> 
> 
> Hi Andreas,
> 
> > is there any plan to support the upcoming BECI (Bluetooth 
> Embedded Control 
> > Interface)? I know its not a working group at the moment 
> but maybe next year.
> 
> I heard of this new interface, but unfortunately I haven't seen the
> specification, yet. However I am pretty sure that we are going to
> support it as soon as we have hardware to test it with.
> 
> Regards
> 
> Marcel
> 
> 
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Marcel Holtmann]

Hi Juergen,

> BECI is designeated as a Profile orientated Interface situated on top of profiles and protocols
> to interact with aplications.
> So its not a question of hardware.
> However since a working group has not been established yet no specs exist.

I heard about BECI and actually my understanding is that stuff like
L2CAP and RFCOMM can run on the Bluetooth chip itself and doesn't needed
to be implemented in the actual host OS. However my tip is that someone
might simply have a look at our D-Bus based API, because we designed all
methods and signals from the viewpoint of the applications. It has
become one of the easiest to use abstractions, I have seen so far.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Andreas Merkle]

Hi Marcel,

> 
> Hi Juergen,
> 
> > BECI is designeated as a Profile orientated Interface situated on top of 
profiles and protocols
> > to interact with aplications.
> > So its not a question of hardware.
> > However since a working group has not been established yet no specs exist.
> 
> I heard about BECI and actually my understanding is that stuff like
> L2CAP and RFCOMM can run on the Bluetooth chip itself and doesn't needed
> to be implemented in the actual host OS. However my tip is that someone
> might simply have a look at our D-Bus based API, because we designed all
> methods and signals from the viewpoint of the applications. It has
> become one of the easiest to use abstractions, I have seen so far.
> 

the BECI functionality will include all Bluetooth features and 
support both multi-profile and Multilink application. 
Its just like the HCI interface but on a higher level.
One of the advantage is that you can implement L2CAP, RFCOMM etc.
into a chip ... thats right.

How fast it will be a working group is a political issue at the
moment. But if its a working group we can suggest the D-Bus API.

Regards
Andreas



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Chafik Moalem]

[-- Attachment #1.1.1: Type: text/plain, Size: 2265 bytes --]

Hi Marcel,

hmmm ... as I understood so far : 
a BECI Module with the right abstraction API (dbus) might "replace"
bluez then ?

btw.: I am currently working with a uart module which has already a
complete BT-Stack with profiles and all the needed logic implemented
"inside" a CSR BC03MM ! All I need to do is initiate profile, initiate
connection (implicit pairing), open SCO et voila : I have a nice
PCM-eSCO connection to my HS ! just testing concurrent connections at
the moment (SPP + HSP)

Just have a look at
 http://www.lintech.de/index.php?index=19&pc=4&p=36  
.. the datasheet is "on click" 

when they talk about "API" they mean a simple serial (uart) message
format :)
Well if I have a bit more time I should try to implement a "special"
uart<->dbus layer ... i think it is something pre-BECI !

Did you hear about other modules already implementing such intelligent
subsystems and already available?

regards
Chafik

Am Dienstag, den 28.11.2006, 18:53 +0100 schrieb Marcel Holtmann:

> Hi Juergen,
> 
> > BECI is designeated as a Profile orientated Interface situated on top of profiles and protocols
> > to interact with aplications.
> > So its not a question of hardware.
> > However since a working group has not been established yet no specs exist.
> 
> I heard about BECI and actually my understanding is that stuff like
> L2CAP and RFCOMM can run on the Bluetooth chip itself and doesn't needed
> to be implemented in the actual host OS. However my tip is that someone
> might simply have a look at our D-Bus based API, because we designed all
> methods and signals from the viewpoint of the applications. It has
> become one of the easiest to use abstractions, I have seen so far.
> 
> Regards
> 
> Marcel
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel

[-- Attachment #1.1.2: Type: text/html, Size: 3666 bytes --]

[-- Attachment #1.2: smiley-3.png --]
[-- Type: image/png, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BECI

[Marcel Holtmann]

Hi Chafik,

> hmmm ... as I understood so far : 
> a BECI Module with the right abstraction API (dbus) might "replace"
> bluez then ?

or we write a daemon that maps our D-Bus base API over BECI and all
application using our API will working on top of both.

> btw.: I am currently working with a uart module which has already a
> complete BT-Stack with profiles and all the needed logic implemented
> "inside" a CSR BC03MM ! All I need to do is initiate profile, initiate
> connection (implicit pairing), open SCO et voila : I have a nice
> PCM-eSCO connection to my HS ! just testing concurrent connections at
> the moment (SPP + HSP)
> 
> Just have a look at
> http://www.lintech.de/index.php?index=19&pc=4&p=36  
> .. the datasheet is "on click" 

I know these kind of systems. Their usage always depends on how much
control you want and actually need.

> when they talk about "API" they mean a simple serial (uart) message
> format :)

No idea.

> Well if I have a bit more time I should try to implement a "special"
> uart<->dbus layer ... i think it is something pre-BECI !

Feel free to do so.

> Did you hear about other modules already implementing such intelligent
> subsystems and already available?

Almost every Bluetooth chip manufacturer provides a serial port profile
module somehow.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] two concurrent a2dp connections

[Sergey Krivov]

Hi,

i am trying to work with two a2dp streams at the same
time. if i do it in the following way it works.
first way (schematically,):

lacp=[] # list of ACP
stream1=connect(addr1)
lacp.append(stream1)
stream2=connect(addr2) 
lacp.append(stream)


if i do it in a different way it does not.
here i advertise a2dp just to get the address
of the units. if i have more than two units the sound
is destroyed completely.  

second way (schematically):
lacp=[]
while true:
    sock2,addr,port=advertise_a2dp()
    avdtp_discover_abort(sock2)  
    sock2.close()
    lacp.append(connect(addr))

using hcidump i found that in the first case the media
packets are send more or less synchronously:
grep of hcidump output gives:
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0041 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]

for the second case i get:
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x006b len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]
    L2CAP(d): cid 0x0042 len 621 [psm 0]

what might be the difference between the two cases.
Didnt i set up some socket options? 
Any help is appreciated!


 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel