Bluetooth vs. WLAN to control biped

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:

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.

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.

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

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

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.

"Gordon McComb" schrieb im Newsbeitrag news: snipped-for-privacy@gmccomb.com...

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?

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

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

Have your tried "FlushFileBuffers(...)" on the serial port file handle after each write?

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.

"Mr Clarke" schrieb im Newsbeitrag news:1115585833.7fd9a2443e01d803099890dab310ea2d@teranews...

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

"mlw" schrieb im Newsbeitrag news:DZCdnZ5Y_ snipped-for-privacy@comcast.com...

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.

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.

"mlw" schrieb im Newsbeitrag news: snipped-for-privacy@comcast.com...