GalantVR4.org The Mitsubishi Galant VR-4 Forum
Galant VR-4 Forums » Galant VR-4 » General VR4 Discussions » Re: data logger plus gps
Previous thread Next thread

Re: data logger plus gps


s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 350132 posted 06/15/06 07:47 PM     Remind Me!  Send Private Message   Edit Post      
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



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350224 posted 06/16/06 01:21 AM     Remind Me!  Send Private Message   Edit Post      
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.

| | | IP: (69.229.45.213) | Report this post to a Moderator

Hertz Galant VR4.org Administrator
OneTitle to rule them all.
77/2000


Galant VR-4 org Post #: 350256 posted 06/16/06 07:39 AM     Remind Me!  Send Private Message   Edit Post      
Sounds like you're making it easier on me. Keep up the good work.



Ryan Hertz

Posts: 13500 | From: Chicago, IL | Member Since: 07/29/02 | IP: (208.57.52.65) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350364 posted 06/16/06 01:33 PM     Remind Me!  Send Private Message   Edit Post      

Swapping pins 2 and 3 gives me a "serial comm error".

| | | IP: (70.133.194.124) | Report this post to a Moderator

Hertz Galant VR4.org Administrator
OneTitle to rule them all.
77/2000


Galant VR-4 org Post #: 350368 posted 06/16/06 01:42 PM     Remind Me!  Send Private Message   Edit Post      
Do you have access to a regular Palm for testing?



Ryan Hertz

Posts: 13500 | From: Chicago, IL | Member Since: 07/29/02 | IP: (208.57.52.65) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350369 posted 06/16/06 01:45 PM     Remind Me!  Send Private Message   Edit Post      
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.




| | | IP: (70.133.194.124) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350423 posted 06/16/06 04:16 PM     Remind Me!  Send Private Message   Edit Post      
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.

| | | IP: (70.133.194.124) | Report this post to a Moderator

Hertz Galant VR4.org Administrator
OneTitle to rule them all.
77/2000


Galant VR-4 org Post #: 350431 posted 06/16/06 04:44 PM     Remind Me!  Send Private Message   Edit Post      
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.



Ryan Hertz

Posts: 13500 | From: Chicago, IL | Member Since: 07/29/02 | IP: (208.57.52.65) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 350436 posted 06/16/06 04:53 PM     Remind Me!  Send Private Message   Edit Post      
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



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350535 posted 06/16/06 11:11 PM     Remind Me!  Send Private Message   Edit Post      
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.

| | | IP: (70.133.194.124) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 350618 posted 06/17/06 10:58 AM     Remind Me!  Send Private Message   Edit Post      
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 Rx
ECU Rx ---> 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 Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 350668 posted 06/17/06 02:30 PM     Remind Me!  Send Private Message   Edit Post      
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.

| | | IP: (69.106.185.127) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 350877 posted 06/18/06 12:20 PM     Remind Me!  Send Private Message   Edit Post      
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 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.



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351069 posted 06/19/06 03:20 AM     Remind Me!  Send Private Message   Edit Post      
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.

| | | IP: (71.128.252.219) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 351152 posted 06/19/06 11:24 AM     Remind Me!  Send Private Message   Edit Post      
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.



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (169.135.104.125) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351179 posted 06/19/06 02:18 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

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.




Some how I missed this post. Sorry Ryan.
I tried to hotsync via serial today. It didn't work. I never tried this with the 7.5k resistor so I don't know what the problem is. It could be he 100k resistor, the cable, the garmin, the pc, or something I am not thinking of.

| | | IP: (69.238.21.209) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351181 posted 06/19/06 02:23 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

Definitely get the newer version of MMCd. 1.8g and 1.8n are the latest versions.




Is there another spot to get these? I am not a member of 3si.org so they won't let me download.

| | | IP: (69.238.21.209) | Report this post to a Moderator

Hertz Galant VR4.org Administrator
OneTitle to rule them all.
77/2000


Galant VR-4 org Post #: 351184 posted 06/19/06 02:39 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

Quote:

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.




Some how I missed this post. Sorry Ryan.
I tried to hotsync via serial today. It didn't work. I never tried this with the 7.5k resistor so I don't know what the problem is. It could be he 100k resistor, the cable, the garmin, the pc, or something I am not thinking of.




Well, at least you know it isn't the ECU.



Ryan Hertz

