I got the cable not the cradle. I forgot to change the label on that drawing. It is a garmin cable. The only change I made was the resistor.
- 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.
All fixed. I was tired when I drew that up. I stole the cradle drawing from palm and modified it to match what I have. Unfortunately, I missed the hotsync label and the word cradle. It looks right now.
I have been looking into this a little more and have found nothing. I thought I read about a similar situation on the 3si thread but can't find it. I am running short on funds at the moment, so I haven't purchased any of the break out boxes or what not.
I really wish that serialfix was compatible with this ique. Any other ideas?
I really wish that serialfix was compatible with this ique. Any other ideas?
s_firestone
Well-known member
The schematic looks to be sound. The fact that your getting codes is a good thing. You might try changing the options in MMCd to lower the logging rate. This makes me think that this is a buffer overflow issue.
Unfortunately this is at least partially symptomatic of the "virtual" serial port AKA USB derived serial port issue as seen with a lot of newer Palms. The common symptom is communications appearing to work but the logger hanging almost immediately. The problem is that the RS-232 implementation is not true. It's emulated from within the USB port. I know this has plagued the community because of the lack of a proper driver for USB. Since the Palms are not Master (USB equivalent to DTE) they lack some of the functions or their big brothers on the PC USB driver interface.
The only other pin that could be causing this is the DTR. If DTR is floating it may just fill the send/recieve buffers and then appear to hang up because it thinks the MAX202 is not ready. Think of it as a queue to hold the send/recieve data without losing it. Try tying it to RTS/CTS or Ground temporarily to see if that fixes the problem.
You may try putting in a call to Garmin. One of their engineers might be able to shed some insight or even provide a beta serial driver. I would keep digging in the Garmin specific forums and the sites that make garmin compatible apps and equipment. You might also go bak through some of the links we have compiled in this thread. There may be something on one of the custom application pages we missed. Just like that serial fix, there may be more than one version of it compiled for your Palm's processor.
I'm going to look into the RS-232 drivers from the Palm's perspective. It's possible we may be able to graft one onto the Garmin from another Palm.
You might also look into your Garmin's menus and check for settings/compatibility options. If the Garmin has a terminal program we might be able to do some tests that way.
While your researching I may try some tests. I may have a newer Palm tungsten to experiment on. It could be a simple modication thats been overlooked to make the Garmin and all other USB derived serial interfaced Palms happy.
Unfortunately this is at least partially symptomatic of the "virtual" serial port AKA USB derived serial port issue as seen with a lot of newer Palms. The common symptom is communications appearing to work but the logger hanging almost immediately. The problem is that the RS-232 implementation is not true. It's emulated from within the USB port. I know this has plagued the community because of the lack of a proper driver for USB. Since the Palms are not Master (USB equivalent to DTE) they lack some of the functions or their big brothers on the PC USB driver interface.
The only other pin that could be causing this is the DTR. If DTR is floating it may just fill the send/recieve buffers and then appear to hang up because it thinks the MAX202 is not ready. Think of it as a queue to hold the send/recieve data without losing it. Try tying it to RTS/CTS or Ground temporarily to see if that fixes the problem.
You may try putting in a call to Garmin. One of their engineers might be able to shed some insight or even provide a beta serial driver. I would keep digging in the Garmin specific forums and the sites that make garmin compatible apps and equipment. You might also go bak through some of the links we have compiled in this thread. There may be something on one of the custom application pages we missed. Just like that serial fix, there may be more than one version of it compiled for your Palm's processor.
I'm going to look into the RS-232 drivers from the Palm's perspective. It's possible we may be able to graft one onto the Garmin from another Palm.
You might also look into your Garmin's menus and check for settings/compatibility options. If the Garmin has a terminal program we might be able to do some tests that way.
While your researching I may try some tests. I may have a newer Palm tungsten to experiment on. It could be a simple modication thats been overlooked to make the Garmin and all other USB derived serial interfaced Palms happy.
I just tried this:
palm file
Which does this:
Quote:
there is a problem with the serial port on version 5. Older Palm OS apps expect the serial library to be preloaded after boot up. In Palm OS 5 and the Tungsten T this lib is not loaded after boot up. This free program will help you running older palm apps that use the serial port.
Unfortunately, odd baud rates were not available on the program and it did not change any results.
palm file
Which does this:
Quote:
there is a problem with the serial port on version 5. Older Palm OS apps expect the serial library to be preloaded after boot up. In Palm OS 5 and the Tungsten T this lib is not loaded after boot up. This free program will help you running older palm apps that use the serial port.
Unfortunately, odd baud rates were not available on the program and it did not change any results.
Crap Crap Crap Crap Crap
garmin FAQ
Quote:
Q. Can I perform real-time tracking with my iQue and a laptop computer?
A. The Garmin iQue does not have the capability of performing real-time tracking. The iQue does not output data that the computer can use to determine its position for tracking purposes. The HotSync process is the only communications channel and does not have the ability to stay on continuously to transmit/receive data.
Q. Is it possible for the iQue 3600 to access the Internet?
A. There are several methods of accessing the Internet while using the iQue. First, use a serial modem cradle to connect through your desktop or laptop computer's Internet connection. Second, use a serial modem cradle that plugs into a standard phone line to connect to a remote ISP or dial-in (remote access) server. This second process is especially beneficial if you are away from your computer. Both processes are detailed in the iQue manual that is on the setup disk. Currently, the iQue 3600 does not support SDIO peripherals.
garmin FAQ
Quote:
Q. Can I perform real-time tracking with my iQue and a laptop computer?
A. The Garmin iQue does not have the capability of performing real-time tracking. The iQue does not output data that the computer can use to determine its position for tracking purposes. The HotSync process is the only communications channel and does not have the ability to stay on continuously to transmit/receive data.
Q. Is it possible for the iQue 3600 to access the Internet?
A. There are several methods of accessing the Internet while using the iQue. First, use a serial modem cradle to connect through your desktop or laptop computer's Internet connection. Second, use a serial modem cradle that plugs into a standard phone line to connect to a remote ISP or dial-in (remote access) server. This second process is especially beneficial if you are away from your computer. Both processes are detailed in the iQue manual that is on the setup disk. Currently, the iQue 3600 does not support SDIO peripherals.
Hertz
Staff member
What is SDIO?
If it works with a serial modem then it will work to log with -- it's the same thing, isn't it?
If it works with a serial modem then it will work to log with -- it's the same thing, isn't it?
3600 manual
I am not sure what SDIO stands for, but I am guessing it is Serial Data Input Output. Reading chapter ten of the above manual leads me to believe the modem is for tcp/ip communication with telephone handshakes and what not.
I am not sure what SDIO stands for, but I am guessing it is Serial Data Input Output. Reading chapter ten of the above manual leads me to believe the modem is for tcp/ip communication with telephone handshakes and what not.
Hertz
Staff member
It still talks to the modem via RS232.
Have you tried those different connection settings?
Have you tried those different connection settings?
s_firestone
Well-known member
I found some more data regarding the known bug in the Palm OS5 devices. This was referencing a T3 but the principle is the same.
Discussion of Palm OS5 serial flow control and buffer implementation
What this discussion alludes to is that the Palm is mis-handling the flow control. It is a known bug and has never been patched in the OS. Essentially the serialfix patches it in some cases. In your case it would not work with your Garmin specific hardware.
What is happening with your Garmin is that the ECU is sending data as soon as its put into 'diag' mode. The Palm serial connection has a data buffer of a finite size. As long as number of received packets is smaller than the buffer can hold, you are able to communicate. However once you begin asking the ECU for the data from multiple registers which contain the logging data, it over-runs the buffer. As soon as the buffer gets full the CTS line drops indicating that no more packets can be sent.
There are two types of flow control. Hardware flow control utilizing actual signal lines RTS/CTS and Software flow control which bundles the flow control onto the TX/RX line. There is also an option of no flow control AKA dumb mode or blind transmission.
There are a couple of scenarios here.
One, the Garmin is not correctly interpreting the RTS/CTS (or ignoring them). We did attempt to tie them so the CTS line would be asserted. Now that you have rudimentary communications, re-check that those lines are tied, as it may be that simple.
Two, the MMCd software is coded for one type of flow control or another but is not written to support both (could be rectified by minor addition to the way the software handles the data with an option to toggle).
Three, we need a circuit to cheat a little and coax the port into being happy. A simple acknowledgment from the MAX202 may do the trick. It may be that the Garmin is doing exactly what its supposed to. But that it expects proper signaling. This may be hard-coded in firmware or in the serial driver(and differ in its behavior from Palm OS4 and earlier). The MAX202 does have these signals available. We may need to extend the control signals over so that the burden for flow control falls on the MAX202 rather than none, or a faked RTS/CTS.
Four, After reading that some people had problems with Garmin devices hot-sync'ing with the backlight on, we could be dealing with a similar problem. The Garmin may be sensitive to power drain from its power supply and that may affect the sensitivity to current loop based communications.
Five, as mentioned before we may be dealing with a virtual serial port that is being emulated strictly as a subset of the Garmin USB port. The serial port may not technically exist which causes all applications written to use a serial library grief.
I'm still researching. As I mentioned before, I am trying to get a non-standard newer palm and look at the original MMCd source to see if we can fake it. I'm also looking at seeing if routing the data via the infrared port or a bluetooth connection would work. There is limited serial support via both. The flow control is still an issue as both alternate types of ports were never intended to have full compliance with RS-232c. If we could get one working USB port of the MMCd code we could do this. Bluetooth may fair better than USB than accomplishing this.
Discussion of Palm OS5 serial flow control and buffer implementation
What this discussion alludes to is that the Palm is mis-handling the flow control. It is a known bug and has never been patched in the OS. Essentially the serialfix patches it in some cases. In your case it would not work with your Garmin specific hardware.
What is happening with your Garmin is that the ECU is sending data as soon as its put into 'diag' mode. The Palm serial connection has a data buffer of a finite size. As long as number of received packets is smaller than the buffer can hold, you are able to communicate. However once you begin asking the ECU for the data from multiple registers which contain the logging data, it over-runs the buffer. As soon as the buffer gets full the CTS line drops indicating that no more packets can be sent.
There are two types of flow control. Hardware flow control utilizing actual signal lines RTS/CTS and Software flow control which bundles the flow control onto the TX/RX line. There is also an option of no flow control AKA dumb mode or blind transmission.
There are a couple of scenarios here.
One, the Garmin is not correctly interpreting the RTS/CTS (or ignoring them). We did attempt to tie them so the CTS line would be asserted. Now that you have rudimentary communications, re-check that those lines are tied, as it may be that simple.
Two, the MMCd software is coded for one type of flow control or another but is not written to support both (could be rectified by minor addition to the way the software handles the data with an option to toggle).
Three, we need a circuit to cheat a little and coax the port into being happy. A simple acknowledgment from the MAX202 may do the trick. It may be that the Garmin is doing exactly what its supposed to. But that it expects proper signaling. This may be hard-coded in firmware or in the serial driver(and differ in its behavior from Palm OS4 and earlier). The MAX202 does have these signals available. We may need to extend the control signals over so that the burden for flow control falls on the MAX202 rather than none, or a faked RTS/CTS.
Four, After reading that some people had problems with Garmin devices hot-sync'ing with the backlight on, we could be dealing with a similar problem. The Garmin may be sensitive to power drain from its power supply and that may affect the sensitivity to current loop based communications.
Five, as mentioned before we may be dealing with a virtual serial port that is being emulated strictly as a subset of the Garmin USB port. The serial port may not technically exist which causes all applications written to use a serial library grief.
I'm still researching. As I mentioned before, I am trying to get a non-standard newer palm and look at the original MMCd source to see if we can fake it. I'm also looking at seeing if routing the data via the infrared port or a bluetooth connection would work. There is limited serial support via both. The flow control is still an issue as both alternate types of ports were never intended to have full compliance with RS-232c. If we could get one working USB port of the MMCd code we could do this. Bluetooth may fair better than USB than accomplishing this.
You mean routing logger data from the ECU via infrared or bluetooth? Bluetooth logging would be pretty trick. Keep up the good research, sounds like you've made some progress, just need to get over this wall. Doesn't the MMcD team have a setup to use newer Palm's and a higher speed data transfer with a mod to the ECU? It's been awhile since I've been over to the 3si site.
-Josh
-Josh
DarkDevilMMM
Well-known member
using bluetooth is pretty simple, especially conversion between serial dataline to bluetooth dataline. the part you need to look into is at the software side, i.e. MMCd. program MMCd to grab data from bluetooth port instead of serial port. I tried to do this before, but I have other more important projects to do /ubbthreads/images/graemlins/smile.gif
the easiest way to do is, get 2 hardware serial to bluetooth converter, one plug into the car, the other plug into the palm, and there u go, bluetooth u have.
the easiest way to do is, get 2 hardware serial to bluetooth converter, one plug into the car, the other plug into the palm, and there u go, bluetooth u have.
s_firestone
Well-known member
If done properly, the program can be made to be transparent. Able to use any transport. All the datalogging software was written on a particular platform that Palm laid out. Unfortunately Palm changed both the hardware and software without maintaining backwards compatibility. They are not the only company to orphan a huge group of existing customers and supporters.
Every week a new Palm/PDA/Phone gets released. Every company is in it for themselves. Very few companies attempt to create a proper framework for artichitectural transparency.
Most will not divulge their supposed "trade secrets", a euphimism for: "We stood on the backs of those who came before us to get where we are, but we claim this land in the name of France anyway... And Thanks for giving us the ride over, now go away".
There is currently no totally compatible universal interface that provides for the complete feature set that RS-232 provided. Most are implemented about 25%. We don't truly need 100% implementation anyway, just a working consistent 50% that won't be altered or nuetered in the future.
I've read about 50 pages (40 to go) on 3SI.org the 'HSLogger' looks to be a transparent interface to the ECU with some expandability. Be nice to see it when done. $100 is not bad if it ends up being the trouble-free solution that its touted to be.
The majority of Serial problems on newer Palms/Sony's and likely the Garmin are probably related to BAUD rate(Some Palms cannot use non-standard baud), incorrect flow control, or inadequate power(or requiring phantom power). The passive cables are likely not going to cut it for most of the newer Palms.
Still reading... /ubbthreads/images/graemlins/uhh.gif
Every week a new Palm/PDA/Phone gets released. Every company is in it for themselves. Very few companies attempt to create a proper framework for artichitectural transparency.
Most will not divulge their supposed "trade secrets", a euphimism for: "We stood on the backs of those who came before us to get where we are, but we claim this land in the name of France anyway... And Thanks for giving us the ride over, now go away".
There is currently no totally compatible universal interface that provides for the complete feature set that RS-232 provided. Most are implemented about 25%. We don't truly need 100% implementation anyway, just a working consistent 50% that won't be altered or nuetered in the future.
I've read about 50 pages (40 to go) on 3SI.org the 'HSLogger' looks to be a transparent interface to the ECU with some expandability. Be nice to see it when done. $100 is not bad if it ends up being the trouble-free solution that its touted to be.
The majority of Serial problems on newer Palms/Sony's and likely the Garmin are probably related to BAUD rate(Some Palms cannot use non-standard baud), incorrect flow control, or inadequate power(or requiring phantom power). The passive cables are likely not going to cut it for most of the newer Palms.
Still reading... /ubbthreads/images/graemlins/uhh.gif
s_firestone
Well-known member
Don't pay any attention to that, we are not dead yet. They are correct in that hotsync is a short, finite process. They are misleading you regarding the ability of either of comm channels in being able to transmit data for more than brief periods. What we are doing does not involve 'hotsync'. We are attempting to use the PDA in a manner similar to the connecting to a modem as described.
How big is that manual mention as being on the CD??? Any chance you could post it?
I found several posts on 3SI.org describing the exact symptoms you are experiencing. Some success has been made in getting them to work. Is your ECU overclocked?
Serial Modem Cradle
Quote:
Crap Crap Crap Crap Crap
garmin FAQ
Quote:
Q. Can I perform real-time tracking with my iQue and a laptop computer?
A. The Garmin iQue does not have the capability of performing real-time tracking. The iQue does not output data that the computer can use to determine its position for tracking purposes. The HotSync process is the only communications channel and does not have the ability to stay on continuously to transmit/receive data.
Q. Is it possible for the iQue 3600 to access the Internet?
A. There are several methods of accessing the Internet while using the iQue. First, use a serial modem cradle to connect through your desktop or laptop computer's Internet connection. Second, use a serial modem cradle that plugs into a standard phone line to connect to a remote ISP or dial-in (remote access) server. This second process is especially beneficial if you are away from your computer. Both processes are detailed in the iQue manual that is on the setup disk. Currently, the iQue 3600 does not support SDIO peripherals.
How big is that manual mention as being on the CD??? Any chance you could post it?
I found several posts on 3SI.org describing the exact symptoms you are experiencing. Some success has been made in getting them to work. Is your ECU overclocked?
Serial Modem Cradle
Quote:
Crap Crap Crap Crap Crap
garmin FAQ
Quote:
Q. Can I perform real-time tracking with my iQue and a laptop computer?
A. The Garmin iQue does not have the capability of performing real-time tracking. The iQue does not output data that the computer can use to determine its position for tracking purposes. The HotSync process is the only communications channel and does not have the ability to stay on continuously to transmit/receive data.
Q. Is it possible for the iQue 3600 to access the Internet?
A. There are several methods of accessing the Internet while using the iQue. First, use a serial modem cradle to connect through your desktop or laptop computer's Internet connection. Second, use a serial modem cradle that plugs into a standard phone line to connect to a remote ISP or dial-in (remote access) server. This second process is especially beneficial if you are away from your computer. Both processes are detailed in the iQue manual that is on the setup disk. Currently, the iQue 3600 does not support SDIO peripherals.
Stephen,
The ecu is stock. The eprom is a keydiver but it is at stock frequencies. The manuals that I have seen are all on the link "garmin FAQ" or for convienience here. The serial cradle you linked to has the exact same pin out as the cable I bought. That one just has a plastic base as opposed to just a connector on mine.
I haven't played with any of this in a couple of days...family stuff.
The ecu is stock. The eprom is a keydiver but it is at stock frequencies. The manuals that I have seen are all on the link "garmin FAQ" or for convienience here. The serial cradle you linked to has the exact same pin out as the cable I bought. That one just has a plastic base as opposed to just a connector on mine.
I haven't played with any of this in a couple of days...family stuff.
I am not making any progress on this. I am starting to think the project is beyond me given my time constraints. I have about a month before I go back to Georgia and leave my car here. In that time I will be doing a motor swap.
Does someone want to take over the project?
Does someone want to take over the project?
s_firestone
Well-known member
I'll be happy to pursue it but I don't have $200+ to fork up on a garmin 3600 so I might be shooting blanks. We could put in a request over on 3Si with the upcoming HSLogger.
