An idea for cars with no ICS switch
Dec 26, 2007, 01:28 AM
#1
Evolving Member
Thread Starter
Join Date: May 2007
Location: Italy
Posts: 178
Likes: 0
Received 0 Likes
on
0 Posts
An idea for cars with no ICS switch
I was looking for tephra's map switch via ICS button, but unfortunately not all our cars have ICS. For example I run 88840016 (EDM IX GSR) and I don't have ICS nor MAP cable... 
Working on some projects I thought that a solution for this problem can be found: MUT request switching.
We know that we have free MUT IDs that we use for example for 2-byte load and RPM, MIVEC read, etc. So we could use some IDs to call a subroutine for map switching, with return byte filled with map ID (I mean: we have 2 set of maps; switch request by calling MUTXX; ECU does switch and return with 0 or 1 to inform on which map set we are using).
This can be done simply via a single PC request, but it would be unconfortable.
So the second part of the idea
: a very low cost electronic device to communicate via MUT requests (or, maybe, a more complex protocol like hi-speed DMA transfer by jcsbanks).
I have a good knowledge of electronic design and such a device would be quite a joke. I mean a cheap microcontroller (4-5$), a ISO9141 transceiver (1.50$), some components (oscillator, switches, leds, etc for no more than 5-6$) and a PCB (depending on quantity from 5 to 15$).
Firmware would be quite easy to write, no more than a simple MUT communication.
Here is my problem: I really don't know MUT protocol... I could read libmut code but apart from comm speed (15625), format (like 8n1) and request/reply there are some basic "functional" questions: with Evoscan I see that MUT does require a slow init (tipical 5 baud) that means about 2 seconds to start communication and a little time to switch map. So, here are my doubts:
Does MUT really needs a slow init?
Which address is sent in 5 baud mode? Classical 0x33?
Does the ECU replies with a key, and does it wants a reply?
Moreover, such a device could remain connected after slow init to get a very fast switch, but does this make sense? Or can we wait 2-3 seconds for map switching?
Here is my first idea for the ICS switch problem, maybe too much christmas food
... any comment and suggestions are welcome.
Working on some projects I thought that a solution for this problem can be found: MUT request switching.
We know that we have free MUT IDs that we use for example for 2-byte load and RPM, MIVEC read, etc. So we could use some IDs to call a subroutine for map switching, with return byte filled with map ID (I mean: we have 2 set of maps; switch request by calling MUTXX; ECU does switch and return with 0 or 1 to inform on which map set we are using).
This can be done simply via a single PC request, but it would be unconfortable.
So the second part of the idea
: a very low cost electronic device to communicate via MUT requests (or, maybe, a more complex protocol like hi-speed DMA transfer by jcsbanks).I have a good knowledge of electronic design and such a device would be quite a joke. I mean a cheap microcontroller (4-5$), a ISO9141 transceiver (1.50$), some components (oscillator, switches, leds, etc for no more than 5-6$) and a PCB (depending on quantity from 5 to 15$).
Firmware would be quite easy to write, no more than a simple MUT communication.
Here is my problem: I really don't know MUT protocol... I could read libmut code but apart from comm speed (15625), format (like 8n1) and request/reply there are some basic "functional" questions: with Evoscan I see that MUT does require a slow init (tipical 5 baud) that means about 2 seconds to start communication and a little time to switch map. So, here are my doubts:
Does MUT really needs a slow init?
Which address is sent in 5 baud mode? Classical 0x33?
Does the ECU replies with a key, and does it wants a reply?
Moreover, such a device could remain connected after slow init to get a very fast switch, but does this make sense? Or can we wait 2-3 seconds for map switching?
Here is my first idea for the ICS switch problem, maybe too much christmas food
... any comment and suggestions are welcome.
Dec 26, 2007, 02:16 AM
#2
Already done - JoeBee did it using libmut and C, then I did it using BASCOM-AVR. We both used Atmel AVR 8 bit RISC microcontrollers.
However, once I dug out my old Pocket PC and found that an old GPS cradle brought out RS232 lines I moved to that, and I already Map switch using it. The patch I've done for US Evo 9 would do the same.
Yes MUT does seem to need a slow Init, no one has got it running any other way.
I have simplified the process - just setup baud rate at 8N1, send a break for 1800ms, wait for 400ms, then read 6 bytes and throw them away. Then you can start logging. The requests are echoed because of the Rx and Tx lines being tied together in OBD. So you have byte request, byte echo, then after the ECU thinks about it, a byte reply. That is all there is to it.
However, once I dug out my old Pocket PC and found that an old GPS cradle brought out RS232 lines I moved to that, and I already Map switch using it. The patch I've done for US Evo 9 would do the same.
Yes MUT does seem to need a slow Init, no one has got it running any other way.
I have simplified the process - just setup baud rate at 8N1, send a break for 1800ms, wait for 400ms, then read 6 bytes and throw them away. Then you can start logging. The requests are echoed because of the Rx and Tx lines being tied together in OBD. So you have byte request, byte echo, then after the ECU thinks about it, a byte reply. That is all there is to it.
Dec 26, 2007, 10:47 PM
#3
Evolving Member
Thread Starter
Join Date: May 2007
Location: Italy
Posts: 178
Likes: 0
Received 0 Likes
on
0 Posts
Already done - JoeBee did it using libmut and C, then I did it using BASCOM-AVR. We both used Atmel AVR 8 bit RISC microcontrollers.
However, once I dug out my old Pocket PC and found that an old GPS cradle brought out RS232 lines I moved to that, and I already Map switch using it. The patch I've done for US Evo 9 would do the same.
Yes MUT does seem to need a slow Init, no one has got it running any other way.
I have simplified the process - just setup baud rate at 8N1, send a break for 1800ms, wait for 400ms, then read 6 bytes and throw them away. Then you can start logging. The requests are echoed because of the Rx and Tx lines being tied together in OBD. So you have byte request, byte echo, then after the ECU thinks about it, a byte reply. That is all there is to it.
However, once I dug out my old Pocket PC and found that an old GPS cradle brought out RS232 lines I moved to that, and I already Map switch using it. The patch I've done for US Evo 9 would do the same.
Yes MUT does seem to need a slow Init, no one has got it running any other way.
I have simplified the process - just setup baud rate at 8N1, send a break for 1800ms, wait for 400ms, then read 6 bytes and throw them away. Then you can start logging. The requests are echoed because of the Rx and Tx lines being tied together in OBD. So you have byte request, byte echo, then after the ECU thinks about it, a byte reply. That is all there is to it.
For slow init it's not a problem, I use it in other projects.
Thread
Thread Starter
Forum
Replies
Last Post
