Sorry for the extremely long post. I generally research a little, write a little, research some more, write some more, edit and rewrite... It's a vicious cycle due to the sheer number of branches trouble-shooting can take. Most problems are solved in advance by looking for possible answers and then weeding out the less likely ones and testing the rest. Use what you need from this post and ignore the rest.
If you no longer have that RJ-11 to DB9 connector you need to tie the signal ground and diag pin together manually (or at least check for continuity), and then connect both of them to the RS-232 signal ground (Pin 5) on the Palm.
Heres why: Until the diag pin is grounded, the ECU is in normal operating mode, not diagnostics mode. Once you tie the RS-232 signal ground and ECU diag together and connect them to the Palm on RS-232 pin 5 (Gnd), then the ECU is put into DIAG ON mode. This could explain why your getting an ECU communications error. The ECU is not transmitting to Jeff's RS-232 transceiver unless you ground that diag pin.
Like I said, there are about a dozen ways to wire a serial port depending on the equipment being wired. Sometimes tying the lines are done just to satisfy one side so it will ignore the particular signals (Ignoring CTS or DSR, tying DCD so that the device believes there is a carrier signal). Some terminals (particularly a lot of DCE type equipment) do not even listen for those signals and will ignore them by default.
You are correct in that DSR/DTR and RTS/CTS are separate entities, the point being is that sometimes we want to 'fake' a "HIGH" signal on a particular pin, so that the comm program using the port is fooled into thinking what we want it to, and not necessarily hanging on a signal that it will never receive because it doesn't exist from the other device. But there is the possibility that Jeff had the typical null modem connections tied inside that RJ-11 to DB9 connector. In other words, the serial port should always have an answer to the questions being posed on those lines, YES it is OK to send and YES we are READY.
Remember unlike a person, a computer can only do what its told, if the OK never comes it will wait indefinitely (think of a dialog box in Windows awaiting a response). RS-232 is an asynchronous protocol. It does not use pure timing, but rather responds based upon signals from the each side (the handshaking). If the handshaking signals stop, communication grinds to a halt while the computer waits. This behavior is by design since serial communications are used for unreliable and noisy links where you cannot guarantee the integrity of the data. It is a scalable standard that allows for very complete handling of errors or no confirmation at all. An example of where all the capabilities are employed is when modems communicate across phone lines, a dumb terminal hooked up to a mainframe, or a serial printer is hooked up half way across a factory. These features can be selectively required, used or selectively ignored depending on the type of equipment and how its programmed.
An example of this asynchronous handshaking in real-world human communications would be two people talking via cell-phones. Cell phones are notorious for cutting out. When talking we periodically check to make sure the other person is still there. If we do not get periodic acknowledgment, we stop sending information and begin putting out a series of queries... "Hello? Hello? Are you there? Can you hear me?". Then we wait. Either one of several things occur. One the person on the other side responds "Yes, I am hearing you, continue", "I didn't get that, could you repeat it?, or simply no reply at all. Depending on which of these responses we receive, including 'no response', we take a particular action. We begin transmitting data from the point we stopped. We begin transmitting again, but repeating from the point which the other party said was not received. Or, we simply wait for a period of time not receiving any reply and hang up to wait for the connection to be resumed.
Most communications problems are simple unintentional mis-interpretations (just as in real life). How many times have we been talking on a phone and realized that the other side had not been receiving for 30 seconds or more. How many times has someone mis-interpreted a message because they were distracted or the content of the message changed while relaying it to a third party (through grape vine effect). How many times have we left a voice mail and it cut off before the message was finished. While we have the ability to filter and correct the context, for a computer this is fatal. If the data is not 100% correct it is unusable, i.e. a garbled mess of 1's and 0's.
RS-232 connections are pretty tolerant of connecting different pins. I don't think you will hurt anything.
Another thing to consider and try is to use a different program such as pocketlogger vs MMCd.
You can get a palm for testing from Ebay for next to nothing. Same with the serial cradles. I wish I was closer.
Now realistically if we cannot get this thing to work with this Ique, any $20 palm will suffice to hook up and log since you already have everything else you need.
I've been reading through the posts on the MMCd thread on 3SI.org (89 pages deep). There is a mention mention of a "serial fix". MMMd thread on 3SI Handango 'Serial Fix'
The references to some of the loggers needing the actual RS-232 lines to operate on the less-than-standard RS-232 on the newer palms. Could be that we simply need to patch into the RTS and CTS lines from Jeff's installed RS-232 transceiver chip for your Palm to be happy.
Someone has reported getting a Treo 650 to work as well as a Palm Tungsten T3 at non-standard baud rates. I do not think we are at the end of the rope here. There is a lot of work being done trying to get these newer generations of Multimedia capable Palms working so do not give up. I think we can get this to work. I only wish I was closer and able to lend a hand. We may have to hack a custom test version of the RS-232 transceiver circuit to get this to work reliably on your Garmin. The end result is that we may aid the entire community. I think this nut can be cracked.
We need a couple of things defined.
1: A proper schematic of your circuit and circuits you have eliminated as not working.
2: The pinout of your particular garmin ique 3600 (I found several but I'm unsure which fits your unit)
3: The version of MMCd you are using.
4: The Palm-OS version.
6: The type chip Jeff is using and extrapolating its schematic. (Been reading on DSM-ECU)
5: Document your settings you have tried and the resulting error code.
Lets do this methodically. You will likely need to buy an RS-232 Break-out box or analyzer so we can see whats happening on the various lines. This will let us transparently see the communications taking place and why they are stopping. I've listed some below. We will simply jumper this in to the circuit between the ECU and Palm.
You don't need all of these things. These are just some items indicative of sorting out problems like this. A simple trip to Radio Shack or a decent Electronics/Radio shop will yield a lost of what you might need without the guesswork. You might even be able to find a couple of Ham or CB radio Gurus who could probably fix this problem or at least diagnose it.RS-232 jumper boxAnother RS-232 Jumper box DB9 to DB25 adapter RS232 Break Out Box on Ebay
This is about a $600 analyzer, several are listed above $100 and this one is only $15 (I Love Ebay).Serial Analyzer on Ebay
I also found this listed on Ebay, not sure if it fits your ique:Garmin Etrex serial RS-232 car adapter
You are not a in a boat alone. A lot of people are quite perturbed by the lack of proper support (and intentional witholding of technical information), from hardware manufacturers. Ham radio, electronics hobbyists, automation hobbyists, developers, scientists alike... Manufacturer attitudes of "You don't need to know", "Thats a trade secret", "We didn't write it so we could license and sell it as an add-on". People fork down good money for promised specs and apps the in the end become vaporware. This is what drove people like Linus Torvalds to develop Linux using open source.
The fact the development is continuing and some progress is being made is very promising for all of us.