Basicblue?
Archiver
Posts: 46,084
This question is for those familiar with the “BasicBlue” module.
How long does it take for a module that has traveled out of bluetooth range
to reestablish communication upon reentering bluetooth range?
My application will need to automatically reestablish a link with a fixed
BT control station after traveling outside the area. The traveling BT unit
is on a fixed course that will return to BT range within a predetermined
amount of time. There is one base and several train cars. Each car will
leave the base station at an undermined time interval. I want all the cars
to read a single broadcast string and select pertinent info from within the
string. The reason I am thinking about Bluetooth is the possibility of Palm
based controller redundancy.
To be more specific… I want to send destination station data to BS2p
equipped model train cars while they are que’d. These trains will travel to
their target station outside BT range on a fixed track and return to Que to
receive other instructions. Is it possible for the basicblue module to carry
out the handshake automatically upon reentering BT range, or should I stick
to the 433MHz modules? I’ve written an experimental Bluetooth Palm App., but
the handshake was less than automatic.
I’ve read that BT 1.1 has more range than the typical BT figures and there
is the possibility that the train cars in this application will never leave
range. This application is in a building and I want to build for the
possibility of interrupted communication.
Is Basicblue for me? I have read through the basicblue manual but I’m still
scratching my head.
Thanks,
Jeff
[noparse][[/noparse]Non-text portions of this message have been removed]
How long does it take for a module that has traveled out of bluetooth range
to reestablish communication upon reentering bluetooth range?
My application will need to automatically reestablish a link with a fixed
BT control station after traveling outside the area. The traveling BT unit
is on a fixed course that will return to BT range within a predetermined
amount of time. There is one base and several train cars. Each car will
leave the base station at an undermined time interval. I want all the cars
to read a single broadcast string and select pertinent info from within the
string. The reason I am thinking about Bluetooth is the possibility of Palm
based controller redundancy.
To be more specific… I want to send destination station data to BS2p
equipped model train cars while they are que’d. These trains will travel to
their target station outside BT range on a fixed track and return to Que to
receive other instructions. Is it possible for the basicblue module to carry
out the handshake automatically upon reentering BT range, or should I stick
to the 433MHz modules? I’ve written an experimental Bluetooth Palm App., but
the handshake was less than automatic.
I’ve read that BT 1.1 has more range than the typical BT figures and there
is the possibility that the train cars in this application will never leave
range. This application is in a building and I want to build for the
possibility of interrupted communication.
Is Basicblue for me? I have read through the basicblue manual but I’m still
scratching my head.
Thanks,
Jeff
[noparse][[/noparse]Non-text portions of this message have been removed]
Comments
>> How long does it take for a module that has traveled
>> out of bluetooth range to reestablish communication
>> upon reentering bluetooth range?
This can be somewhat variable due to interference, but in a
relatively clean environment you should be able to reestablish a
link with a known device within a few seconds. The reason that I
qualify this to a "known device" is that it will take longer to
connect if you either do not know the address of the remote device
or have not connected for a long time. The reason for this is that
Bluetooth devices use a hopping sequence to avoid interference both
with technologies like 802.11 and other Bluetooth devices. This
means that when two Bluetooth devices want to communicate with each
other, they must sync up and hop together. The eb500 remembers the
sync information for devices that it has connected to recently and
therefore will be able to reconnect more quickly.
If you are going to be out of range for less than forty seconds, you
can simply increase the link timeout and let the eb500 handle this
automatically. The link timeout specifies the period of time that
the eb500 will wait and retry transmissions before assuming that the
link is broken. You can set the link timeout using the following
syntax with a value in seconds of between one and forty.
set linktimeout 40<CR>
If you think that you may be out of range for more than forty
seconds at a time, simply monitor the connection status line and
attempt to reconnect if the connection is lost. Within a few seconds
of the eb500 coming back in range, a connection will be established
and it can sync up with the current information.
Because Bluetooth is connection oriented, it is often helpful to
think of your solution somewhat differently than you would when
using a broadcast protocol. This serves to both determine whether
Bluetooth is right for your design, and uncover new
possibilities that you may not have considered. For instance you
describe that
>> I want all the cars to read a single broadcast string
>> and select pertinent info from within the string. The
>> reason I am thinking about Bluetooth is the possibility
>> of Palm based controller redundancy.
What if we turn this around to a connection oriented design rather
than a broadcast design? A connection oriented design would put the
Palm controller in charge of all the rail cars. The controller would
decide when it needs to connect with each car, send instructions,
and read back information. This could be anything from staying
connected whenever in range to connecting every few minutes. The
point is that the behavior is completely configurable on the host
side. There are a number possible benefits to this scheme including
the following.
1. The communications code on the BS2p is much simpler in this
scheme because it is largely passive. When the controller connects
to it, it simply needs to follow the command provided. This could
entail sending back information or traveling to the remote station.
2. Since the controller is communicating with each eb500
individually it is quite simple to encapsulate functionality. For
instance new cars with additional features could support additional
commands without effecting existing cars.
3. Since the controller is in charge of all communications, it
is easy to use multiple controllers or switch controllers on the
fly. If the train cars connected to the controller they would have
to be aware of each controller that was used.
4. Since Bluetooth is connection oriented, the controller will
automatically know when it can not communicate with one of the cars.
With a broadcast protocol you must write additional code to
accomplish this.
5. Since the controller is in charge of all communications, the
amount of transmission time can be kept to a minimum for power
conservation. Typically the controller knows when it needs to
exchange information and therefore will only connect when necessary.
This allows the eb500 to use very little power.
6. Most Bluetooth implementations on PCs and PDAs support up to
seven simultaneous connections. This will allow the controller to
communicate with seven eb500 units at the same time.
7. Multiple controllers could be used simultaneously. Each
controller could be used to either control specific cars or one
could be used for something specific like monitoring the current
state of each car.
I hope that this clears things up a bit.
Talk to you soon,
Bryan Hall
A7 Engineering
www.a7eng.com
Parallax in time to change my order from 433Mhz to a couple of embedded Blue
modules.
I didn't think about the benefits of the connection status line until now,
but it certainly makes things simple. I'm sure I'll have plenty of other
questions once the modules arrive.
Thanks again,
Jeff
Original Message
From: Bryan Hall [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=86uxwG4elbP1zVCz9pHYukp2Zke0AA4vJH4xj3efHkASUaSTrRCN40R4h7uMP39-egxwWjiDo0l4qqO13PcAFQ]bryan@f...[/url
Sent: Monday, February 16, 2004 8:27 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: Basicblue?
Hello Jeff,
>> How long does it take for a module that has traveled
>> out of bluetooth range to reestablish communication
>> upon reentering bluetooth range?
This can be somewhat variable due to interference, but in a
relatively clean environment you should be able to reestablish a
link with a known device within a few seconds. The reason that I
qualify this to a "known device" is that it will take longer to
connect if you either do not know the address of the remote device
or have not connected for a long time. The reason for this is that
Bluetooth devices use a hopping sequence to avoid interference both
with technologies like 802.11 and other Bluetooth devices. This
means that when two Bluetooth devices want to communicate with each
other, they must sync up and hop together. The eb500 remembers the
sync information for devices that it has connected to recently and
therefore will be able to reconnect more quickly.
If you are going to be out of range for less than forty seconds, you
can simply increase the link timeout and let the eb500 handle this
automatically. The link timeout specifies the period of time that
the eb500 will wait and retry transmissions before assuming that the
link is broken. You can set the link timeout using the following
syntax with a value in seconds of between one and forty.
set linktimeout 40<CR>
If you think that you may be out of range for more than forty
seconds at a time, simply monitor the connection status line and
attempt to reconnect if the connection is lost. Within a few seconds
of the eb500 coming back in range, a connection will be established
and it can sync up with the current information.
Because Bluetooth is connection oriented, it is often helpful to
think of your solution somewhat differently than you would when
using a broadcast protocol. This serves to both determine whether
Bluetooth is right for your design, and uncover new
possibilities that you may not have considered. For instance you
describe that
>> I want all the cars to read a single broadcast string
>> and select pertinent info from within the string. The
>> reason I am thinking about Bluetooth is the possibility
>> of Palm based controller redundancy.
What if we turn this around to a connection oriented design rather
than a broadcast design? A connection oriented design would put the
Palm controller in charge of all the rail cars. The controller would
decide when it needs to connect with each car, send instructions,
and read back information. This could be anything from staying
connected whenever in range to connecting every few minutes. The
point is that the behavior is completely configurable on the host
side. There are a number possible benefits to this scheme including
the following.
1. The communications code on the BS2p is much simpler in this
scheme because it is largely passive. When the controller connects
to it, it simply needs to follow the command provided. This could
entail sending back information or traveling to the remote station.
2. Since the controller is communicating with each eb500
individually it is quite simple to encapsulate functionality. For
instance new cars with additional features could support additional
commands without effecting existing cars.
3. Since the controller is in charge of all communications, it
is easy to use multiple controllers or switch controllers on the
fly. If the train cars connected to the controller they would have
to be aware of each controller that was used.
4. Since Bluetooth is connection oriented, the controller will
automatically know when it can not communicate with one of the cars.
With a broadcast protocol you must write additional code to
accomplish this.
5. Since the controller is in charge of all communications, the
amount of transmission time can be kept to a minimum for power
conservation. Typically the controller knows when it needs to
exchange information and therefore will only connect when necessary.
This allows the eb500 to use very little power.
6. Most Bluetooth implementations on PCs and PDAs support up to
seven simultaneous connections. This will allow the controller to
communicate with seven eb500 units at the same time.
7. Multiple controllers could be used simultaneously. Each
controller could be used to either control specific cars or one
could be used for something specific like monitoring the current
state of each car.
I hope that this clears things up a bit.
Talk to you soon,
Bryan Hall
A7 Engineering
www.a7eng.com
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Yahoo! Groups Links