9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] bluetooth
@ 2009-09-22 19:34 Skip Tavakkolian
  2009-09-22 22:33 ` Patrick Kelly
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Skip Tavakkolian @ 2009-09-22 19:34 UTC (permalink / raw)
  To: 9fans

anyone looked at this or given it any thought?




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-22 19:34 [9fans] bluetooth Skip Tavakkolian
@ 2009-09-22 22:33 ` Patrick Kelly
  2009-09-23  0:53 ` dave.l
  2009-09-23 14:37 ` Richard Miller
  2 siblings, 0 replies; 25+ messages in thread
From: Patrick Kelly @ 2009-09-22 22:33 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


On Sep 22, 2009, at 3:34 PM, Skip Tavakkolian wrote:

> anyone looked at this or given it any thought?

I was going to check into it after I did some tests in the audio
system. Although I probably won't finish my tests till early-mid
october.
>
>




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-22 19:34 [9fans] bluetooth Skip Tavakkolian
  2009-09-22 22:33 ` Patrick Kelly
@ 2009-09-23  0:53 ` dave.l
  2009-09-23 14:48   ` Richard Miller
  2009-09-23 14:37 ` Richard Miller
  2 siblings, 1 reply; 25+ messages in thread
From: dave.l @ 2009-09-23  0:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

A very superficial glance a long time ago suggested that it was a
twisty little maze of de-facto and de-vulgus standards.
i.e. the death of a thousand committees.

Then there's the hardware ...

On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote:

> anyone looked at this or given it any thought?
>
>




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-22 19:34 [9fans] bluetooth Skip Tavakkolian
  2009-09-22 22:33 ` Patrick Kelly
  2009-09-23  0:53 ` dave.l
@ 2009-09-23 14:37 ` Richard Miller
  2009-09-23 16:10   ` Skip Tavakkolian
  2009-09-23 17:54   ` Skip Tavakkolian
  2 siblings, 2 replies; 25+ messages in thread
From: Richard Miller @ 2009-09-23 14:37 UTC (permalink / raw)
  To: 9fans

> anyone looked at this or given it any thought?

I've been working on a bluetooth implementation which should be
ready for initial release soon.  Just the core communication layers
(usb-hci transport, hci, l2cap, rfcomm), and fairly rudimentary:
I've tried to pick a minimal useful subset rather than support
the whole 1420-page Core V2.1+EDR standard.

The interface follows the normal Plan 9 /net model, so the usual
dial/announce/listen operations work pretty much as expected,
and you can do things like:

  aux/listen1 bt!*!77 /bin/exportfs
  import -A bt!00123456789A!77 / /n/blue

A bit of tweaking to cs(8) would allow the use of "friendly"
device names in place of 12-hexdigit bluetooth device addresses.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23  0:53 ` dave.l
@ 2009-09-23 14:48   ` Richard Miller
  2009-09-24 20:40     ` dave.l
  0 siblings, 1 reply; 25+ messages in thread
From: Richard Miller @ 2009-09-23 14:48 UTC (permalink / raw)
  To: 9fans

> A very superficial glance a long time ago suggested that it was a
> twisty little maze of de-facto and de-vulgus standards.
> i.e. the death of a thousand committees.

The core standard (defining the communication layers) is actually
not too bad, compared to some I've had to look at.  It's huge, but
a lot of it is describing low-level radio stuff (below the hci layer)
which your bluetooth chip takes care of.

All the "profiles" (application layers) have their own separate
standards documents, and there indeed is a morass of (non)design
by committee.

> Then there's the hardware ...

