Kurt, I recently got a new android phone, running 4.4.2 I believe. I should be able to now test MCOMM with BLUEM. will try it out soon. Steve
On Wed, Mar 9, 2016 at 4:07 PM, Kurt McCullum <[email protected]> wrote: > Sort of. The H register delay in the original source is 20 which according > to Ken gives a 3ms delay. I've had to set it between 80 or 90 which is a > little over 4 times that delay. When I transfer a 6k file through the serial > port it takes between 6 and 7 seconds. Over Bluetooth its just over 9 > seconds. So it is definitely slower but surprisingly reliable. I have not > found the best delay value yet so I'm still trying to get as much speed as I > can out of it. > > That's a good tip about tweaking the adapter itself. I may be able to reduce > the packet size. > > It's the small packets back and forth on the directory listing that really > show the delay. And if you have two pages worth of files it's painful. > > > Kurt >> >> >> Interesting. So increasing packet size wouldn't help because the directory >> enumeration would still be small messages. >> >> We could design an extension where multiple directory entries are packed >> into a single response. >> >> Barring that I suspect Bluetooth is buffering small packets to make larger >> messages. The directory traversal message is very short so the Bluetooth >> device may be waiting to see if we're going to send any more so it can build >> up a larger packet. We're not so we end up incurring that batching wait >> every time. >> >> That might be configurable in the Bluetooth device so that it will wait >> less time to batch a message. Assuming that's what's happening >> >> -- John. >> >> >
