PC OS: Fedora Core 3
pilot-link version : 0.12.pre4
Handheld: IBM WorkPad c500
HotSync connection: handheld to pc via usb cable
HotSync Settings: 115,200 bps Flow Control: Auto
GUI: Jpilot version 0.99.7

I recently purchased an IBM WorkPad c500. It is identical to the Palm m500. I have been able to use jpilot to sync data between the handheld, and my PC. However, when I try to install add-on files, I get failed errors.

So, switching to console and running the pilot-xfre command. I get very simular results.
<br /># pilot-xfer -i HARDBALL.PRC<br /><br />   Listening for incoming connection on /dev/ttyUSB1... connected!<br /><br />   Installing 'HARDBALL.PRC'...<br />   ERROR: pi_file_install failed (-202, PalmOS 0x0000).<br /><br />   Thank you for using pilot-link.<br />#<br />#<br />

Well now, what could be the cause of this?
After some lengthy and might I say almost boreing perusal of black and white documents pertaining to my new handheld, I came to the conclusion that my speed settings may be in-accurate. I did not read but just a little further, where the manual states that setting the speed on my handheld is irrellevant in regards to usb usage.

Ok, so once again, I continue through the long and dark hallways of information, as I gleen the files for more information. Well, having the source code for pilot-link, I began to peruse it, to no avail. Although I have coded in C++ in the past, it was to not any great extent, and this seemed to only prove that I din't know what I was looking for.

Ok. So now what? Well I decided to use a freinds windows machine with the PalmOne Desktop software. After doing some investigation, I found that m500 handhelds had a problem formatting 128MB + SD Cards. Could this be the solution?

I installed the required patch from Palm, and Voile' I had a working hotsync link. I reformatted my 128 SD Card, and bingo! I could then load .prc files to it.

So now I am back here on my linux box, to give a go again, and hopefully we can get somewhere :)

1. Just got it Aug 10th-2005.
2. LifeDrive locks up after sitting for a few hours. 
3. LD goes into a RESET after every hot sync, that takes 2.5 minutes
4. 'Files' application makes the unit go to RESET.

I am hoping that PALM can resolve this since I like the looks and potential of the LD, but I will not accept anything less than 100% working for $499.  More new to follow. Please share your experiences.

Mack

I ran into an interesting situation with the LifeDrive and the T5.

(See my previous posts for specifics about using the LifeDrive and the T5 on FC3 and other postings on the site about using the first reported USB device for the LifeDrive although the second reported USB device is typical for Palm devices and specifically correct for the T5)

After backing up the normal (non-flash) portion of the LifeDrive, I attempted to do a backup of the T5. pilot-xfer never detected that the T5 was present and attempting to sync. I followed the same procedure that I always do, which is to start the sync on the T5 before starting pilot-xfer, and using -p /dev/ttyUSB1. (When connecting and disconnecting, check dmesg, as sometimes the hot disconnect processing is not complete and the T5 is assigned /dev/ttyUSB2 and /dev/ttyUSB3; the same is true of the LifeDrive).

However, if I wait until the driver has shown all the messages that occur when the T5 (or LifeDrive) is disconnected, behavior returns to normal and I can do all the backup operations on the T5.

The same is true if the T5 is backed up and I then try to backup the LifeDrive.

This is rather strange, as the connection messages (from dmesg) are identical when it works and when it doesn't. I suspect this is an issue with the particular USB hub in the machine I'm using to sync. I'll try to verify or refute this hypothesis soon and post the answer.

In the meantime, the workaround is simple; just wait.

2005-07-07 20:27:00

The Palm LifeDrive with pilot-link has some serious problems with both functionality and performance. I'm posting information for those who, like me, purchased the LifeDrive prematurely. I've been able to make many things work, but not all. I hope this information is useful to others.

I also have a T5, so I'm able to verify that the problems I'm seeing are specific to the LifeDrive. Of course it is possible for a bug to be exposed by one handheld and not seen on another, but the T5 and LifeDrive are quite similar and the odds are very very low that the problems I'm seeing are pilot-link problems. However, I'm hoping that workarounds can be developed for some of the problems.

My most recent test results, with pre4, are:

T5:

All problems I've seen with the T5 and earlier pilot-link releases have been resolved. Of course my testing is not comprehensive, so there may still be issues, but I can do the crucial operations with the T5, specifically, backup, backup flash (--rom and the other flags telling pilot-xfer to backup the contents of flash), backup the illegal file, and restore.

Install (--install) works without problems.

After a normal (just -b, no flash flags) backup, the T5 shows an error and instructs you to tap to reset the device. Usually the device "hears" the tap, but occasionally it is necessary to use the reset button. The backup appears to be intact. I believe that this problem may be caused, or at least triggered, by an app I've installed. I can't verify this without completely reverting the T5 to factory state, which I don't want to do until the LifeDrive is stable and usable.

LifeDrive:

After a hard reset (with secure erase) I can backup normal memory with "pilot-xfer -p /dev/ttyUSB0 -b /somewhere/or/other"

If any of the flash memory backup flags are used (e.g.: "pilot-xfer -p /dev/ttyUSB0 --rom -b /somewhere/or/other" nothing is backed up and the LifeDrive resets itself. Pilot-xfer displays the name of the first file, and believes that it is waiting for the file; meanwhile the PDA is no longer there (from the perspective of the USB driver).

The LifeDrive is slow. Transfers through a USB version 1 hub take a very long time, and if there is a large file I believe an infinite loop may be entered. (I'll know for certain whether the loop is infinite when I check it first thing tomorrow morning.)