Category Archives: Personal

iPod Video 5.5 Gen Bluetooth Mod

All Photos posted in the gallery above, but modification notes of the key stages below.

Opening the iPod, Storage Mod with iFlash

Opening the iPod and replacing the hard drive with the iFlash storage mode was straight forward. The major thing to take care of is:-
1) When removing the build in battery, be careful not to break the legs of the battery clip. Even though it still holds the battery ribbon cable if a leg is broken, its going to be harder to re-attach the battery
2) Be careful with the ribbon zif cable
3) The top of the iFlash card aligns with a notch on the side of the case. Make sure that it sits properly before assembling the case.

Preparing the Bluetooth Module

Finding the right Bluetooth module is painful. BT5.0 audio transmitters are hard to find, and most are transceivers at a much higher cost. I settled for a BT 4.2 Transceiver board but I had it locked permanently to transmit mode. The main selection criteria was that it was low power and can handle input voltage of 3.3V – 5V. I could also easily remove the audio connectors to get a large enough solder pad to connect to the iPod Audio lines. Once the components are removed, I tested the layout on the iPod to ensure that things can fit. The original idea was to be able to power the BT module using the iPod power lines itself which delivers 3.6V. I also included a small switch to allow me to totally power off the module when not in use.

Preparing the Power and Audio lines

Using a fine tip solder, solder the audio and power lines neatly and extend them out under the iFlash board. Take note that the board may have metal surfaces. I isolated them all with electric tape to ensure no short circuits can occur. Solder the power lines through the switch and audio to the LR of the bluetooth module. I also got a 1000mAh battery to replace the original 650mAh battery.

Audio Testing… Problems!

I reassembled the iPod but did not close the iPod. Tested the audio with BT speakers and verified that the circuit worked. However, on closer listening there was ground noise that leaked from the iPod to the BT module. This seems that this is because the power and the audio shares the same ground. As I usually make use of IEMs, this was unacceptable as it was really irritating and really distorted soft music. Partially closing the iPod also made me realise that the metal backing caused the range of the BT to be severely limited… to about 3m. This was also unacceptable to me.

Plastic Rear Panel

I ordered a new thick casing to accommodate the increased thickness due to components and proceeded to cut out a huge plate form the new back. I then laser cut 2 pieces of acrylic 2mm thick, (1 for spare!) to sit in the same space. This also allowed me to customise the markings on the rear panel. The aim really, is to address the BT range issue. Test assemblies looks great!

Power isolation to Remove Noise

I did several variations of trying to isolate noise between the power and audio. However, due to the shared ground, I was unable to do so with my limited knowledge. I tried RC circuits, LC circuits and power isolators. While all worked to some extend, the moment the audio ground touches the BT board, the noise is re-introduced. Isolating the ground also caused audio to cut out as the ground reference was changed. The final solution was to totally isolate the power supply to the BT by using a separate battery. This introduces another problem of having to find space for another battery and how to include a charging circuit for it. This effectively adds 2 more items to be inserted into the iPod. A battery and a Li-ion charging board.

I dug up a old Li-Ion charge regulator and connected it under the screen. I also identified a location on the side of the iPod so as to expose the micro USB port. Soldered everything in for a test with a separate battery, charging circuit, and the audio noise is gone! The charging circuit also works well.

Care must be taken when trying to dremel-cut a slot for the microUSB port. The metal structure around the iPod is fragile. Be sure to hold it tight when cutting. I did snap mine, but you can still use it even if its broken.

Battery Size Issues

Test fitting everything into the iPod with the thick iPod back case and acrylic back didn’t fit. Investigation concludes that the original 270mAh battery used was 6mm tall and couldn’t fit under the case of the iPod. The solution to this was to find a thinner battery. I finally decided on one that is 3mm thick but was only rated at 250mAh. This ultimately worked and I managed to fit everything into the iPod.

Advantages of this Modification

