Bluetooth eb500
Archiver
Posts: 46,084
How long should it take for the Embedded Bluetooth transceiver to send a byte to
a pc, and receive a byte from the pc?
On the OPTAscope I'm getting a reading of almost 50 milliseconds. The eb500 is
on the Boe-Bot. SEROUT sends a byte to the pc. Then SERIN reads a byte that the
pc sends right back. Any ideas on why it's taking so long?
According to the Parallax manual, I need to get a pulse out to the Boe-Bot
servos every 10 to 40 ms, so I can't afford 50 ms. Any ideas on how to speed
things up?
[noparse][[/noparse]Non-text portions of this message have been removed]
a pc, and receive a byte from the pc?
On the OPTAscope I'm getting a reading of almost 50 milliseconds. The eb500 is
on the Boe-Bot. SEROUT sends a byte to the pc. Then SERIN reads a byte that the
pc sends right back. Any ideas on why it's taking so long?
According to the Parallax manual, I need to get a pulse out to the Boe-Bot
servos every 10 to 40 ms, so I can't afford 50 ms. Any ideas on how to speed
things up?
[noparse][[/noparse]Non-text portions of this message have been removed]
Comments
There are a number of factors that effect the timing when sending a byte
round trip from stamp to PC and back to the stamp. I am going to assume
that your stamp and PC are running efficiently and just focus on timing
issues with Bluetooth and the eb500 module.
While the Bluetooth protocol is designed to transmit data reliably at
sustained high data rates of up to 720kbps, it is not specifically
designed for either low latency transfers or timing dependant transfers.
What this means is that if your application requires a latency of less
than 5ms, Bluetooth may not be the right solution for you. Think of a
Bluetooth data transfer a little like TCP/IP over Ethernet in that the
data will arrive intact, but the overall timing with which it will
arrive is a bit unpredictable and will not be the same every time you
send the data. This is simply a tradeoff in the way the protocol is
defined. Bluetooth emphasizes throughput, reliability, and low power
operation rather than low latency.
The eb500 is configured by default to negotiate connections that lean
towards power savings rather than low latency. Specifically it supports
two Bluetooth low power modes called sniff and park. I suspect that the
latency issue that you are seeing is largely due to the eb500 module
entering sniff mode between bytes and then having to come out of sniff
mode to transmit. Sniff mode is a low power state that is negotiated
between the two radios when the connection is established. It allows one
of the radios to enter a low power mode for specific negotiated
intervals of time (20ms to 80ms for an eb500) in order to conserve power
when no data is being transmitted. The down side to this is that when
the first byte is sent from a device currently in sniff mode, it must
wait for the interval to expire before sending the data. Subsequent
bytes are sent immediately as long as the data stream is kept constant.
Any significant pause between bytes will allow the radio to go back into
sniff mode to conserve power.
The initial eb500 version 1.0 firmware release does not allow you to
disable these low power modes in favor of a lower latency connection.
While I can not give you a specific time frame, this is recognized as an
important feature and will be added to a future firmware release.
I do however have a suggestion that may help you with your current
project. If you are going to service the sensors and servos on your BS2
based robot, you need to break away from the idea of a tightly coupled
command response loop between the PC and the BOE-Bot. This can be done
in several ways, one of which is demonstrated in the Monkey Do portion
of the eb500 Monkey See/Monkey Do sample. Take a look at the following
code:
CmdData VAR BYTE
'Wait for the eb500 radio to be ready
PAUSE 1000
'Set the initial state to hold
CmdData = 3
Main:
'Wait for a command
SERIN 0,84,[noparse][[/noparse]DEC1 CmdData]
'Process the command
BRANCH CmdData,[noparse][[/noparse]Hold, Turn_Right, Turn_Left, Move_Fwd]
'If the command was invalid, just loop again
GOTO Main
I did not include the motor routines for each action because the
important element here is the main processing loop. The key to the
motors running at full capacity in this scenario is simply that the
controller, the PC in your example, sends commands frequently. The exact
rate at which you need to send commands will vary depending on how much
processing that you are doing. To get a feel for this, try the following
experiment.
1. Load the Monkey Do application (MonkeyDo.bs2) onto your BOE-Bot. This
is documented starting on page 43 of the eb500 manual.
2. Connect to the BOE-Bot via Bluetooth from your PC using
HyperTerminal. This is documented on page 28 of the manual in the
section titled "Connecting a PC with a DBT-120 to a BOE".
3. Open HyperTerminal on the PC and connect to the COM port from step 2.
4. As you type the numbers 1, 2, and 3 into HyperTerminal your BOE-Bot
will move in very small increments. Notice that the robot is quite
responsive to these commands even though the eb500 has sniff mode
enabled.
5. Now hold down the number 1. The BOE-Bot now moves forward smoothly at
full speed. You will notice a delay between the time that you press and
hold the key and the time that the BOE-Bot is moving forward smoothly.
This is due to the way in which the key repeat in HyperTerminal works
and not Bluetooth latencies.
From your sample description it also sounds like you are sending sensor
data up to the PC. This can be accomplished in a similar manner by
simply adding a SEROUT to write the sensor data to the eb500 each time
through the loop. As long as your sensor read time is not really long,
the robot will keep moving at full speed.
I hope that this clarifies the timing issues for you. Let me know if you
have any further questions.
Bryan Hall
A7 Engineering
www.a7eng.com
Original Message
From: Steve Nelick [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=tgSc7gXxABvH7R952vnnPNTn5BzQsv4cZmqkeRI9pptn4py1lW6xR5UbOgtd3CcdWg4s_Yf_iCbezTMG]s.nelick@v...[/url
Sent: Tuesday, January 13, 2004 6:30 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Bluetooth eb500
How long should it take for the Embedded Bluetooth transceiver to send a
byte to a pc, and receive a byte from the pc?
On the OPTAscope I'm getting a reading of almost 50 milliseconds. The
eb500 is on the Boe-Bot. SEROUT sends a byte to the pc. Then SERIN reads
a byte that the pc sends right back. Any ideas on why it's taking so
long?
According to the Parallax manual, I need to get a pulse out to the
Boe-Bot servos every 10 to 40 ms, so I can't afford 50 ms. Any ideas on
how to speed things up?
Thanks for the information on the EmbeddedBlue 500. That's a powerful
device! I had no idea it worked that way.
When I read the instructions for the eb500, I saw the SERIN 0,84, and I
assumed the Bluetooth was running at 9600 baud. I started programming the
BS2 to work like the program in the StampWorks Experiment #31 Serial
Communications.
When I sent a byte to over to the Boe-Bot and back to the pc, I was
disappointed to see that it took 50 ms. So I spent all day yesterday running
tests. First, I blamed the problem on Python, and I switched to C++, but the
timing results were the same. Then I thought the problem was the eb500, so I
started sending bytes between a pc and a notebook computer.
If I sent 1 byte over and back, 1,000 times, it took 30 seconds. But, if I
sent 100 bytes over and back, 1,000 times, it only took 32.2 seconds. How
could 99,000 bytes go over and back in 2.2 seconds!
My wife kept asking me if I was O.K. She said I seemed to be in a highly
agitated state, walking around the kitchen in circles. I said I'm having a
problem with the robot. Eventually I got a bottle of gin and fell asleep.
When I got your note I went back to the my test results, and there it was:
99,000 bytes X 8 bits per byte X 2 (over and back) in 2. 2 seconds
That's the 720 kbps that's in your note.
____________
Original Message
From: "Bryan Hall" <bryan@f...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, January 14, 2004 7:56 PM
Subject: RE: [noparse][[/noparse]basicstamps] Bluetooth eb500
> Hello Steven,
>
> There are a number of factors that effect the timing when sending a byte
> round trip from stamp to PC and back to the stamp. I am going to assume
> that your stamp and PC are running efficiently and just focus on timing
> issues with Bluetooth and the eb500 module.
>
> While the Bluetooth protocol is designed to transmit data reliably at
> sustained high data rates of up to 720kbps, it is not specifically
> designed for either low latency transfers or timing dependant transfers.
> What this means is that if your application requires a latency of less
> than 5ms, Bluetooth may not be the right solution for you. Think of a
> Bluetooth data transfer a little like TCP/IP over Ethernet in that the
> data will arrive intact, but the overall timing with which it will
> arrive is a bit unpredictable and will not be the same every time you
> send the data. This is simply a tradeoff in the way the protocol is
> defined. Bluetooth emphasizes throughput, reliability, and low power
> operation rather than low latency.
>
> The eb500 is configured by default to negotiate connections that lean
> towards power savings rather than low latency. Specifically it supports
> two Bluetooth low power modes called sniff and park. I suspect that the
> latency issue that you are seeing is largely due to the eb500 module
> entering sniff mode between bytes and then having to come out of sniff
> mode to transmit. Sniff mode is a low power state that is negotiated
> between the two radios when the connection is established. It allows one
> of the radios to enter a low power mode for specific negotiated
> intervals of time (20ms to 80ms for an eb500) in order to conserve power
> when no data is being transmitted. The down side to this is that when
> the first byte is sent from a device currently in sniff mode, it must
> wait for the interval to expire before sending the data. Subsequent
> bytes are sent immediately as long as the data stream is kept constant.
> Any significant pause between bytes will allow the radio to go back into
> sniff mode to conserve power.
>
> The initial eb500 version 1.0 firmware release does not allow you to
> disable these low power modes in favor of a lower latency connection.
> While I can not give you a specific time frame, this is recognized as an
> important feature and will be added to a future firmware release.
>
> I do however have a suggestion that may help you with your current
> project. If you are going to service the sensors and servos on your BS2
> based robot, you need to break away from the idea of a tightly coupled
> command response loop between the PC and the BOE-Bot. This can be done
> in several ways, one of which is demonstrated in the Monkey Do portion
> of the eb500 Monkey See/Monkey Do sample. Take a look at the following
> code:
>
>
> CmdData VAR BYTE
>
> 'Wait for the eb500 radio to be ready
> PAUSE 1000
> 'Set the initial state to hold
> CmdData = 3
>
> Main:
> 'Wait for a command
> SERIN 0,84,[noparse][[/noparse]DEC1 CmdData]
>
> 'Process the command
> BRANCH CmdData,[noparse][[/noparse]Hold, Turn_Right, Turn_Left, Move_Fwd]
>
> 'If the command was invalid, just loop again
> GOTO Main
>
>
> I did not include the motor routines for each action because the
> important element here is the main processing loop. The key to the
> motors running at full capacity in this scenario is simply that the
> controller, the PC in your example, sends commands frequently. The exact
> rate at which you need to send commands will vary depending on how much
> processing that you are doing. To get a feel for this, try the following
> experiment.
>
> 1. Load the Monkey Do application (MonkeyDo.bs2) onto your BOE-Bot. This
> is documented starting on page 43 of the eb500 manual.
> 2. Connect to the BOE-Bot via Bluetooth from your PC using
> HyperTerminal. This is documented on page 28 of the manual in the
> section titled "Connecting a PC with a DBT-120 to a BOE".
> 3. Open HyperTerminal on the PC and connect to the COM port from step 2.
> 4. As you type the numbers 1, 2, and 3 into HyperTerminal your BOE-Bot
> will move in very small increments. Notice that the robot is quite
> responsive to these commands even though the eb500 has sniff mode
> enabled.
> 5. Now hold down the number 1. The BOE-Bot now moves forward smoothly at
> full speed. You will notice a delay between the time that you press and
> hold the key and the time that the BOE-Bot is moving forward smoothly.
> This is due to the way in which the key repeat in HyperTerminal works
> and not Bluetooth latencies.
>
> From your sample description it also sounds like you are sending sensor
> data up to the PC. This can be accomplished in a similar manner by
> simply adding a SEROUT to write the sensor data to the eb500 each time
> through the loop. As long as your sensor read time is not really long,
> the robot will keep moving at full speed.
>
> I hope that this clarifies the timing issues for you. Let me know if you
> have any further questions.
>
> Bryan Hall
> A7 Engineering
> www.a7eng.com
>
>
>
Original Message
> From: Steve Nelick [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=E3FBBBn4i6e81BjjBtjsy4GusTS8ZPN0ZtdNzN-yya4-3MCYZ7r2Av5lH3tO62TspwlmSMdEdpyOlm4Xnw]s.nelick@v...[/url
> Sent: Tuesday, January 13, 2004 6:30 PM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Bluetooth eb500
>
>
> How long should it take for the Embedded Bluetooth transceiver to send a
> byte to a pc, and receive a byte from the pc?
>
> On the OPTAscope I'm getting a reading of almost 50 milliseconds. The
> eb500 is on the Boe-Bot. SEROUT sends a byte to the pc. Then SERIN reads
> a byte that the pc sends right back. Any ideas on why it's taking so
> long?
>
> According to the Parallax manual, I need to get a pulse out to the
> Boe-Bot servos every 10 to 40 ms, so I can't afford 50 ms. Any ideas on
> how to speed things up?
>
>
>
>
>
> 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
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
I have a question.
Is there any reason that the eb500 can't be connected to the debug
port instead of the normal I/o pins? Just curious. By the way, so
far, the eb500 is running pretty good, though I have found a bug in
the IPAQ that I've fixed. Still having a little trouble getting the
transmit eb500 to ipaq or PC working right. very sporatic results,
though it does connect. Took me a long tome to figure out the bug in
the IPAQ so I hav'ent been able to concentrate on the BL transmit
stuff. The recieve works superb though. You should consider making a
version of it that hangs off the debug port.
Anyway, the remote control of the hexcrawler works fine. All of the
troubles so far have been on the IPAQ and the NSbasic though as I
said, I still haven't got the transmit stuff working to my
satisfaction. I don't think it is the eb500 though, i think it's the
IPAQ.
You should also consider making a module with a SMA connector on it
for standard bluetooth antennas. I'm still planning on dadding the
eb500 to my own little project, just not there yet.
--- In basicstamps@yahoogroups.com, "Steve Nelick" <s.nelick@v...>
wrote:
> Hello Bryan,
>
> Thanks for the information on the EmbeddedBlue 500. That's a
powerful
> device! I had no idea it worked that way.
>
> When I read the instructions for the eb500, I saw the SERIN 0,84,
and I
> assumed the Bluetooth was running at 9600 baud. I started
programming the
> BS2 to work like the program in the StampWorks Experiment #31
Serial
> Communications.
>
> When I sent a byte to over to the Boe-Bot and back to the pc, I was
> disappointed to see that it took 50 ms. So I spent all day
yesterday running
> tests. First, I blamed the problem on Python, and I switched to
C++, but the
> timing results were the same. Then I thought the problem was the
eb500, so I
> started sending bytes between a pc and a notebook computer.
>
> If I sent 1 byte over and back, 1,000 times, it took 30 seconds.
But, if I
> sent 100 bytes over and back, 1,000 times, it only took 32.2
seconds. How
> could 99,000 bytes go over and back in 2.2 seconds!
>
> My wife kept asking me if I was O.K. She said I seemed to be in a
highly
> agitated state, walking around the kitchen in circles. I said I'm
having a
> problem with the robot. Eventually I got a bottle of gin and fell
asleep.
>
> When I got your note I went back to the my test results, and there
it was:
>
> 99,000 bytes X 8 bits per byte X 2 (over and back) in 2.
2 seconds
>
> That's the 720 kbps that's in your note.
>
>
> ____________
>
>
>
>
Original Message
> From: "Bryan Hall" <bryan@f...>
> To: <basicstamps@yahoogroups.com>
> Sent: Wednesday, January 14, 2004 7:56 PM
> Subject: RE: [noparse][[/noparse]basicstamps] Bluetooth eb500
>
>
> > Hello Steven,
> >
> > There are a number of factors that effect the timing when
sending a byte
> > round trip from stamp to PC and back to the stamp. I am going to
assume
> > that your stamp and PC are running efficiently and just focus on
timing
> > issues with Bluetooth and the eb500 module.
> >
> > While the Bluetooth protocol is designed to transmit data
reliably at
> > sustained high data rates of up to 720kbps, it is not
specifically
> > designed for either low latency transfers or timing dependant
transfers.
> > What this means is that if your application requires a latency
of less
> > than 5ms, Bluetooth may not be the right solution for you. Think
of a
> > Bluetooth data transfer a little like TCP/IP over Ethernet in
that the
> > data will arrive intact, but the overall timing with which it
will
> > arrive is a bit unpredictable and will not be the same every
time you
> > send the data. This is simply a tradeoff in the way the protocol
is
> > defined. Bluetooth emphasizes throughput, reliability, and low
power
> > operation rather than low latency.
> >
> > The eb500 is configured by default to negotiate connections that
lean
> > towards power savings rather than low latency. Specifically it
supports
> > two Bluetooth low power modes called sniff and park. I suspect
that the
> > latency issue that you are seeing is largely due to the eb500
module
> > entering sniff mode between bytes and then having to come out of
sniff
> > mode to transmit. Sniff mode is a low power state that is
negotiated
> > between the two radios when the connection is established. It
allows one
> > of the radios to enter a low power mode for specific negotiated
> > intervals of time (20ms to 80ms for an eb500) in order to
conserve power
> > when no data is being transmitted. The down side to this is that
when
> > the first byte is sent from a device currently in sniff mode, it
must
> > wait for the interval to expire before sending the data.
Subsequent
> > bytes are sent immediately as long as the data stream is kept
constant.
> > Any significant pause between bytes will allow the radio to go
back into
> > sniff mode to conserve power.
> >
> > The initial eb500 version 1.0 firmware release does not allow
you to
> > disable these low power modes in favor of a lower latency
connection.
> > While I can not give you a specific time frame, this is
recognized as an
> > important feature and will be added to a future firmware release.
> >
> > I do however have a suggestion that may help you with your
current
> > project. If you are going to service the sensors and servos on
your BS2
> > based robot, you need to break away from the idea of a tightly
coupled
> > command response loop between the PC and the BOE-Bot. This can
be done
> > in several ways, one of which is demonstrated in the Monkey Do
portion
> > of the eb500 Monkey See/Monkey Do sample. Take a look at the
following
> > code:
> >
> >
> > CmdData VAR BYTE
> >
> > 'Wait for the eb500 radio to be ready
> > PAUSE 1000
> > 'Set the initial state to hold
> > CmdData = 3
> >
> > Main:
> > 'Wait for a command
> > SERIN 0,84,[noparse][[/noparse]DEC1 CmdData]
> >
> > 'Process the command
> > BRANCH CmdData,[noparse][[/noparse]Hold, Turn_Right, Turn_Left, Move_Fwd]
> >
> > 'If the command was invalid, just loop again
> > GOTO Main
> >
> >
> > I did not include the motor routines for each action because the
> > important element here is the main processing loop. The key to
the
> > motors running at full capacity in this scenario is simply that
the
> > controller, the PC in your example, sends commands frequently.
The exact
> > rate at which you need to send commands will vary depending on
how much
> > processing that you are doing. To get a feel for this, try the
following
> > experiment.
> >
> > 1. Load the Monkey Do application (MonkeyDo.bs2) onto your BOE-
Bot. This
> > is documented starting on page 43 of the eb500 manual.
> > 2. Connect to the BOE-Bot via Bluetooth from your PC using
> > HyperTerminal. This is documented on page 28 of the manual in the
> > section titled "Connecting a PC with a DBT-120 to a BOE".
> > 3. Open HyperTerminal on the PC and connect to the COM port from
step 2.
> > 4. As you type the numbers 1, 2, and 3 into HyperTerminal your
BOE-Bot
> > will move in very small increments. Notice that the robot is
quite
> > responsive to these commands even though the eb500 has sniff mode
> > enabled.
> > 5. Now hold down the number 1. The BOE-Bot now moves forward
smoothly at
> > full speed. You will notice a delay between the time that you
press and
> > hold the key and the time that the BOE-Bot is moving forward
smoothly.
> > This is due to the way in which the key repeat in HyperTerminal
works
> > and not Bluetooth latencies.
> >
> > From your sample description it also sounds like you are sending
sensor
> > data up to the PC. This can be accomplished in a similar manner
by
> > simply adding a SEROUT to write the sensor data to the eb500
each time
> > through the loop. As long as your sensor read time is not really
long,
> > the robot will keep moving at full speed.
> >
> > I hope that this clarifies the timing issues for you. Let me
know if you
> > have any further questions.
> >
> > Bryan Hall
> > A7 Engineering
> > www.a7eng.com
> >
> >
> >
Original Message
> > From: Steve Nelick [noparse][[/noparse]mailto:s.nelick@v...]
> > Sent: Tuesday, January 13, 2004 6:30 PM
> > To: basicstamps@yahoogroups.com
> > Subject: [noparse][[/noparse]basicstamps] Bluetooth eb500
> >
> >
> > How long should it take for the Embedded Bluetooth transceiver
to send a
> > byte to a pc, and receive a byte from the pc?
> >
> > On the OPTAscope I'm getting a reading of almost 50
milliseconds. The
> > eb500 is on the Boe-Bot. SEROUT sends a byte to the pc. Then
SERIN reads
> > a byte that the pc sends right back. Any ideas on why it's
taking so
> > long?
> >
> > According to the Parallax manual, I need to get a pulse out to
the
> > Boe-Bot servos every 10 to 40 ms, so I can't afford 50 ms. Any
ideas on
> > how to speed things up?
> >
> >
> >
> >
> >
> > 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
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/basicstamps/
> >
> > To unsubscribe from this group, send an email to:
> > basicstamps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
> >
> >
>> Is there any reason that the eb500 can't be connected
>> to the debug port instead of the normal I/o pins?
To connect the eb500 to the debug port for communications is fairly
simple. All that you need to do is level translation between the
eb500s 5V TTL levels and the debug ports RS232 levels. You will only
need to do this for the transmit and receive line, but you will also
need to connect the stamp ATN line to ground.
For Stamp programming the situation gets a bit more complex because
of the control signals used to detect the device and reset it before
firmware downloads. This is not possible with the eb500, but A7 is
working on an standard RS232 version of the module that will support
both wireless programming and debugging.
>> You should also consider making a module with a SMA
>> connector on it for standard bluetooth antennas.
This is currently in the works but will most likely take the form of
an MMCX connector rather than an SMA. The MMCX connector is quite a
bit smaller and will allow substantial reduction in PCB size. Keep
an eye on both the Parallax (www.parallax.com) and A7 Engineering
(www.a7eng.com) sites for further details as they become available.
Talk to you soon,
Bryan Hall
A7 Engineering
bhall@a...
--- In basicstamps@yahoogroups.com, "Dave Evartt" <davee@a...> wrote:
> Bryon,
>
> I have a question.
>
>
> Is there any reason that the eb500 can't be connected to the debug
> port instead of the normal I/o pins? Just curious. By the way, so
> far, the eb500 is running pretty good, though I have found a bug
in
> the IPAQ that I've fixed. Still having a little trouble getting
the
> transmit eb500 to ipaq or PC working right. very sporatic results,
> though it does connect. Took me a long tome to figure out the bug
in
> the IPAQ so I hav'ent been able to concentrate on the BL transmit
> stuff. The recieve works superb though. You should consider making
a
> version of it that hangs off the debug port.
>
> Anyway, the remote control of the hexcrawler works fine. All of
the
> troubles so far have been on the IPAQ and the NSbasic though as I
> said, I still haven't got the transmit stuff working to my
> satisfaction. I don't think it is the eb500 though, i think it's
the
> IPAQ.
>
> You should also consider making a module with a SMA connector on
it
> for standard bluetooth antennas. I'm still planning on dadding the
> eb500 to my own little project, just not there yet.
>
trouble getting the ipaq to recieve data using NSBASIC.
Transmitting was fine. I've figured it out and here is what
happened.
Turns out that there were two problems reciving on the IPAQ
from the eb500.
First, the recieve port (com5) is not the port that is used.
Even though the Bluetooth manager says com5, it really is
using com8, which is the bluetooth output port. It uses the
same port number for both, though it may be handled
internally just to make you think it is the same port, in
which case, they should not tell you that it's using two
seperate ports. You can't change the port assignments anyway
so there's no real reason to mention a two port setup when
the software knows it's all on the same port.
Second, The NSBASIC addobject statement does not initialize
the comm object properly if it is not declared a certain way.
It is apparently common to declare the comm object with the
following line;
addobject "comm"
While this will work and not generate errors, it also will
not generate oncomm events that make it easy to handle data
coming in.
addobject "comm","comm",0,0,0,0
is the proper way to do it. This is undocumented and likely
to be the single biggest issue with using NSBASIC and
bluetooth on the IPAQ.
Once these two problems were identified, things work out
very well.
There is a tool you might consider building to make it
easier to integrate bleutooth enabled applications and that
is a way to open a specific device from with a VB program
running on the pocket pc. As it is, you have top select a
bluetooth device when the com port gets open. It would be
nice to be able to call a function in VB that would open a
specific device just before we open the com port so the
selction process is transparent.
The thing I'm trying to do requires that the list of
bluetooth devices, all eb500s, be listed inside the program.
This in itself is easy enough to do, but the function call
to open a bluetooth device is currently unknown, though I'm
sure it is available. Since I'm new to the CE, there is
still a lot too learn on it.
Of course, this will all be mute when A7 lets us name our
own devices. Any idea when this feature will become
available? I'm will to play alpha or beta tester. My
bluetooth experience goes back a few years.
Keep up the good work and please have someone email me a
quote for 1000 boards. I'm planning on using the eb500 in my
product (i already told you that) I need to know how much
it's going to set me back with the money people when I pitch
it to them. I don't know if they will go for it, but it
would be nice if they do.
Thanks.
---- Original message ----
>Date: Wed, 21 Jan 2004 09:02:45 -0000
>From: "Bryan Hall" <bryan@f...>
>Subject: [noparse][[/noparse]basicstamps] Re: Bluetooth eb500
>To: basicstamps@yahoogroups.com
>
>Hi Dave,
>
>>> Is there any reason that the eb500 can't be connected
>>> to the debug port instead of the normal I/o pins?
>
>To connect the eb500 to the debug port for communications
is fairly
>simple. All that you need to do is level translation
between the
>eb500s 5V TTL levels and the debug ports RS232 levels. You
will only
>need to do this for the transmit and receive line, but you
will also
>need to connect the stamp ATN line to ground.
>
>For Stamp programming the situation gets a bit more complex
because
>of the control signals used to detect the device and reset
it before
>firmware downloads. This is not possible with the eb500,
but A7 is
>working on an standard RS232 version of the module that
will support
>both wireless programming and debugging.
>
>>> You should also consider making a module with a SMA
>>> connector on it for standard bluetooth antennas.
>
>This is currently in the works but will most likely take
the form of
>an MMCX connector rather than an SMA. The MMCX connector is
quite a
>bit smaller and will allow substantial reduction in PCB
size. Keep
>an eye on both the Parallax (www.parallax.com) and A7
Engineering
>(www.a7eng.com) sites for further details as they become
available.
>
>Talk to you soon,
>
>Bryan Hall
>A7 Engineering
>bhall@a...
>
>--- In basicstamps@yahoogroups.com, "Dave Evartt"
<davee@a...> wrote:
>> Bryon,
>>
>> I have a question.
>>
>>
>> Is there any reason that the eb500 can't be connected to
the debug
>> port instead of the normal I/o pins? Just curious. By the
way, so
>> far, the eb500 is running pretty good, though I have
found a bug
>in
>> the IPAQ that I've fixed. Still having a little trouble
getting
>the
>> transmit eb500 to ipaq or PC working right. very sporatic
results,
>> though it does connect. Took me a long tome to figure out
the bug
>in
>> the IPAQ so I hav'ent been able to concentrate on the BL
transmit
>> stuff. The recieve works superb though. You should
consider making
>a
>> version of it that hangs off the debug port.
>>
>> Anyway, the remote control of the hexcrawler works fine.
All of
>the
>> troubles so far have been on the IPAQ and the NSbasic
though as I
>> said, I still haven't got the transmit stuff working to
my
>> satisfaction. I don't think it is the eb500 though, i
think it's
>the
>> IPAQ.
>>
>> You should also consider making a module with a SMA
connector on
>it
>> for standard bluetooth antennas. I'm still planning on
dadding the
>> eb500 to my own little project, just not there yet.
>>
>
>
>
>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
>
>To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
>To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
>Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
--
Regards
Dave Evartt
American Hovercraft
I just emailed you off list with bulk pricing of the eb500. With
bulk pricing, the manuals and cd's are not included and the product
must be purchased in sets of 10, 100, or 1,000. If others are
interested in bulk pricing you may email me off the list.
The team at A7 has reviewed your feedback and will take it into
consideration.
Sincerely,
Erik Wood
Parallax, Inc.
ewood@p...
--- In basicstamps@yahoogroups.com, Dave Evartt <davee@a...> wrote:
> Thanks, by the way, you'll remember that I was having
> trouble getting the ipaq to recieve data using NSBASIC.
> Transmitting was fine. I've figured it out and here is what
> happened.
>
> Turns out that there were two problems reciving on the IPAQ
> from the eb500.
>
> First, the recieve port (com5) is not the port that is used.
> Even though the Bluetooth manager says com5, it really is
> using com8, which is the bluetooth output port. It uses the
> same port number for both, though it may be handled
> internally just to make you think it is the same port, in
> which case, they should not tell you that it's using two
> seperate ports. You can't change the port assignments anyway
> so there's no real reason to mention a two port setup when
> the software knows it's all on the same port.
>
> Second, The NSBASIC addobject statement does not initialize
> the comm object properly if it is not declared a certain way.
>
> It is apparently common to declare the comm object with the
> following line;
>
> addobject "comm"
>
> While this will work and not generate errors, it also will
> not generate oncomm events that make it easy to handle data
> coming in.
>
> addobject "comm","comm",0,0,0,0
>
> is the proper way to do it. This is undocumented and likely
> to be the single biggest issue with using NSBASIC and
> bluetooth on the IPAQ.
>
> Once these two problems were identified, things work out
> very well.
>
> There is a tool you might consider building to make it
> easier to integrate bleutooth enabled applications and that
> is a way to open a specific device from with a VB program
> running on the pocket pc. As it is, you have top select a
> bluetooth device when the com port gets open. It would be
> nice to be able to call a function in VB that would open a
> specific device just before we open the com port so the
> selction process is transparent.
>
> The thing I'm trying to do requires that the list of
> bluetooth devices, all eb500s, be listed inside the program.
> This in itself is easy enough to do, but the function call
> to open a bluetooth device is currently unknown, though I'm
> sure it is available. Since I'm new to the CE, there is
> still a lot too learn on it.
>
> Of course, this will all be mute when A7 lets us name our
> own devices. Any idea when this feature will become
> available? I'm will to play alpha or beta tester. My
> bluetooth experience goes back a few years.
>
> Keep up the good work and please have someone email me a
> quote for 1000 boards. I'm planning on using the eb500 in my
> product (i already told you that) I need to know how much
> it's going to set me back with the money people when I pitch
> it to them. I don't know if they will go for it, but it
> would be nice if they do.
>
> Thanks.
>
>
>
> ---- Original message ----
> >Date: Wed, 21 Jan 2004 09:02:45 -0000
> >From: "Bryan Hall" <bryan@f...>
> >Subject: [noparse][[/noparse]basicstamps] Re: Bluetooth eb500
> >To: basicstamps@yahoogroups.com
> >
> >Hi Dave,
> >
> >>> Is there any reason that the eb500 can't be connected
> >>> to the debug port instead of the normal I/o pins?
> >
> >To connect the eb500 to the debug port for communications
> is fairly
> >simple. All that you need to do is level translation
> between the
> >eb500s 5V TTL levels and the debug ports RS232 levels. You
> will only
> >need to do this for the transmit and receive line, but you
> will also
> >need to connect the stamp ATN line to ground.
> >
> >For Stamp programming the situation gets a bit more complex
> because
> >of the control signals used to detect the device and reset
> it before
> >firmware downloads. This is not possible with the eb500,
> but A7 is
> >working on an standard RS232 version of the module that
> will support
> >both wireless programming and debugging.
> >
> >>> You should also consider making a module with a SMA
> >>> connector on it for standard bluetooth antennas.
> >
> >This is currently in the works but will most likely take
> the form of
> >an MMCX connector rather than an SMA. The MMCX connector is
> quite a
> >bit smaller and will allow substantial reduction in PCB
> size. Keep
> >an eye on both the Parallax (www.parallax.com) and A7
> Engineering
> >(www.a7eng.com) sites for further details as they become
> available.
> >
> >Talk to you soon,
> >
> >Bryan Hall
> >A7 Engineering
> >bhall@a...
> >
> >--- In basicstamps@yahoogroups.com, "Dave Evartt"
> <davee@a...> wrote:
> >> Bryon,
> >>
> >> I have a question.
> >>
> >>
> >> Is there any reason that the eb500 can't be connected to
> the debug
> >> port instead of the normal I/o pins? Just curious. By the
> way, so
> >> far, the eb500 is running pretty good, though I have
> found a bug
> >in
> >> the IPAQ that I've fixed. Still having a little trouble
> getting
> >the
> >> transmit eb500 to ipaq or PC working right. very sporatic
> results,
> >> though it does connect. Took me a long tome to figure out
> the bug
> >in
> >> the IPAQ so I hav'ent been able to concentrate on the BL
> transmit
> >> stuff. The recieve works superb though. You should
> consider making
> >a
> >> version of it that hangs off the debug port.
> >>
> >> Anyway, the remote control of the hexcrawler works fine.
> All of
> >the
> >> troubles so far have been on the IPAQ and the NSbasic
> though as I
> >> said, I still haven't got the transmit stuff working to
> my
> >> satisfaction. I don't think it is the eb500 though, i
> think it's
> >the
> >> IPAQ.
> >>
> >> You should also consider making a module with a SMA
> connector on
> >it
> >> for standard bluetooth antennas. I'm still planning on
> dadding the
> >> eb500 to my own little project, just not there yet.
> >>
> >
> >
> >
> >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
> >
> >To visit your group on the web, go to:
> > http://groups.yahoo.com/group/basicstamps/
> >
> >To unsubscribe from this group, send an email to:
> > basicstamps-unsubscribe@yahoogroups.com
> >
> >Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
> >
> >
> --
> Regards
>
> Dave Evartt
> American Hovercraft
What you are experiencing is known in the data communciations arena as
"round trip delay". That is, the time to send a message, have the
message transit the communication link (which may involve several
nodes), be received, delivered to the waiting application, and the
same as above for the application to get its message delivered to the
initiating application. 50MS is FAST by the standards I'm used to!
I suggest that, given the behavior of the eb500, you maintain a
continuous stream of data going between the two ends (ie, over the
eb500 link). For example, you could use the ASCII character SYN which
both ends would ignore. Determine the maximum time you can wait
between transmissions to prevent your end from going into "sniff"
mode. Make sure you transmit a SYN well short of that time. Do this
on both ends. This way the link will be kept active and you probably
will get the response you need.
It takes about a millisecond to send a byte at 9600 bps plus
propogation time. (Actually 10/9600 ths of a second.)
Hope this helps!
Russ
--- In basicstamps@yahoogroups.com, "Steve Nelick" <s.nelick@v...> wrote:
> How long should it take for the Embedded Bluetooth transceiver to
send a byte to a pc, and receive a byte from the pc?
>
> On the OPTAscope I'm getting a reading of almost 50 milliseconds.
The eb500 is on the Boe-Bot. SEROUT sends a byte to the pc. Then SERIN
reads a byte that the pc sends right back. Any ideas on why it's
taking so long?
>
> According to the Parallax manual, I need to get a pulse out to the
Boe-Bot servos every 10 to 40 ms, so I can't afford 50 ms. Any ideas
on how to speed things up?
>
>
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]