Thanks Steve,
I have tested it quite a bit and it seems to work fine as long as the
TS-DOS delays are in place. It's definitely slower than a cable though.
Kurt
On 3/23/2016 11:21 AM, Stephen Adolph wrote:
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.