The clear advantage of doing this mod is that the iPod is now BT. But I have found that separating the power using another battery means that the iPod still is able to last for about 10-12 hours. The battery for BT is able to last for about 5 hours. The BT charge time is about 1/2 hour as the Li-Ion charger board charges at 500mAh. Upon testing, it seems that the iPod only charges at 250mAh. So it takes 4 hours to fully charge. All in all, charging for 1/2 hour for 5 hours seems pretty reasonable.

The microUSB slot at the side makes it really easy now to open the iPod for repairs. No more hard prying.

Quirks of this Modification

The BT board that I am using automatically goes into discovery mode at every startup. So devices have to be repaired every time. Its not a big deal, but just makes it a little inconvenient if you are picky.

The headphone and hold switch assembly for the slim iPod also seems to be just very slightly different to that of the thick iPod. While it also works, but you would have to adjust it slightly to make it fit well.

The mini switch I am using was old. Pressing too hard on the switch can cause the BT circuit to disconnect. I’d have to change the switch at some point to something of better quality, but it’ll have to do for now.

Edit – 20200702
The switch is now replaced with one that is angled to the side. This makes the switch structure a little stronger and no longer disconnect on slight touches. Also re-ran the power cables under the Flash board. Requires some re-solder, but electric tape is still required on the charging board to isolate it properly. Audio wire is also shortened and re-soldered neatly to the side.

Final Touches

I finished the mod by polishing the acrylic parts as well as the metal housing with Autosol and made a leather case for it. Once nicely polished, the iPod is a fingerprint magnet, but its lightweight, wireless playback connectivity, continued availability of a headphone audio out is a joy to use.

BT sound quality was pretty good but I might choose to upgrade it to one that is BT5.0 in the future if the price is right. The range of BT transmission is about 5m. Carrying the iPod in my backpack and using my IEMs wouldn’t be a problem.

This project took me a few months, with all the waiting for shipping.. but it was definitely a worthy project and I’m very happy with the results!

PalmIIIxe Connection to TTL Uart on Linux – Part 3 – Getting up to speed

Getting past 19200bps

It really took me a long while before I wrote the post. Partly coz I was really tired after all the mods done to my Palm, but also that after I completed it… I forgot. 🙂

From Part 2 when I last left off, I was really having issues trying to get the Palm to communicate with my Linux system at the full speed. 19200bps was the fastest I could go but I just couldn’t go 115200bps.

Getting all the connections right

After quite a few tries, I finally realised that I not only had to get the Tx/Rx lines correct, which addresses the basics of serial communications in today’s modern systems, but also the traditional lines which is RTS and CTS. My resulting connection diagram is shown below. Once that is sired up correctly, I was able to get connected via the DB9 serial from the Palm to a TTL UART with no issues!

Resulting connections with RTS and CTS also connected.
Final connection diagram which I used for soldering

Once the serial port is setup, there isn’t really much else to do on the hardware front. Once it was possible to get to TTL, converting that to USB or directly connection a TTL to a Raspberry Pi using serial is relatively straight forward. Getting all other pieces of communication to work is simply using older instructions of getting the network connection to the Palm using PPP on linux and/or getting Network Hotsync to work.

In addition, this effectively lays the ground of being able to communicate from the Palm to a Raspberry Pi using simple commands sent over a serial port, and then having a simple serial port daemon listening on the Raspberry to execute the received instructions.

Wrote a simple Palm application to communicate simple commands over the serial port which is then received by a Raspberry Pi Mini mounted behind the Palm


Its been a long while since i last completed this set of hardware “surgery” on my PalmIIIxe. i’m really happy that it works, as i now have the software to get my iCal, Contacts all in this traditional handy device. I also have my own USB sync cable for this and have been able to do things like Network Hotsync etc using pilot-link.