Posts: 13500 | From: Chicago, IL | Member Since: 07/29/02 | IP: (208.57.52.65) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 351246 posted 06/19/06 07:40 PM     Remind Me!  Send Private Message   Edit Post      
It's not going to sync with a PC without rewiring. Not unless you switch the send/recieve lines. PC is DTE, datalogger is DCE. You can switch the connections and test though.



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 351250 posted 06/19/06 07:48 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

Quote:

Definitely get the newer version of MMCd. 1.8g and 1.8n are the latest versions.




Is there another spot to get these? I am not a member of 3si.org so they won't let me download.




There is a link embedded for 1.8g on DMChips.com

MMCd 1.8g



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351294 posted 06/19/06 09:18 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

It's not going to sync with a PC without rewiring. Not unless you switch the send/recieve lines. PC is DTE, datalogger is DCE. You can switch the connections and test though.




I thought long and hard about this. The cable was bought as a pc hotsync serial cable. So I thought it should work. But I modified the cable from the 7.5k resistor which is for a pc connection to the 100k resistor which is for a serial device connection. Will this flip flop the tx/rx like I think it will?

| | | IP: (69.238.21.209) | Report this post to a Moderator

s_firestone
Ctrl-Alt-Boost
918/1000


Galant VR-4 org Post #: 351362 posted 06/20/06 06:27 AM     Remind Me!  Send Private Message   Edit Post      
It's unlikely it would switch the tx/rx for you but it definitely might change the comm mode. The cable would likely be wired DCE(Garmin) to DTE(PC). If the cable was already a hotsync serial cable using a DB9 connector then that might work. The comm mode using the 100K resistor may be for Garmin's GPS mode.



Stephen Firestone
1992 GVR4 #918 of 1K

Posts: 1610 | From: Park City, UT USA | Member Since: 06/27/02 | IP: (24.170.24.226) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351460 posted 06/20/06 12:31 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

Quote:

Quote:

Definitely get the newer version of MMCd. 1.8g and 1.8n are the latest versions.




Is there another spot to get these? I am not a member of 3si.org so they won't let me download.




There is a link embedded for 1.8g on DMChips.com

MMCd 1.8g




Awesome! I tried this and I made a little progress, maybe. At baud rates just higher than 1953bps like 2193bps I was able to read codes, I think. I ran my battery down so I didn't force an error to be sure (my motor is shot so I'm not sure what I would do), but I was able to read "none" while doing a test. However, I tried to log and as soon as I unpaused the palm froze and needed to be reset with the button on the back. Is this an improvement?

| | | IP: (71.134.186.121) | Report this post to a Moderator

Paul Mc369
Unregistered


Galant VR-4 org Post #: 351462 posted 06/20/06 12:35 PM     Remind Me!  Send Private Message   Edit Post      
Quote:

1: A proper schematic of your circuit and circuits you have eliminated as not working.
5: Document your settings you have tried and the resulting error code.




I am still working on the schematics. Well, I should say, I am still thinking about how I would do them. I don't have autocad or viseo so whatever I do will be in mspaint .

| | | IP: (71.134.186.121) | Report this post to a Moderator

Hertz Galant VR4.org Administrator
OneTitle to rule them all.
77/2000


Galant VR-4 org Post #: 351464 posted 06/20/06 12:35 PM     Remind Me!  Send Private Message   Edit Post   


The freeze could be an infinite loop of some kind.



Ryan Hertz

Posts: 13500 | From: Chicago, IL | Member Since: 07/29/02 | IP: (208.57.52.65) | Report this post to a Moderator


Pages: 1 | 2 | 3 | 4
Previous thread Next thread

Extra information
0 registered and 8 anonymous users are browsing this forum.

Galant VR4.org Moderator:  curtis, steve, atc250r, jcgalntvr4-244, cheekychimp, jepherz, Rausch, toybreaker, iceman69510, pot, FlyingEagle 

Print Thread

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Thread views: 5058

Rate this thread


News & Events: News | Events
Galant VR-4: Newbies | General VR4 Discussions | Technical Discussions | How To and Info Archive
Marketplace: Parts For Sale | Cars For Sale | Good Guys | Bad Guys
Community: Members' Showcase

Contact Us | Privacy statement GalantVR-4.org

Generated in 0.36 seconds in which 0.061 seconds were spent on a total of 14 queries. Turbo powered.


Hertz's Galant VR-4 Page