Maybe I was lucky, but my random choice of development hardware
(a cheap generic usb dongle with a CSR chip) has seemed to behave
just as the spec says.  Of course there have been surprises, but
so far these have been where the spec was ambiguous and my guess
didn't match the firmware designer's guess.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 14:37 ` Richard Miller
@ 2009-09-23 16:10   ` Skip Tavakkolian
  2009-09-23 17:54   ` Skip Tavakkolian
  1 sibling, 0 replies; 25+ messages in thread
From: Skip Tavakkolian @ 2009-09-23 16:10 UTC (permalink / raw)
  To: 9fans

>   aux/listen1 bt!*!77 /bin/exportfs
>   import -A bt!00123456789A!77 / /n/blue

beautiful!




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 14:37 ` Richard Miller
  2009-09-23 16:10   ` Skip Tavakkolian
@ 2009-09-23 17:54   ` Skip Tavakkolian
  2009-09-23 17:57     ` Francisco J Ballesteros
  2009-09-23 18:11     ` Richard Miller
  1 sibling, 2 replies; 25+ messages in thread
From: Skip Tavakkolian @ 2009-09-23 17:54 UTC (permalink / raw)
  To: 9fans

>   import -A bt!00123456789A!77 / /n/blue

what does the device id discovery look like?




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 17:54   ` Skip Tavakkolian
@ 2009-09-23 17:57     ` Francisco J Ballesteros
  2009-09-23 18:11     ` Richard Miller
  1 sibling, 0 replies; 25+ messages in thread
From: Francisco J Ballesteros @ 2009-09-23 17:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

If it's useful, I'd love to beta test or alpha test or whatever.

thanks a lot for your effort!



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 17:54   ` Skip Tavakkolian
  2009-09-23 17:57     ` Francisco J Ballesteros
@ 2009-09-23 18:11     ` Richard Miller
  2009-09-23 20:57       ` Skip Tavakkolian
  1 sibling, 1 reply; 25+ messages in thread
From: Richard Miller @ 2009-09-23 18:11 UTC (permalink / raw)
  To: 9fans

> what does the device id discovery look like?

At present:

	echo inquiry M N >/net/bt/ctl
(spend up to M seconds looking for up to N devices)
	cat /n/bt/devices
(see what devices have been found)




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 18:11     ` Richard Miller
@ 2009-09-23 20:57       ` Skip Tavakkolian
  2009-09-24  4:33         ` lucio
  2009-09-24  8:22         ` Richard Miller
  0 siblings, 2 replies; 25+ messages in thread
From: Skip Tavakkolian @ 2009-09-23 20:57 UTC (permalink / raw)
  To: 9fans

> 	echo inquiry M N >/net/bt/ctl
> (spend up to M seconds looking for up to N devices)
> 	cat /n/bt/devices
> (see what devices have been found)

the application i have in mind inventories all device id's it sees
with a time stamp.  i need to measure the flow between two endpoints
based on the id/timestamp.  i was thinking of something like this:

while (sleep 1) {
	echo `{ls /net/bt/ids}^'@'^`{date -n}
}

i've not considered the pros/cons of each approach.

thank you for doing this. like nemo, i'd like to offer testing.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 20:57       ` Skip Tavakkolian
@ 2009-09-24  4:33         ` lucio
  2009-09-24  8:22         ` Richard Miller
  1 sibling, 0 replies; 25+ messages in thread
From: lucio @ 2009-09-24  4:33 UTC (permalink / raw)
  To: 9fans

> thank you for doing this. like nemo, i'd like to offer testing.

To echo nemo and skip, I do own one USB bluetooth radio and many
mobile handsets.  Count me in, if you wish.

++L




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 20:57       ` Skip Tavakkolian
  2009-09-24  4:33         ` lucio