I also learnt about a bunch of things on serial connections, TTL and serial communication. Of course, it also brings me back to Palm programming which was really quite a trip down memory lane. I ams also really happy to have this modification not destroy or disfigure my Palm too much. I now have a 10 pin “expansion port” on the back of my unit, but otherwise, everything still works great. i could still install my old games and utilities into it. It also still functions as my desk calculator. It is a little dated, but i could still install Palm apps like games and utilities to make use of it.

The most disappointing coming out of all this effort was that i couldn’t find the right software to be able to receive email on my palm. Writing an email client is out of my league and applications such as Eudora Internet Suite is severely out of date and i just can’t seem to use that successfully anymore; and i didn’t really want to change the configurations of my email service too much.

In conclusion? Modify your PalmIII if you want to make use of it somewhat. Using AAA batteries is great, and i’m talking about battery life that goes for weeks instead of just a day. Don’t expect it to be transformed into a daily companion now though as you will be challenged to find the software or hardware to be able support all the modern goodies we are now so used to such as Wifi. But having no Internet on the device could also be good…

Its nice to get away from modern tech and connectivity sometimes, and return to simpler times.

PalmIIIxe Connection to TTL Uart on Linux – Part 2 – Internal Modifications

Getting a good clean signal over the serial port was really important. After a fair bit of use of the acrylic laser cut connect, it was found that it constituted too much trial and error in manually making the connection. So the idea to actually modify the Palm serial port into a connector started to take root. The key idea is to look for a space on the Palm, solder the connector and have that connected permanently on the Palm, so that when required, an add-on board can be used to expand the capability of the unit, instead of mucking around with the 10-pin port.

Opening the Palm, Soldering the pins

Opening the palm was easy. I followed a post from iFixit to get that done. It was then decided to put the pin connectors on the flat portion at the back of the Palm. The PCB at that area was also empty giving me space to work the wires. I used an isolating tape to mask off the areas where the 10-pin was frequently used by external accessories and soldered “backward” the wires that would extend to the connecting pins.

External view of the connecting pins to the serial port

The wires are then routed internally along the edge gaps of the palm and soldered underneath the cover.

Tapping on Serial Cable connections and routing the wiring to the back case

On the PCB, insulating tape was also used on the PCB to prevent short circuits just incase the pins were to touch and scratch the board.

Back case view of serial extension pins. Electric tape on the bottom motherboard to prevent shorts

All these are then carefully re-assembled, hiding all the wires within the Palm. The end result is a neat package with no visible modifications to the 10-pin port.

View of soldered pins with back cover reassembled

The exposed pins shows up on the back, providing a slight improvement in viewing angle when placed flat on a table top. A cover was made to provide some amount of protection to the pins, but I have found that is usually unnecessary.

Assembled back case with cover to protect the pins when unused
Palm resting on a flat surface

Upon re-assembly, a functional check was done to ensure that everything is still working…. and it is.. yeah!

Reassembly boot test

Connecting an Expansion Board

The connector pins lines itself up to a 5x7cm DIY PCB. The connection is fairly straightforward and acts as a breakout board for additional functions like the adding a Hotsync button. Jumper wires are used to extend and connect the various pins to additional circuitry making it a lot neater to deal with. Some pictures below to illustrate what was done. Overall, it wasn’t rocket science, but it surely made the connections a lot easier to deal with.

Breakout board for serial pins. Lower pins for external connectivity to Bread Boards
Side view with clip velcro holding board down. Feels like a RAM style extension board!
Breakout board in action with external development board
Side view of how everything attaches together when in use


All the above and previous work finally made sure that I was able to have a good way to achieve a “break-out” of the palm pilot pins unto a PCB which I can then work on. This made it a lot simpler to connect things like resistors and other ICs. As noted in Part 1, this kinda fixed issue 3-6. But now I have to begin working on question (3)…. how do I get the baud rate past 19200? And why can’t I get PPP working? All that experimentation would be detailed in another post.

