I'm currently working on the Bluetooth setup application, or to be more precise, on the device discovery feature. The Bluetooth setup application will be used to discover devices, pair with them and set system-wide parameters such as connection speeds.
In the process, I hit one of the tougher problems in projects like this: Figuring out what the existing NewtonOS code expects to happen in a new component (such as a new comm tool). It's a very tedious process... currently, there seems to be an off-by-one error in the data transfer back to the NewtonScript world. For certain input scripts (mostly those which read byte by byte), the last byte in a transmission is lost. This bug also causes the PPP negotiation phase to take forever.
I also still haven't found out why PPP is so slow. It seems that the peer device simply takes its time talking to the Newton. At least on the PPP and HCI level, I can't see any retransmits or packet errors. But I'm working on it.
With Courier 0.5 out, I've got now again some more patience for working on Blunt. Caching and download were something that just had to be in Courier, but now it's Hammer time again.
One remarkable step forward today was a successful PPP connection over Bluetooth to my Linux machine. There is however something seriously wrong with either the MTU size, the ppp daemon or flow control: Transfer speed is about 400 bytes per second. Not really breathtaking. That prompted me to get OBEX working reliably to get some alternative numbers. There were (and probably are) still some rough edges in the L2CAP and RFCOMM layer. A remaining mystery is why some packets get garbled right after connection establishment. But simply sending them again helps.
Anyway, the speed over OBEX is more satisfactory: about 10-15k/sec from my Mac, which is quite good considering that the serial speed to the Bluetooth card is 23k/sec. I guess that the slow PPP speed is related to the failure of establishing a PPP connection to my 3650...
There was an interesting discussion on NewtonTalk on printing. I do not print very much anymore - it was exciting in the beginning, with devices such as the toilet roll printer that worked with the ZX Spectrum, or the first inkjet printers - but the amount of material I would have to print for doing my work is simply too high.
But on the other hand, a challenge is a challenge, no matter how you look at it! So I investigated how much it would take to enable TCP/IP (or rather, lpr) printing from the Newton. And it seems quite feasible. Praise the NewtonOS again for that. A lpr printer driver would be a subclass of the TPSPrinterDriver protocol class, similar to the TPSPAPPrinter which does AppleTalk printing. I played around a bit, and got a dummy printer class working. It only needs the code to initiate the connection and send some data. Unfortunately, connecting over TCP/IP requires grabbing a link and doing a DNS lookup, something which wasn't really planned in the current printing process. I guess it would have to be done via a proto patch of the printing transport...
I've been fiddeling around with Courier over the last couple of days. One of the planned improvements is caching of pages in the history and it seems to work reasonably well now. One problem however resurfaced: The protoTXView can use a VBO to store large text files, but it seems to be somewhat unstable. Sometimes, the stored data gets corrupted, resulting in -10600 and -10061 errors. The workaround for now is to have either history caching or VBO usage.
Sometimes, things just don't want to work as designed, you encounter Heisenbugs, random errors show up, and finding a rational explanation is way too much work. In these cases, "let things settle" is a perfectly valid strategy! L2CAP connection establishment was a bit flakey in Blunt, so I added a command to get the link quality before initiating the connection, delaying things a bit. Seems to work so far. And I got the first bytes sent over from the Newton as a connecting device to the Mac machine.
Starting a PPP daemon on the Mac to let the Newton establish a TCP/IP connection via Bluetooth should be possible now... but there is still lots of additional code required, especially the Internet Setup/Blunt coordination is missing (stuff like peer discovery, finding the correct RFCOMM port, handling pairing etc.)
Connecting to a Linux machine via Bluetooth works now. Data transfer seems to work as well, but that's not really verified. The 3650 and Mac OS X don't like some of the connection parameters used in the top level RFCOMM layer, but much of the lower layers is implemented. Some mysteries still need to be solved, for example the timing when sending packets via the HCI layer. Sometimes, the packets get lost... what would help is using delay timers, but that's an area I've tried to avoid so far. Timer events should however be a universal feature on the NewtonOS, and they would help in making the Bluetooth connection more reliable.
I also cracked open a no-name USB Bluetooth dongle to see what kind of module is inside. Unfortunately, Bluetooth modules often come in either UART or USB flavor, and the module I found is a USB only module. So much for getting cheap internal Bluetooth on the Newton! The modules from BTDesigner.com are not that expensive, but shipping is about $30...
One thing that got a bit in the way of my development work is that Mac OS X 10.2.8 broke my Bluetooth setup. The system preferences crash in the Bluetooth panel (yes, I've deleted all relevant .plist files) and my Acer dongle doesn't work anymore. Seems like Apple wants people to upgrade to Panther.
I'm almost ready to release a proof-of-concept version of Blunt. It still crashes occasionally and sometimes, a connection can't be established from Mac OS X. But otherwise, I've been able to successfully send files from my 3650 and desktop to the Newton. The bug du jour was a buffer overflow, causing some bytes to be lost here and there, but that's fixed now. The buffer sizes in the various places in the stack definitely need some adjusting!
An interesting related topic are of course Bluetooth cards. The PICO card which I'm using is neither very battery-friendly nor small, so a nice, small, low-power alternative would be great. And it doesn't have to be a PCMCIA or CF card: It should be possible to put together a small PCB with a Bluetooth module and fit it inside the Newton, similar to the SER-001. Bluetooth modules are tiny, all-in-one solutions which can be interfaced with using serial lines and which don't need very much extra circuitry...