I finally got the adapter installed. ECU communication error. Now I need to figure out how to swap the surface mount 7.5k resistor with a 100k one.
- Software Upgraded - Reset Your Password to Login
In order to log in after the forum software change, you need to reset your password. If you don't have access to the email address you used to register your GVR4.org account, you won't be able to reset your password. In that case, follow the instructions here to regain access to the forum.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
s_firestone
Well-known member
You'll have to desolder the 7.5, or add a 100K in series. Solder a 1/8 watt 100K resistor in its place, don't worry about needing a surface mount, resistance is resistance. Or add a switch with 7.5K on one pole and the 100K on the other.
Ya, the electronics doesn't scare me too much. It is the physical connections. There is very little room and, from what I can tell, I'll need to just rest the resistor leads on top of the board and solder it that way.
OK, I have no experience with this. I have tried both the 7.5k resistor and the 100k resistor. With the car off I get a "serial comm error". With the car on I get a "ecu comm error". I don't even know what I should be checking to trouble shoot this.
Is it possible I screwed up the rx tx...hhmmm
Is this the same kind of error when swapping from a pc connection to a palm?
Is this the same kind of error when swapping from a pc connection to a palm?
Last edited by a moderator:
s_firestone
Well-known member
It's obvious your getting power since the message changes when you have the key on. It could be simple. Sounds like your serial port is communicating with the RS-232 driver chip in the Logger cable. Could be a BAUD rate mismatch in MMCd.
Very possible. Try swapping and see what happens. This is why I use break-out boxes, breadboards and punchdown connectors when testing a new circuit. Sometimes a device on either side is looking for a signal such as DTR(Data Terminal Ready) or CST(Clear To Send) or DCD (Data Carrier Detect) to be active before communications can continue. Most Null modem tie at least one of these connectors. Also make sure you have a ground.
Which type ALDL to RS-232 cable are using? One for a Palm or one for a PC? If a PC than you need only a null modem adapter.
Null modem pinouts
Very possible. Try swapping and see what happens. This is why I use break-out boxes, breadboards and punchdown connectors when testing a new circuit. Sometimes a device on either side is looking for a signal such as DTR(Data Terminal Ready) or CST(Clear To Send) or DCD (Data Carrier Detect) to be active before communications can continue. Most Null modem tie at least one of these connectors. Also make sure you have a ground.
Which type ALDL to RS-232 cable are using? One for a Palm or one for a PC? If a PC than you need only a null modem adapter.
Null modem pinouts
I am using a permanent rs232 port that keydiver soldered in for me. I lost his adapter and spent some time figuring out what I needed to replace it. That can be found in this post here.
I tried all 4 available options in the mmcd program for baud rate. It didn't change anything. I will try to swap the rx and tx (pins 2 and 3) tomorrow and see what happens.
I wish I had done some preliminary wiring like you described. It would have made this part a little easier.
I tried all 4 available options in the mmcd program for baud rate. It didn't change anything. I will try to swap the rx and tx (pins 2 and 3) tomorrow and see what happens.
I wish I had done some preliminary wiring like you described. It would have made this part a little easier.
Hertz
Staff member
Sounds like you're making it easier on me. Keep up the good work. /ubbthreads/images/graemlins/grin.gif
/ubbthreads/images/graemlins/bawling.gif /ubbthreads/images/graemlins/dunno.gif
Swapping pins 2 and 3 gives me a "serial comm error".
Swapping pins 2 and 3 gives me a "serial comm error".
Hertz
Staff member
Do you have access to a regular Palm for testing?
nope
over on dsmtuner I found this:
Quote:
A "Serial Comm Error" means MMCd is seeing nothing on the RXD line and "ECU comm error" means that MMCd saw it's command echoed back but never received a response from the ECU. A bad cable can cause both errors, but you will get a "Serial Comm Error" is the cable is disconnected and a "ECU comm error" if the ECU is disconnected but have a good cable.
/ubbthreads/images/graemlins/dunno.gif
over on dsmtuner I found this:
Quote:
A "Serial Comm Error" means MMCd is seeing nothing on the RXD line and "ECU comm error" means that MMCd saw it's command echoed back but never received a response from the ECU. A bad cable can cause both errors, but you will get a "Serial Comm Error" is the cable is disconnected and a "ECU comm error" if the ECU is disconnected but have a good cable.
/ubbthreads/images/graemlins/dunno.gif
OK, I have tested every connection from the ecu main board (with the rs232 driver chip) all the way back to the palm connection. It is all correct according to the schematics from above. I am at a loss.
Hertz
Staff member
Can you verify that the serial works from the Q itself? Now that you've built yourself a serial cable, you should be able to sync it via serial with your computer.
s_firestone
Well-known member
Now that you've established this, you have eliminated those two lines. A typical serial port has a couple of control signals (like traffic signals) that determine who can talk and when. On simple communications (known as a dumb modem) or null modem lines these pins are typically tied.
This gets a bit tricky. There are two types of communications equipment:
Data Terminal Equipment (DTE)
Data Communications Equipment (DCE)
Each type is wired opposite one another at the port so that by default, all the proper pins will be connected (Tx to Rx, RTS to CTS, etc).
This is why a PC can connect to a modem with a straight through cable. PC (DTE) to Modem (DCE).
You cannot connect like equipment together without swapping several signals and faking a couple others, this is known as a null modem.
A PC (Which is DTE) will connect to a Palm because the Palm is DCE.
When you try to connect a Palm (DCE) to a Datalogger wired for a PC (DTE) the pins are mismatched. This is where the Null modem comes in, it reverses the signals from DCE into DTE.
So typically a Palm is DCE and an ECU datalogger cable is DCE unless the datalogger is hardwired as DTE in advance. Hence the two types of cables or one cable and a null modem.
Several must haves for a serial port(Assuming 9 pin to 9 pin):
2 Tx Rx 3 (Required)
3 Rx Tx 2 (Required)
5 Gnd Gnd 5 (Required)
7 RTS CTS 8 (RTS, CTS provide each terminal with the "OK" signal to transmit or acknowledge)
8 CTS RTS 7 (Ditto)
1 DCD DCD 1 (Usually tied to DSR, DTR to trick devices into 'ready' status)
4 DTR DSR 6 (Required)
6 DSR DTR 4 (Required)
Likely you are simply missing one signal for the remote (ECU) to respond. That signal is likely RTS/CTS, or DTR/DSR. This may be a signal that simply needs to be faked (set to one level) by connecting to another pin so that the corresponding piece of equipment says "OK", so communications can continue.
Think of how a human conversation takes place. Each person takes turns giving and receiving information. Visual and audible queues are used to determine when to speak, listen, or acknowledge. This is known as handshaking in computer terms. As humans we learn to do it automatically and with a great deal of flexibility. But computers must rely solely on fact. The process of acknowledging a packet of data must be absolute, otherwise the data must be re-sent. The same holds true with determining who's turn it is to talk. The pins on a serial port accomplish that.
Here is another link. Scroll down the page and it touches on hung communications. You may need to check with Jeff on specifics of how complete the hardwired serial port is. That will determine what tricks you must use to make both pieces of equipment happy.
Serial Interface Properties
This gets a bit tricky. There are two types of communications equipment:
Data Terminal Equipment (DTE)
Data Communications Equipment (DCE)
Each type is wired opposite one another at the port so that by default, all the proper pins will be connected (Tx to Rx, RTS to CTS, etc).
This is why a PC can connect to a modem with a straight through cable. PC (DTE) to Modem (DCE).
You cannot connect like equipment together without swapping several signals and faking a couple others, this is known as a null modem.
A PC (Which is DTE) will connect to a Palm because the Palm is DCE.
When you try to connect a Palm (DCE) to a Datalogger wired for a PC (DTE) the pins are mismatched. This is where the Null modem comes in, it reverses the signals from DCE into DTE.
So typically a Palm is DCE and an ECU datalogger cable is DCE unless the datalogger is hardwired as DTE in advance. Hence the two types of cables or one cable and a null modem.
Several must haves for a serial port(Assuming 9 pin to 9 pin):
2 Tx Rx 3 (Required)
3 Rx Tx 2 (Required)
5 Gnd Gnd 5 (Required)
7 RTS CTS 8 (RTS, CTS provide each terminal with the "OK" signal to transmit or acknowledge)
8 CTS RTS 7 (Ditto)
1 DCD DCD 1 (Usually tied to DSR, DTR to trick devices into 'ready' status)
4 DTR DSR 6 (Required)
6 DSR DTR 4 (Required)
Likely you are simply missing one signal for the remote (ECU) to respond. That signal is likely RTS/CTS, or DTR/DSR. This may be a signal that simply needs to be faked (set to one level) by connecting to another pin so that the corresponding piece of equipment says "OK", so communications can continue.
Think of how a human conversation takes place. Each person takes turns giving and receiving information. Visual and audible queues are used to determine when to speak, listen, or acknowledge. This is known as handshaking in computer terms. As humans we learn to do it automatically and with a great deal of flexibility. But computers must rely solely on fact. The process of acknowledging a packet of data must be absolute, otherwise the data must be re-sent. The same holds true with determining who's turn it is to talk. The pins on a serial port accomplish that.
Here is another link. Scroll down the page and it touches on hung communications. You may need to check with Jeff on specifics of how complete the hardwired serial port is. That will determine what tricks you must use to make both pieces of equipment happy.
Serial Interface Properties
Ok, after reading over that site I decided to try to jump pin 7 and 8 (rts/cts on the palm). I decided this because the palm only has a DSR but no DTR or DCD so jumping them together would have done nothing.
I also decided this since no data logger cable schematic I found had jumped connections and the setup worked before with only 4 wires coming out of the ecu box.
Here is the strange part. I still get an ecu comm error for baud rates of 1920, 1953 and 8192bps. However, I now get a serial comm error when 9600bps is selected.
I also decided this since no data logger cable schematic I found had jumped connections and the setup worked before with only 4 wires coming out of the ecu box.
Here is the strange part. I still get an ecu comm error for baud rates of 1920, 1953 and 8192bps. However, I now get a serial comm error when 9600bps is selected.
s_firestone
Well-known member
1920 is likely the one you want, I don;t think the ECU can run at higher baud rates like 9600.
It is unfortunate but there are about a dozen ways to wire a serial port depending on the device.
If this is the case then the lines must be tied to their complementary pin.
ECU Gnd ---> Palm Serial Gnd (common ground)
ECU Diag (tied to Ground to put the ECU in DIAG mode) This is technically the ON switch for logging.
ECU Tx Palm Tx
Essentially you have 3 wires, Jeff states that the ECU DIAG is already tied to ground inside the ECU connector.
Try it in its simplest form first. If it works then no futher modification is necessary.
If you tie RTS/CTS strictly on the palm side you may want to also tie in DSR line. Try wiring it like above first and only wire in the extra if it does not respond.
Which interface does the Ique use for its serial port, do you have a true pinout? We still have not ruled out this being a Palm OS 5 problem.
One thing you might try. I'm assuming even with the installed serial port on the ECU, that the DIAG port still works. If so you should be able to test using a true datalogger cable. A proper datalogger cable uses a full RS-232 tranciever chip and it provides the necessary signaling. It interprets and converts the proper RS-232 into the single pin +5V TTL ALDL protocol used by the ECU diag port.
It is unfortunate but there are about a dozen ways to wire a serial port depending on the device.
If this is the case then the lines must be tied to their complementary pin.
ECU Gnd ---> Palm Serial Gnd (common ground)
ECU Diag (tied to Ground to put the ECU in DIAG mode) This is technically the ON switch for logging.
ECU Tx Palm Tx
Essentially you have 3 wires, Jeff states that the ECU DIAG is already tied to ground inside the ECU connector.
Try it in its simplest form first. If it works then no futher modification is necessary.
If you tie RTS/CTS strictly on the palm side you may want to also tie in DSR line. Try wiring it like above first and only wire in the extra if it does not respond.
Which interface does the Ique use for its serial port, do you have a true pinout? We still have not ruled out this being a Palm OS 5 problem.
One thing you might try. I'm assuming even with the installed serial port on the ECU, that the DIAG port still works. If so you should be able to test using a true datalogger cable. A proper datalogger cable uses a full RS-232 tranciever chip and it provides the necessary signaling. It interprets and converts the proper RS-232 into the single pin +5V TTL ALDL protocol used by the ECU diag port.
Stephen,
The on board stuff Jeff added is an rs232 driver. It has the IC as well as the rest of the components to make it a true permanent data logger cable. Everything is contained on a riser board Jeff soldered in to the ECU main board. 4 wires come out from that circuit. Jeff decided to use a telephone cord for these wires. Red is the ECU DIAG. Black is ground. Yellow and Green are txd and rxd. Because Jeff used a Telephone cord for the wires, an rj11 to db9 adapter is used. Unfortunately, the one Jeff sent me has been misplaced. The other thread illustrates what I did to replace that adapter. IT is in the adapter that the ECU DIAG gets tied to ground. So once the adapter is connected to the phone cord, it is exactly like plugging in a true data logger cable.
This leaves the question on the palm side of things. I have checked the palm serial cable I have to the diagram I linked to previously with a multimeter. The diagram is accurate.
I first tried to wire nothing special. I just had the adapter with txd, rxd and ground plugged into the store bought serial cradle cable. This cable came with a 7.5k resistor for the device select. I got the "ecu comm error" with this. So I then swapped the 7.5k to a 100k in order to make it a "serial device". This didn't change anything. Then I tied the cts and rts together as described in the link you posted. That resulted in what I described above.
It looks like the only hardware thing I have left to try is to tie the dsr in with the cts/rts. This is not on the link you gave. In fact that link describes them as being to separate things. Will I hurt anything by trying this?
It would be nice it try a known good palm, like a palmIII. But I don't know of anyone around here with one.
The on board stuff Jeff added is an rs232 driver. It has the IC as well as the rest of the components to make it a true permanent data logger cable. Everything is contained on a riser board Jeff soldered in to the ECU main board. 4 wires come out from that circuit. Jeff decided to use a telephone cord for these wires. Red is the ECU DIAG. Black is ground. Yellow and Green are txd and rxd. Because Jeff used a Telephone cord for the wires, an rj11 to db9 adapter is used. Unfortunately, the one Jeff sent me has been misplaced. The other thread illustrates what I did to replace that adapter. IT is in the adapter that the ECU DIAG gets tied to ground. So once the adapter is connected to the phone cord, it is exactly like plugging in a true data logger cable.
This leaves the question on the palm side of things. I have checked the palm serial cable I have to the diagram I linked to previously with a multimeter. The diagram is accurate.
I first tried to wire nothing special. I just had the adapter with txd, rxd and ground plugged into the store bought serial cradle cable. This cable came with a 7.5k resistor for the device select. I got the "ecu comm error" with this. So I then swapped the 7.5k to a 100k in order to make it a "serial device". This didn't change anything. Then I tied the cts and rts together as described in the link you posted. That resulted in what I described above.
It looks like the only hardware thing I have left to try is to tie the dsr in with the cts/rts. This is not on the link you gave. In fact that link describes them as being to separate things. Will I hurt anything by trying this?
It would be nice it try a known good palm, like a palmIII. But I don't know of anyone around here with one.
s_firestone
Well-known member
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. /ubbthreads/images/graemlins/grin.gif
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 box
Another 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.
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 box
Another 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.
Long posts are perfectly fine. Let me answer some of your questions quickly. I know you want more detailed answers and I will work on them tomorrow.
Quote:
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.
2) The pinout for the Garmin is the same as the one I linked to previously as "palm links"
3) 1.5d
4) Palm OS 5.2.1
6) max202--- (the last bit has been scratched)
I tried the "serialfix" thinking it would be the answer, but it isn't compatible. I get an"unsupported CPU type" error. It looks like the program is made for higher end CPUs. The garmin runs on a 200MHz dragonball mxl arm9.
I will try to get more info tomorrow.
Quote:
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.
2) The pinout for the Garmin is the same as the one I linked to previously as "palm links"
3) 1.5d
4) Palm OS 5.2.1
6) max202--- (the last bit has been scratched)
I tried the "serialfix" thinking it would be the answer, but it isn't compatible. I get an"unsupported CPU type" error. It looks like the program is made for higher end CPUs. The garmin runs on a 200MHz dragonball mxl arm9.
I will try to get more info tomorrow.
s_firestone
Well-known member
Definitely get the newer version of MMCd. 1.8g and 1.8n are the latest versions.
Let me look up the MAX 202 and see if it differs from the typical MAX232 chip.
Let me look up the MAX 202 and see if it differs from the typical MAX232 chip.