PalmIIIxe Connection to TTL UART on Linux – Part 1

Serial ports are obsolete. So trying to sync the PalmIII to a modern desktop becomes a pain when you need to convert the serial port to a USB. The use of an adapter is to unwieldy to carry about, so the hunt for a PalmIII serial to USB cable begins…. and it ends rather quickly. It is very hard to find, and very expensive. So comes the consideration to make one yourself. Keep in mind that what I wanted to do was to create a cheap Palm to USB serial connector so that I could have PalmOS talk to a linux… for the purpose of… whatever.

Huge DB9 Serial to USB adapter. Expensive too.

Initial Research

On browsing the internet, there is no lack of information when it comes to documenting the PIN outs of the PalmIII serial port. I have reproduced the one that I found the most simple/useful here.

PalmIII Pins and its uses

This is just great, as it also seems to coincide with most of what other people have done with their old PalmIIIs, using it as a serial terminal. A lot of the mods out there seem to simply open up the Palm and solder stuff directly to the TX and RX lines and hooking it up to their Raspberry PI or otherwise. I didn’t want to do that as I didn’t want to “destroy” my Palm. I still wanted to be able to use it for games and to bring it around (thats what I wrote all the sync software for isn’t it?). So the goal was to have a way that my palm can interface with a modern linux system, over USB, get on the internet etc, so that I do fun stuff with it, and get continue to get the same goodness of the original Palm for use as a PDA.

This is where I made my first mistake.

Mistake 1: Not understanding Serial

I have mistakenly thought that it is simply enough to connect the TX/RX lines. But it turns out that TTL levels are very different from RS232 on a DB9 connector. The former ranges from 0-5V and the latter can swing from -9V to +9V or more. Even though both are serial ports. Hooking up directly shows gibberish on PocketTerm (by Plushworks), but it definitely shows something. This means that the first thing I had to do was to try and convert the RS232 signal to TTL. Upon digging a little more, I came across a connector for Serial to TTL. So I ordered one to try.

RS232 to TTL convertor

Problem 1: The Palm Serial Connector

In order to be able to create a direct connection from my PalmIII Hotsync Cable to TTL Serial in a small form, and do away with bulky connectors, I had to desolder the DB9, and directly interface my Palm connector to the serial port. Thats where the connection diagram proved useful. However, I didn’t want to destroy my Palm cable by cutting it. So I had to have a sustainable way to re-create the Hotsync connector so I could build things from it in the future. For that, I designed, with some interactions, an acrylic based connector which I can laser cut, then hook up at low cost. Its not fantastic, but it works.

Two self laser cut connectors for the PalmIIIxe. Connection isn’t fantastic, but it works.

There are a few issues however, that the height of the pins has to be exact. Otherwise the connection to the palm is flaky. So while doing this helped me get past certain roadblocks, using these connectors wasn’t the way I ultimately ended up with. More on that another time.

Hooking things up

Once I had the connector made, with breakout for all the lines, I followed the diagram below and started connecting it to the RS232 to TTL serial adapter. Putting everything on a breadboard, I decided to go a step further and actually put in some LEDs in order to have some visuals when there is traffic flowing or when the port is open.

PalmIII Connection to DB9
Serial to TTL convertor based on Max3232. Note that yellow TX line connects to TX on UART0
Breadboard with LEDs to show activity on Serial over TTL, UART0 connection

The sketch below shows how I hooked up only 4 lines to the TTL and had my first successful sync with pilot-xfer. The connecting system is a Cubietruck which has an onboard TTL serial (UART0) which I connected to. The resulting port on the UART is /dev/ttyS0. The testing software used was, on the Palm side PocketTerm, and on the Linux side, Minicom. The settings used to test are documented in the sketch below.

Cubietruck UART0 wiring. Note that VCC comes from another 5V pin.
Serial to TTL wiring and testing software settings

