Navigation
» About
» GitHub
Mottek Blog
» Mottek
» Archive
2023 2022 2020 2019 2018 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004 2003
Search
0.7.6
Finally. I think I nailed the bug in Blunt which caused the random restarts. Or rather, I replaced the code which I suspected to be not working. The root cause was clear, data being received with no place to store. In the original TAsyncSerTool, the data is left in the input buffer, and before, I was removing it and storing it in a temporary buffer in Blunt. Now I just check if a HCI packet is complete, and if not, I just leave it in the input buffer. Seems to work quite nicely, so everybody having trouble with Blunt causing restarts should switch to 0.7.6!
Poll? Final?
The T68i is now accepting data over BtOBEX. It does some things differently in the RFCOMM connection establishment, mostly regarding compatibility between the 1.0b and 1.1 versions of the Bluetooth spec and the use of the Poll/Final bit. Also, there was a small bug in Blunt. I’ll have to test my changes with some other devices and also GPRS, but the T68i looks promising at the moment.
In the ER…
… are currently an older BT2000E Bluetooth card and a SonyEricsson T68i. Thanks go to Ronnie and Marty for the loaners! A quick examination showed that the BT2000E is probably a tough case (the serial chip is using some unknown parameters), but the T68i looks better (it has some problems on the highest RFCOMM layer). More soon.
Serial Drivers
Now some background information about making the Air2Net card work with Blunt… The card uses a 16950 serial chip, which is in the default configuration compatible to the good old 16450 chip. The problem is however that this also means that the transfer buffers are only one byte “deep.” This causes immediate overrun errors as soon as a bit more traffic is going over the wires. Fortunately, the ‘950 is simple to switch into other modes (‘550, ‘650 and ‘750), so all that was necessary was to use the TSerialChip16450 class to talk to the chip and set some registers. The result is a new simple helper class which will from now on contain the chipset specific parts of Blunt.
On a related note, Daniel Padilla has gotten his hands on a Conceptronic CF card. Unfortunately, connecting to that card crashes the Newton. It too uses a 16950 chip, but it seems that it advertises its I/O space in a way that confuses the Newton, resulting in a crash when the registers are accessed. It would probably be possible to hardwire the correct parameters, but Daniel wants to take the card apart and use the internal module directly, similar to my setup.
Bluetooth Hardware
I’m currently working on an AmbiCom Air2Net BT2000 driver for Blunt (thanks for the loaner, Zac!). It is highly likely that this CompactFlash card will be supported without restrictions. So we have the PICO Card, the internal modules, and now the BT2000 card. The BT2000 card is not very expensive and consumes very little power. It looks like a good choice if you are living in the US since it is readily available there. For Europe, the PICO cards show up regularily on eBay, but I suspect that the Conceptronic Bluetooth CF cards could work as well.
Field testing
The internal Bluetooth modules behave really well. No ugly cards sticking out, very low power consumption and adequate speed. Some improvements would be automatic reception of items in the Inbox, which should not affect battery life at all. Also, there are some sporadic restarts which are probably due to a buffer overflow in the NewtonScript adaption layer. Otherwise, I’d say that this was definitely a very successful hardware and software hack!
Case closed
My Newton’s case that is. It seems that the current wiring is more or less ok so I screwed everything back together. The Bluetooth module is powered when the Newton is on, and it’s off otherwise. I still needed to figure out a reset method for the module since the two power lines are independent. There is this practical serial channel 3 select signal on the internal J6 connector which works nicely as a reset line. Now whenever the Newton reboots or is powered up, I reset the module. Power consumption is great, when active, the total is always under 100mA.
An alternative to this would be to power the module all the time and use a voltage regulator to get the 1.8V out of the permantently on 3.3V line. Maybe another day :)
But there is still a Heisenbug in the whole setup. I’m not exactly sure if the channel 3 is up to speed or if I really should get the RTS/CTS handshake working, for now I have to use a Wait(1) after each HCI packet. That’s a minimal overhead. Would be nice though to know what’s going wrong.
Much better
The switched 3.3V line works. I hope it doesn’t cause any long term problems. Now the module is powered whenever the Newton is switched on. It takes under 10ms for the module to get into stable state, so switching it on and off is not really a problem.
Somebody with the skills to solder the dongle killer should be able to wire the BT module as well. Of course, a ready made module like the SER-001 would be much nicer!
Power trip
The problem of the module sucking too much power when the Newton is switched off turned out to be quite interesting. The 1.8V power used for the module core is turned off when the Newton is off. But the 3.3V for the I/O lines and the memory is still on. This causes the module to go into some weird state where it drains about 40-50mA. Now I’ve got to either find a 3.3V source which is also switched off, or a 1.8V source which is constantly on. There is already a candidate for the switched 3.3V source: The power supply for the PCMCIA slots…
This sucks …
… a bit too much power. The Bluetooth module is supposed to draw only 12mW, but it drained my (admittedly very worn out) rechargable battery pack in 10 hours. And this while the Newton is off. Frank Gruendel has measured that the Newton draws about 1mA when off, which probably comes to around 5mW. Clearly, something is wrong. But after Reading The Fine Manual - which always seems to be a good idea, if you find it in the packing material -, I noticed that the RX and CTS lines need a 1k resistor. I’m now letting one Newton run down it’s battery while switched on, and another one switched off but with the module sans RX and CTS lines installed. This should give me an idea how much energy my battery packs still holds and how much the module will draw.
In the worst case, I’d have to add a switch. Ideally however, this problem (if it still exists after adding the resistors) should be solved by controlling the power to the module via the DTR line. Unfortunately, I don’t have neither the tools nor the skill to build something myself - it’s already quite astonishing that I got this far!
The final setup I’m planning to use also requires a bit of Newton case modding. The antenna should stick out of the case a bit because the case is shielded from the inside with some sort of metal layer. I scratched some of that off in an area where the module sits, and the range is actually quite good. The antenna is now there where the plastic cover for the SER-001 (or modem or audio-in or …) was. Not too attractive, but hidden behind the port door all the time. A bit epoxy modelling might take care of this later. For now I’m enjoying the first Newton with a built-in Bluetooth module, surfing the web wirelessly!
Yes, yes, yes!
Wasn’t this fun! I struggled quite a bit hooking up one of the internal Bluetooth modules to the Newton, but finally managed to get some results. Turns out that the CTS and RTS lines need to be switched and that it helps a lot if you actually provide all necessary power lines to the module. I was trying for a while to run it on 3.3V alone, but the actual core needs 1.8V as well. I’m sure that any hardware designer would have ran out of the room screaming observing how I found all requried connectors on the mainboard, but so what :) The thing runs and answers nicely to a HCI reset command with a command status event. Let’s hope that things stay that way!
They’re here!
Two internal Taiyo Yuden Bluetooth modules. Now let’s see how they can be wired to the Newton’s internal serial slot.
No SyncML for you!
I played around a bit with iSync and mod_ssl to see what’s going on behind the scenes when using .Mac to sync your data between devices. Too bad things haven’t changed much from this. The protocol to the .Mac servers is clearly not SyncML (and probably will never be. Apple wants to make money with .Mac). That makes a universal SyncML client for the Newton a bit more limited in scope. But so what :) I think I’ll still give it a shot at some point!
Finally
Neo 0.8.5 contains an important bug fix that now enables sending OBEX data via Bluetooth to MacOS X and is required for correct OBEX transfers from the Newton in general. The bug was that the length of the overall object was sent incorrectly which lead to a timeout during transfer. Things look actually quite usable now!
Timers cont.
Timers are working now on the comm tool level. Most things are already in place, just a custom event class needed. A comm tool is running as a task and has already a port to where you can send messages. The message handling function is also implemented, it’s called HandleRequest. I now send deferred messages from Blunt to itself and have a nice timer mechanism. This helped in getting around the lost packets issue with MacOS X.
Windows
Ok, pairing from the Newton works now which is at this stage more or less required for Windows. But Windows doesn’t seem to like the duplicate L2CAP packets which Blunt sends for connection establishment. Seems like I have to figure out how to use timers in Blunt… Also, Windows refuses to accept OBEX data items. Could this be the same bug which causes Mac OS X to silently drop incoming objects?
Vacation is over
Time to start hammering again - and working off my backlog of emails! I just made some small adjustments to Blunt to improve Windows support. Pairing is the first step, and it looks like initiating pairing from the Newton works at least to Mac OS X and my 3650.
I also investigated SyncML a bit. I’m not sure if Apple will ever open iSync enough to allow true SyncML integration… they seem to use server authentication from iSync, most likely to see .Mac services. Instead of using iSync and .Mac, my plan is to play around with my own SyncML server instead and see how much effort a SyncML client for the Newton might be. I got Sync4J running on my Cube, and the vCard and iCal files used by SyncML should be importable into Address Book, iCal and also IC/VC.