Are those times just for the upload or do they also include the time taken to locate and open the connection? I always tend to use a USB connection for downloads....
Here are some figures I put together a while ago, for raw comms speed...
First I measured the round trip time (or latency), using a simple program
to send a single byte and echo it back. The results are:
USB PC->NXT : 1.8ms
BT PC->NXT : 53.8ms
BT NXT->NXT : 46.6ms
RS485 NXT->NXT rtt: 5.7ms
The second test increased the transmitted data size from 1 byte to 512
bytes with a single byte response. The table below shows the (average)
time taken for a single 512 byte packet with the resultant bandwidth in
USB PC->NXT : 5.1ms (100KB/s)
BT PC->NXT : 67.3ms (7.6KB/s)
BT NXT->NXT : 132.4ms (3.9KB/s)
RS485 NXT->NXT 512 + ack: 22.0ms (23.4KB/s)
Finally I tested the transmission of a 512 byte data packet, but without
any form of acknowledgement (so the data was in effect streamed):
USB PC->NXT : 3.9ms (131KB/s)
BT PC->NXT : 26.7ms (19KB/s)
BT NXT->NXT : 45.2ms (11.3KB/s)
RS485 NXT->NXT 512: 19.1ms (26.8KB/s)
So your times do include the time to open the connection (but not to perform a search)... On my system (using Lawrie's latest pccomms code that caches Bluetooth addresses, which I think is the same as specifying an address)... I uploaded a program 22757 bytes long in 4094 milliseconds so that is 5.5K/s which is pretty much in line with my test results...
This is with the brick next to my computer and using a Belkin Bluetooth dongle which is a class 1 device (most are class 2).... My upload was from NetBeans (using the standard leJOS nxjupload command)...
This post pertains to expected round-trip latencies over Bluetooth (PC <-> NXT) and why I might be seeing times an order of magnitude slower than your results. I am new to leJOS and Bluetooth.
I am testing the performance of Bluetooth connectivity. This snippet of code from the PC writes an int and reads it back. On the NXT it reads and writes back. No other delays. dos and dis are data output and input streams respectively:
long t0 = System.currentTimeMillis();
long t1 = System.currentTimeMillis();
System.out.println("Executed round trip in " + (t1 - t0) + " ms.");
The results are in the 750ms range pretty reliably which is way higher than you were reporting. This is with the brick beside my computer.
I am using Snow Leopard. It is a Broadcom bluetooth device - class 1.
If you have any insight into why these numbers are so high, or if indeed others find similarly high numbers, I owuld be much obliged.
Is that a one off test or do you run it in a loop? I suspect that sometimes the initial packet is slower. The figures I gave are all for doing a number of round trips and then taking an average... I can certainly confirm the streaming data rate with my PC to NXT as being around 18Kbytes/S as I've recently been doing some work that required greater than 15Kbytes to function. This was on Windows 7 (my previous tests used Windows XP), so it looks like the MS Bluetooth stack works pretty well in both versions.
Other than that sorry can't really help. Perhaps it is the hardware or software you are using?
Just to be sure I've just re-run my test. I basically took the BTSend and BTReceive samples (with BTSend running on the PC), I commented out the code that displays the read data on the NXT and added timing code around the send loop. So the program basically sends an integer and reads back the echo from the NXT, 100 times. On my system this takes 5867ms or 58ms per round trip. Which is pretty much in line with my earlier figures (which used a single byte and more iterations)....