The photo below shows the hardware build and connectivity on the PalmIII side. Notice that I have a breakout board on the Palm end with some LEDs which I subsequently added to help my visually identify the state of the serial connection. So this allows me to quickly identify connection behaviour and problems across the Palm the TTL conversion. I also added some connector pins so that I can use jumper wires to hook things into the breadboard without having to re-solder all the time. Another video below shows the process of a Hotsync…. just some blinking lights there. But I was happy that this was working.

Final Palm and Cubietruck connection over TTL on UART0
Blinking LED lights during a sync over TTL

Further testing with login services on Linux

In general, to be able to offer any kind of service over the serial port, it must not be “taken up” by any other service. So I had to ensure that there are no other boot up service that is using it. As I was using a Cubietruck with the Armbian image, I just had to disable the console from the boot environment.

On Cubietruck, Armbian Distribution
delete “console” in armbianEnv.txt
or change

Just to bring it a step further, once I was able to establish a serial connection at 9600 or 19200 Baud to the Linux system, I tried offering login services on the Serial Port. In may posts, I have noticed that folks are trying all sorts of setup to be able to permanently offer a login prompt over serial. However, this is not something that I wish to do. I wanted to be able to (1) know exactly the service that I want to offer, and (2) have control over when I offer it. The following command provides a login prompt over the specific serial port.

On Cubietruck, Disable Serial Console on Boot
cd /etc/systemd/system
systemctl mask serial-getty@ttyS0.service

Once done, you should be able to get to a login prompt when connecting over the serial line.

Logging in to a shell on the Palm

Problem 2: Maximum Baud Rate of 115200 is Unavailable

While everything works on 19200 on Minicom and PocketTerm, but when it comes to Hotsync, for some reason, I can’t get it to go above 19200 Baud rate. This holds true for Hotsync, but not the Minicom+PocketTerm combination. All research on the internet doesn’t seem to talk about why. This was a head scratcher for me. Every thing I have read seems to only say “4 lines i.e. Vcc, And, Tx, Rx, and it works”. Poking around the settings on the serial port in linux also didn’t seem to help. So while I was happy that I could now perform a Hotsync at 19200, I wasn’t completely happy as I couldn’t use the max rate of 115200.

Problem 3: Trying to Setup PPP from Palm to Linux does not work

Trying to survive on 19200 Baud rate, I tried to setup PPP on my linux system such that I would be able to get a network connection routed from my Palm to the internet via the linux machine. This was working using my bulky Serial to USB adapter, and I wanted to replicate this with my connection. However, this wasn’t the case. Trying to setup a connection continually fails, with the server side being stuck at the following message.

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7ba91055> <pcomp> <accomp>]

All this seems to indicate something was wrong. It seems that having just Tx and Rx lines being connected isn’t enough. I started to wonder if the RTS and CTS lines needs to be connected as well. And if DTR needed to be connected.

End of Part 1

At this stage, lets review what was accomplished/learnt/questions:-
1) I have managed to get my Palm connected to a UART TTL Serial Port at limited speed
2) A Max3232 logic convertor is required to convert RS232 signals to TTL
3) The base Palm Baud rate seems to be 19200.
4) Connecting with just TX and RX provides connectivity over serial at the base baud rate, but can’t seem to get to the max speed of 115200 for Networking or Hotsync
5) Do we need all 10 pins to be connected as is in the diagram to be able to replicate the functions of the original HotSync cable?
6) We need to have a clean, stable and extensible way of connecting the Palm Serial port to a breakout board for further development

Points 3-5 seems to be interrelated, and in order to solve it, I had to first have my serial connector be reliable as stated in point 6. As noted earlier, my self made connector seems a little flaky when trying to connect to the serial pins. There was therefore a need to change the way I connected to the serial pins before I tried to tackle this.

I think that, point (6), deserves another post. So till my next installation, where I will highlight what I did to improve the connectivity situation to the 10 pins on my Palm.