@ 2009-09-24  8:22         ` Richard Miller
  2009-09-24 11:03           ` Nathaniel W Filardo
                             ` (3 more replies)
  1 sibling, 4 replies; 25+ messages in thread
From: Richard Miller @ 2009-09-24  8:22 UTC (permalink / raw)
  To: 9fans

>> 	cat /n/bt/devices
>> (see what devices have been found)

Typo - should be /net/bt/devices - currently gives you device address,
class, and friendly name for all "known" devices (see below).  First
on list is self.

term% cat /net/bt/devices
00025b0011bf 020104 'atom'
00236c9dd69f 38010c 'Richard Miller’s MacBook'

> the application i have in mind inventories all device id's it sees
> with a time stamp.

What do you mean exactly by "sees"?  A device may be known
because it responded to an inquiry (probe for all devices) or a
page (probe for specific device), or because it sent you an inquiry
or a page, or because you paired with the device at some time in
the past and have a stored link key for it.  [A device may be set
to respond to page but not inquiry.  Or vice versa.]

> while (sleep 1) {
> 	echo `{ls /net/bt/ids}^'@'^`{date -n}
> }

The hardware can automatically do periodic inquiry scans in the
background.  I could add a command 'inquiry auto N' to enable this
(but I guess you would still need a 'sleep' loop to look at the
devices file).

Advice sought:
1. Would it be helpful to have a timestamp in the devices record to
give the time the device was last seen (for some value of "seen")?
2. When should a device disappear from the /net/bt/devices list?




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24  8:22         ` Richard Miller
@ 2009-09-24 11:03           ` Nathaniel W Filardo
  2009-09-24 13:59             ` Richard Miller
  2009-09-24 15:30           ` rsc
                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 25+ messages in thread
From: Nathaniel W Filardo @ 2009-09-24 11:03 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2227 bytes --]

On Thu, Sep 24, 2009 at 09:22:17AM +0100, Richard Miller wrote:
> What do you mean exactly by "sees"?  A device may be known
> because it responded to an inquiry (probe for all devices) or a
> page (probe for specific device), or because it sent you an inquiry
> or a page, or because you paired with the device at some time in
> the past and have a stored link key for it.  [A device may be set

Shouldn't factotum be in charge of storing keys?  Or do you mean just
keys that happen to be resident in the stack right now?

> to respond to page but not inquiry.  Or vice versa.]
> 
> > while (sleep 1) {
> > 	echo `{ls /net/bt/ids}^'@'^`{date -n}
> > }
> 
> The hardware can automatically do periodic inquiry scans in the
> background.  I could add a command 'inquiry auto N' to enable this
> (but I guess you would still need a 'sleep' loop to look at the
> devices file).
> 
> Advice sought:
> 1. Would it be helpful to have a timestamp in the devices record to
> give the time the device was last seen (for some value of "seen")?
> 2. When should a device disappear from the /net/bt/devices list?

How about exposing things as an ndb db so that we can add fields as the
need arises?
  mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp
  active=rfcomm3, sdp=pan,rfcomm,...,...
(that might be a bad example, if sdp is done by a separate daemon, e.g.;
am just musing).

What about letting me set a stored key by writing a line into this as a
single write of "mac=... !secret=0x..." ala factotum's ctl file?

Oh hey... why not make the file also act like the sound mixers and jccfs
journals?  That is, just stream events out to readers, starting with a full
enumeration and then updates, then the "you are about to block" empty read,
then block until the next scan or timeout which changes something.

You can give an advisory signal (mac=... gone= or somesuch) that a device
should be considered gone (and purge it from the list you'd report to a
fresh client) after some small time interval... something between 5 and 30
seconds seems reasonable to me?  People watching the event stream are free
to do their own thing.

Does that seem reasonable?
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 11:03           ` Nathaniel W Filardo
@ 2009-09-24 13:59             ` Richard Miller
  2009-09-24 20:05               ` Steve Simon
  0 siblings, 1 reply; 25+ messages in thread
From: Richard Miller @ 2009-09-24 13:59 UTC (permalink / raw)
  To: 9fans

>> ... or because you paired with the device at some time in
>> the past and have a stored link key for it.
>
> Shouldn't factotum be in charge of storing keys?  Or do you mean just
> keys that happen to be resident in the stack right now?

No, I mean keys which are kept in non-volatile store inside the
bluetooth chip.  The BT firmware kindly does this for you.

This means when you buy a secondhand phone, put a new SIM card
in it, and wipe its memory, it may still be paired with random
devices from its previous life.

> How about exposing things as an ndb db so that we can add fields as the
> need arises?
>   mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp
>   active=rfcomm3, sdp=pan,rfcomm,...,...
> (that might be a bad example, if sdp is done by a separate daemon, e.g.;
> am just musing).

