Bluetooth vs. WLAN to control biped

In an effort to get rid of that silly wire between my bot and the PC, I added a Bluetooth-to-RS232 module to my servo controller. WIth mixed results
though.
While the serial connection itself is great and pretty much guaranteed (either on or off, but not losing a'a few bytes' on the way), the Windows side of things drives me nuts! One data set to the controller is 34 bytes, but the Windows driver tries to be efficient and waits until I fill a 100 some byte buffer before sending any data out.
So now in real life, the robot communication lags about half a second (until the buffer is full), but then the controller get 5 different servo positions at once. It's useless and makes the originally very smoothly moving robot behave like a - um - B-movie robot.
So the alternative would be to use a WLAN-to-RS232, but will I get the same problem with lag. Does anyone have any experience with those? Which one should I get? I'd prefer raw solder-yourself modules over some clunky plastic box.
Any other true alternatives? UHF?
Thanks for opinions,
Matt
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
This isn't unusual, and the buffer issue affects some other interfaces as well, including a number of implementations of USB. One way around it is to pad out the buffer with null (or otherwise "do nothing") bytes. Have you tried this?
-- Gordon
News wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I'm also surprised that there is no way to turn this behavior off.
OP, did you try editing the driver settings? I know that, for instance, you can tell a modem to turn off this type of wait/compress cycle. I did this a long time ago to play Bolo on the internet with a 56k modem with less lag.
--
|\/| /| |2 |<
mehaase(at)sas(dot)upenn(dot)edu
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Mark Haase wrote:

At least for USB the 64-byte packet seems to be fairly standard. I'm not sure if it's part of the USB protocol or just the FTDI chips that are so popular.
In the case for the FTDI chips you can send data in 64-byte packets, which probably means some empty bytes, which should be harmless; toggle the DTR line (works with only some of their chips); or just wait for the buffer to self-flush. They offer some nice data sheets on optimizing latency and flow-control.
A sometimes visitor to the SD robotics user group, who also works for a company that sells Bluetooth radios, demonstrated some "hive motion" robots that appeared to have little or no trouble with latency or buffers, so some of this may be product-specific.
http://robotics.fullthrottle.com/Articles/Buildingtheradio.html
One of their products, EmbeddedBlue, is designed to connect directly to the Basic Stamp. Example code shows dealing with the buffer. (I have not used these boards, but have seen them demonstrated.)
-- Gordon
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ah, well, the controller on the receiver side does not like 'empty' bytes at all. Toggeling the control lines btw was something I tried and it *does* flush the bytes in the buffer out, but for some reason, flushing plus setting a control pin plus clearing a control pin takes a fourth of a second. I need to send data at 30 or better 50 commands per second though :-/
Thanks much for the link.
Matthias

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I tried the usual COMM line stuff to flush buffers, set the output buffer size, etc., but to no avail. I have not found any way to directly modify Bluetooth driver settings in Windows XP. Any ideas?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Just an Idea... ...that using two or more transceiver pairs to throw data should be twice (or more) as fast! Just use two (or more) seperate carrier frequencies. ----------------------------------------------------------------------- Ashley Clarke -------------------------------------------------------

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ah, nice idea.
I still need to find out how to do changes to the BT side. The serial connection looks just like a com port, and thre are no extra settings like carrie frequency.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yes, I tried to pad. And while I am getting a nice regular tranmission of blocks, I am wasting a lot of bandwidth on the receiver (RS232) side. But worse, the controller expects data blocks with correct checksum and hickups at 'do nothing' zeros by running out of sync. This at least will be solved as soon as I get my own controllers soldered.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
News wrote:

Latency on 802.11b/g systems sucks, too.
In particular, avoid the Sveasoft Linux software for Linksys wireless modems. We have three of these units, and have established with a packet sniffer that the units mangle TCP packets. Apparently, even when the "firewall" code is supposedly turned off, it's still doing something, and when there are more than two or three packets in flight, it consistently mangles one of them, causing checksum errors.
                John Nagle                 Team Overbot
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
News wrote:

Have your tried "FlushFileBuffers(...)" on the serial port file handle after each write?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yes, I did. No change in behavior. The BT com emulation still waits until it has eiter 64 bytes in the buffer, or a 30th of a second.
By building my own controller, I am now able to send 64 byte blocks, getting 30 data sets per second, working my way to the required 60 data sets.
Still, a little bit more controll over the BT side of the Com port would be nice... .
Thanks,
Matthias

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Matthias Melcher wrote:

It sounds like you are bumping into an SO_RCVLOWAT or SO_SNDLOWAT issue with the socket. I'm not familiar with your system, but if it is using sockets to communicate, see if there is a way to set socket options on the system.
Alternatively, you may be seeing the "Nagle algorithm," in which case you should look for a way to specify "TCP_NODELAY" on the socket.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ah, good hints. I have to check out the socket interfaface for BT soon as I am running into all those restrictions. I use sockets for ethernet connections, so it should not be too difficult to adapt as long as the serial receive module understands me.
I am using the WIndows XP COMM port emulation:
CreateFile("//./COM15", ... etc.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.