[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] solving a broadcast problem through bluetooth
Le Jeudi 01 Février 2001 20:14, Gordon McNutt a écrit :
> ping kidwai wrote:
> > Hi,
> > Thanks for your reply, Yes, u r right that a slave cannot broadcast, but
> > a Master can, What happens if they want to form a new piconet and sends
> > the *query* packet, since there is no prior notification in broadcasting
> > to other nodes, if the other node is also sending a *query* packets or
> > two or more nodes reply to that *query* packet at the same time, their
> > packets will collide *at the reciever*. Although the solution given for
> > that, *the Master won't reply and those nodes will wait for random amount
> > of time and resend the packet again.*
> > Hope that would clear, What exactly I wanna know, since I am not fully
> > convinced the *random amount of time waitage * stuff before resending the
> > packet. It doesnt give you the gurantee that packet won't collide again.
> > I am interested in knowing that, are there any control signals for
> > notifying other nodes that *Hey Iam sending a broadcast *query packet*
> > and nobody dares to send or recieve any packet during this packet time*
> Your talking about a master telling its slaves to shut up while it does an
> inquiry, right? I don't see anything in the spec about that. But in
> principle random retries should work. I suppose if congestion was really
> bad then inquiry would get flaky. But how bad would it have to be? Have to
> dig into the spec and do some math...
I think (but I might be wrong) that you don't have it right... In connection
state, a slave can transmit data only when the master tells him to do so by
transmiting a (small) packet with the am_addr attributed to this slave (i.e.
polling scheme). A broadcast packet is just a packet with am_addr == 0. So if
a master does an inquiry, its slaves "naturally" shut up...
> This brings up some questions which I haven't had time (yet) to research.
> Maybe somebody out there knows the answers:
> 1. Can a slave start an inqury? I suppose if it avoids the hop sequence of
> the piconet(s) it's already on then this would work...
> 2. The spec says "slaves can participate in different piconets on a
> time-division multiplex basis". I have trouble imagining this. Slaves only
> listen part of the time for each time slot in each piconet? And only
> transmit part of the time... and if they want to transmit when they're
> supposed to be listening... seems like the problem gets pretty bad pretty
> fast as the number of piconets goes up. Has anyone actually implemented
> firmware that can handle multiple piconets?
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to email@example.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org