I think this is mixing too many unrelated things together.  Sdp is another
layer (like dns), and if you want to see active connections you can
use netstat.  /net/bt/devices is simply for relating names to addresses,
like /net/arp.

> What about letting me set a stored key by writing a line into this as a
> single write of "mac=... !secret=0x..." ala factotum's ctl file?

Where would you get the key from?  Link keys are generated internally
during the pairing transaction between devices.  The PIN used for pairing
is supplied by the user with a command to /net/bt/ctl, but this will be
different each time so there's no point giving it to factotum.

> You can give an advisory signal (mac=... gone= or somesuch) that a device
> should be considered gone (and purge it from the list you'd report to a
> fresh client) after some small time interval... something between 5 and 30
> seconds seems reasonable to me?  People watching the event stream are free
> to do their own thing.

I can't see a compelling application for this but maybe I'm unimaginative.
If you are connected to a device and it disappears you'll get a hangup.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24  8:22         ` Richard Miller
  2009-09-24 11:03           ` Nathaniel W Filardo
@ 2009-09-24 15:30           ` rsc
  2009-09-24 15:57             ` Richard Miller
  2009-09-24 19:06           ` Skip Tavakkolian
  2010-04-26 18:09           ` Skip Tavakkolian
  3 siblings, 1 reply; 25+ messages in thread
From: rsc @ 2009-09-24 15:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 00236c9dd69f 38010c 'Richard Miller’s MacBook'

I was going to comment that you should use %q instead of '%s'
but now I notice that the apostrophe is 0x2019 not a simple '.
Does Bluetooth specify UTF-8 as the string encoding sent over
the network?

Russ


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 15:30           ` rsc
@ 2009-09-24 15:57             ` Richard Miller
  0 siblings, 0 replies; 25+ messages in thread
From: Richard Miller @ 2009-09-24 15:57 UTC (permalink / raw)
  To: 9fans

> I was going to comment that you should use %q instead of '%s'

I do, of course.  The funny apostrophe was MacOS's idea.

> Does Bluetooth specify UTF-8 as the string encoding sent over
> the network?

No, just that the device name is encoded as UTF-8 (up to 248 octets).




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24  8:22         ` Richard Miller
  2009-09-24 11:03           ` Nathaniel W Filardo
  2009-09-24 15:30           ` rsc
@ 2009-09-24 19:06           ` Skip Tavakkolian
  2009-09-25 10:11             ` Richard Miller
  2010-04-26 18:09           ` Skip Tavakkolian
  3 siblings, 1 reply; 25+ messages in thread
From: Skip Tavakkolian @ 2009-09-24 19:06 UTC (permalink / raw)
  To: 9fans

> What do you mean exactly by "sees"?  A device may be known
> because it responded to an inquiry (probe for all devices)

all devices that are listening on inquiry scan channels and respond to
inquiry requests.  (i'm just learning the details and my terminology
may be a bit off).




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 13:59             ` Richard Miller
@ 2009-09-24 20:05               ` Steve Simon
  2009-09-25 10:23                 ` Richard Miller
  0 siblings, 1 reply; 25+ messages in thread
From: Steve Simon @ 2009-09-24 20:05 UTC (permalink / raw)
  To: 9fans

Fantastic work Richard, I too will be very interested in playing
with this once you are ready.

The only one thought - probably not mentioned as it is so obvious,
it would be neat if the plumber and thus auth/fgui could be pressed
into service for entering the pairing PIN.

