[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] solving a broadcast problem through bluetooth

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

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 majordomo@xxxxxxx.com