-Steve



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-23 14:48   ` Richard Miller
@ 2009-09-24 20:40     ` dave.l
  2009-09-25 10:48       ` Richard Miller
  0 siblings, 1 reply; 25+ messages in thread
From: dave.l @ 2009-09-24 20:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks a million for all your work on this:
it means I'll probably be running plan9 seriously soon:-).

To be selfish for a moment ...
Presumably there's still a medium sized asteroid of pain to go through
to get something like,
say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
working sensibly?

Oh, and we'll need more drivers which will need to be more complex and
more efficient and less buggy
while driving more, and more divergent hardware which is becoming ever
more complex and bigger and buggier,
of course.

OTOH, of course, we do at least have the wonderfully clean plan9 view
of all this contortionous mess,
so at least when I need to push an avrcp driver onto my stack,
I can manipulate and see the hideous vipers nest in userland and prod
it with rc.

Plus, of course, it'll be totally dandy for connecting my plan9
wristputer to my plan9 briefcase.

Well done again.

D

On 23 Sep 2009, at 15:48, Richard Miller wrote:

>> A very superficial glance a long time ago suggested that it was a
>> twisty little maze of de-facto and de-vulgus standards.
>> i.e. the death of a thousand committees.
>
> The core standard (defining the communication layers) is actually
> not too bad, compared to some I've had to look at.  It's huge, but
> a lot of it is describing low-level radio stuff (below the hci layer)
> which your bluetooth chip takes care of.
>
> All the "profiles" (application layers) have their own separate
> standards documents, and there indeed is a morass of (non)design
> by committee.
>
>> Then there's the hardware ...
>
> Maybe I was lucky, but my random choice of development hardware
> (a cheap generic usb dongle with a CSR chip) has seemed to behave
> just as the spec says.  Of course there have been surprises, but
> so far these have been where the spec was ambiguous and my guess
> didn't match the firmware designer's guess.
>
>



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 19:06           ` Skip Tavakkolian
@ 2009-09-25 10:11             ` Richard Miller
  2009-09-25 11:30               ` matt
  0 siblings, 1 reply; 25+ messages in thread
From: Richard Miller @ 2009-09-25 10:11 UTC (permalink / raw)
  To: 9fans

>> What do you mean exactly by "sees"? ...
>
> all devices that are listening on inquiry scan channels and respond to
> inquiry requests.

It looks like your requirement might be satisfied by one or
the other of these things in the /net/bt/devices record:

- a discoverable (ie "responded to most recent inquiry") flag
- a timestamp for last inquiry response received (1 second resolution?)

I'm reluctant to remove devices altogether when they don't
respond to inquiry, because it may still be possible to
connect to a non-discoverable device by paging its address.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 20:05               ` Steve Simon
@ 2009-09-25 10:23                 ` Richard Miller
  0 siblings, 0 replies; 25+ messages in thread
From: Richard Miller @ 2009-09-25 10:23 UTC (permalink / raw)
  To: 9fans

> it would be neat if the plumber and thus auth/fgui could be pressed
> into service for entering the pairing PIN.

I don't quite see the connection between plumber and fgui - doesn't
fgui just read directly from /mnt/factotum/needkey?

At present there's a needkey-like mechanism for PINs - the equivalent
of fgui is this simple rc loop:

	while (bd=`{read </net/bt/pinreq}) {
		echo -n enter PIN for device `{grep $bd /net/bt/devices} ' : '
		pin=`{read}
		~ $pin '' || echo pin $bd $pin >/net/bt/ctl
	}

But now you mention it, using the plumber seems a good idea, so we
could pop up a new window to ask for a PIN when needed.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24 20:40     ` dave.l
@ 2009-09-25 10:48       ` Richard Miller
  0 siblings, 0 replies; 25+ messages in thread
From: Richard Miller @ 2009-09-25 10:48 UTC (permalink / raw)
  To: 9fans

> Presumably there's still a medium sized asteroid of pain to go through
> to get something like,
> say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
> working sensibly?

A2DP will need synchronous connections which aren't implemented
yet (sorry).

AVRCP itself looks straightforward, but it's mostly just a wrapper
for the AV/C command set.  The spec for AV/C looks well enough
defined, so go ahead!

> Oh, and we'll need more drivers which will need to be more complex and
> more efficient and less buggy

s/more complex/simpler/ -- we are talking about Plan 9, remember?




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-25 10:11             ` Richard Miller
@ 2009-09-25 11:30               ` matt
  0 siblings, 0 replies; 25+ messages in thread
From: matt @ 2009-09-25 11:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

you could just set the mtime to the time of the last successful
operation on that device

>>>What do you mean exactly by "sees"? ...
>>>
>>>
>>all devices that are listening on inquiry scan channels and respond to
>>inquiry requests.
>>
>>
>
>It looks like your requirement might be satisfied by one or
>the other of these things in the /net/bt/devices record:
>
>- a discoverable (ie "responded to most recent inquiry") flag
>- a timestamp for last inquiry response received (1 second resolution?)
>
>I'm reluctant to remove devices altogether when they don't
>respond to inquiry, because it may still be possible to
>connect to a non-discoverable device by paging its address.
>
>
>
>




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [9fans] bluetooth
  2009-09-24  8:22         ` Richard Miller
                             ` (2 preceding siblings ...)
  2009-09-24 19:06           ` Skip Tavakkolian
@ 2010-04-26 18:09           ` Skip Tavakkolian
  3 siblings, 0 replies; 25+ messages in thread
From: Skip Tavakkolian @ 2010-04-26 18:09 UTC (permalink / raw)
  To: 9fans

Now that I have a little experience, I've formed an opinion

> Advice sought:
> 1. Would it be helpful to have a timestamp in the devices record to
> give the time the device was last seen (for some value of "seen")?

Yes; this would be a good feature.

> 2. When should a device disappear from the /net/bt/devices list?

it would be good if this was settable. i think the value depends on the
application and user behavior. at a starbucks they might hang around,
but along a walkway it might be the length of time a person walks 30'.




^ permalink raw reply	[flat|nested] 25+ messages in thread

* [9fans] bluetooth
  2022-03-19 19:05 [9fans] Perhaps someone can give me an advice Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2022-03-19 19:52 ` Richard Miller
  0 siblings, 0 replies; 25+ messages in thread
From: Richard Miller @ 2022-03-19 19:52 UTC (permalink / raw)
  To: 9fans

lyndon@orthanc.ca:
> Bluetooth (and BLE) support woould be *very* nice to have.

I have a native bluetooth host implementation for Plan 9, not ported
from anything (it's written from scratch based on published bt specs.)
I don't regard it as sufficiently debugged for a release ... it's
missing some important error handling (mandatory retries to recover from
poor reception) and it just plain doesn't work for some of the dongles
I've tried. I don't know whether it's compatible with BLE (which didn't
exist at the time I wrote it). Contact me off list if you'd like a copy.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mf8839883c089cb58afb527cf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2022-03-19 19:52 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-22 19:34 [9fans] bluetooth Skip Tavakkolian
2009-09-22 22:33 ` Patrick Kelly
2009-09-23  0:53 ` dave.l
2009-09-23 14:48   ` Richard Miller
2009-09-24 20:40     ` dave.l
2009-09-25 10:48       ` Richard Miller
2009-09-23 14:37 ` Richard Miller
2009-09-23 16:10   ` Skip Tavakkolian
2009-09-23 17:54   ` Skip Tavakkolian
2009-09-23 17:57     ` Francisco J Ballesteros
2009-09-23 18:11     ` Richard Miller
2009-09-23 20:57       ` Skip Tavakkolian
2009-09-24  4:33         ` lucio
2009-09-24  8:22         ` Richard Miller
2009-09-24 11:03           ` Nathaniel W Filardo
2009-09-24 13:59             ` Richard Miller
2009-09-24 20:05               ` Steve Simon
2009-09-25 10:23                 ` Richard Miller
2009-09-24 15:30           ` rsc
2009-09-24 15:57             ` Richard Miller
2009-09-24 19:06           ` Skip Tavakkolian
2009-09-25 10:11             ` Richard Miller
2009-09-25 11:30               ` matt
2010-04-26 18:09           ` Skip Tavakkolian
2022-03-19 19:05 [9fans] Perhaps someone can give me an advice Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-03-19 19:52 ` [9fans] bluetooth Richard Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).