More ROSCO commands

[colinb...@gmail.com]

I learned recently that the diagnostic port command 0xF9 is used to adjust the fuel map by somehow applying an offset. If anyone has more information on this, please let us know.

Also, the command 0xCD seems to be some sort of debug feature, possibly to allow peeking RAM. I believe the command requires some followup command to be sent within a timeout period after 0xCD enables this mode. Again, if anyone has more info on this, please share.

--Colin

[Sebastian]

Sadly have nothing to share - But if you give a Manual how I can listen to a Testbook communication via the 3-pin connector I could send you some examples of a normal Testbook Session commands. There you have advanced Features to Change some Parameters.

But Need Guidance how to listen to the communication.

[Martin Rubenstein]

Sebastian

For someone who can put MEMSLogger onto a Raspberry Pi, I expect this would be child's play for you.    So you have access to a Testbook?      The developer of Android app MEMSDiag, Pawel Wozniczka, told me not long ago about sniffing out the commands "it's not too difficult :) Costs next to nothing (5-10 GBP?), software is available for free at saleae website."       I'm not sure it'd be wise for me to include his email address here, but if you don't have it and don't get answers here, PM me and I'll give it you; Pawel would be just as keen to get to the bottom of all this detective work as the rest of us.

Does Testbook not guide you through the various options, or is it the details of how to sniff out the Testbook commands you want?

[Martin Rubenstein]

Colin.

The fuel map offset 0xF9, did you have any further thoughts?  

 The Blackbox Solutions page https://www.blackbox-solutions.com/shop/help/SM002.html mentions what they call Feedback, which is what we're calling the Short Term Fuel Trim, and their Injector Time, which we call the Long Term Fuel Trim (LTFT), and which increment and decrement with 0x79, 7A, 7B and 7C.     And whilst the Blackbox Solutions page also mentions offsets for idling and ignition, there is nothing about a fuel map offset.   

What might such an offset do that LTFT doesn't already do,or perhaps I should ask{ would not such an offset only have meaning for open-loop conditions eg non-catalyst cars all the time or emission-controlled cars under, for example, rapid acceleration?

[colinb...@gmail.com]

Unfortunately, I don't have any more information about the 0xF9 command or what it might do. My only clue came from a very short code snippet in one of the original assembly source modules. Back in the 1990s, a small sampling of the code was released to a third party to develop a static analysis tool (probably for quality assurance purposes.) There's a comment block at the top of one of the modules:

; name: cwadjmm0.a96
;
; description: ROSCO Diagnostics worker for Adjusting the main map.
;
; active conditions: On reception of a valid command F9h (Adjust main map)
;                    whilst at diagnostics level 80
;
;
; action: Calls a strategy module via the strategy SEP table which will alter
;         the main map offset.

Note that this also suggests the existence of different "diagnostic levels". There's not much code after this -- just some instructions that check for the F9 command and call a routine in a different module that I don't have. I think the term "strategy module" is just some nomenclature used by the ECU engineers to refer to a firmware routine that performs an ECU function.

The source modules that I have are marked with dates and abbreviated versions of the author's name. There's only a single full name in the lot of them, and I've thought about trying to contact this person today on the off chance that he might remember and be able to share ROSCO diagnostic information. I haven't done anything further because I'm not sure if he'd appreciate being tracked down and asked about work he did twenty-five years ago :)

--Colin

[fra...@pinza.demon.co.uk]

On Thursday, April 21, 2016 at 1:13:49 AM UTC+1, colinb...@gmail.com wrote:

I haven't done anything further because I'm not sure if he'd appreciate being tracked down and asked about work he did twenty-five years ago :)

On the other hand: a Honda engineer turned up at the Pride of Longbridge rally a year or so ago, to be in the presence of the gathered R8's (Rover 200/400 wedges). He'd been one of the chassis engineers on that joint Rover/Honda project, which launched back in 1989. Plenty of Rover people are still proud of what they achieved back then.

[Martin Rubenstein]

If Sebastian manages to monitor the output of his Testbook, perhaps many of the missing pieces of this jigsaw will fall into place, though, reading your post, I wondef if this 0xF9 might be something that wasn't intended for inclusion in the standard Rover diagnosric kit.

Something to experiment with on one of my spare ECUs and see how the fuel trims compare on 2 journeys over the same route.

[fra...@pinza.demon.co.uk]

I wonder if Testbook self-configures according to whatever identifier the connected ECU returns, and quietly sends customised commands for each type?

[thierry...@gmail.com]

HEllo,

I'm actually looking to diagnose my mini with MEMS 1.6 ECU ref : MNE101150

Today i have succeed :

 to connect 3 pins connector with GND, TX , RX and usb Serie cable

to send and receive data with a standard serial interface

But when i used : MEMSlogger, MEMS_diag, MemsGuage , every time i have a failure to connect ECU

If i correctly understood , to connect ECU , i need to pass:

CA recieve CA

75 receive 75

D0 receive D099000203

But my ECU MNE 101150 is not like this

When i send:

CA , i recieved some time 02 00 30 00 00 or 79 00 or 28 00 43 00 or 43 00

75 , recieved : 5D 00 or 43 00 or 13 00 43 00 or 4D 00 43 00

D0 , received 7F 00 or 2A 00 00 or 14 00 00

Do you have any idea or do you know if ECU MNE 101150 is compatible with all the software :

- MEMSlogger, MEMS_diag, MemsGuage  or ACR2 diagnositic reader 

Thanks for your help

THierry

[Martin Rubenstein]

Hi Thierry

You don’t need to send any commands. Your failure to connect is quite possibly you are trying to connect to the wrong COM port. I have 2 leads and one has to connect on COM3 and the other on COM5. I have to reset the COM port in each program. Play around changing the COM port; I think that is your problem. Look in the Preferences in each program to find the COM port settings.

[Alan Richey]

I agree. The programs send those initialise codes automatically.    Assuming you are using a PC use Device Manager to find out which virtual COM port your cable has been allocated.

[Thierry Bavois]

Hi Martin

I fact i pretty sure to do Serial communication 

Conclusion Setup computeur comx... are Ok

My question is general , what is the Part number you succeed to connect to MemsRead or MemsGauge softwaire

All mini rover i know are in this list:

MNE10027

MNE101070

MNE101170

MNE10097

MNE101150

MNE101350

MNE101160

All are SPI, Mems 1.6 type 

Myne is MNE101150

What is the part number inside your ECU , you succeed to communicate?

Thanks

BR

Thierry

[Martin Rubenstein]

Thank you, Thierry, and forgive me for not understanding the question.

I am away from the car for a few weeks but I do know, looking at my laptop, thatI have connected with

MNE101320
MNE101140

and I’m fairly sure I recognise MNE101160 as the third ECU serial number I have connected to.

Martin

[Alan Richey]

I have no idea. but I don't think it matters.   As long as you are sure it is MEMS 1.6 it should be OK (ridged cover with a single pluf, not one with a cross on the cover).  

My next thought is the wiring. 

Are you sure you have wired the 3 plugs correctly ? (http://memsdiag.blogspot.co.uk/)

What chipset are your using in your cable ?  (You can see this in Device Manager).

Is the driver correct and working ?

At the risk of stating the onbious, you do have the ignition switch ON I hope ?

[Thierry Bavois]

Hello All

I will reply on all questions:

MEMS 1.6 sure because Reference of Part MNE101150 only one connector + on air entrance for MAP inside & mini SPI 1996

3 plugs correct because , i check all the combination possible and come back to the original like http://alum.wpi.edu/~colinb/rover-mems-16-diagnostic-protocol.html

USB Serial interface FTDI manufacturer and check by oscilloscope level higher than 5V 

All the software , do the same thinks send CA in hexadecimal and wait to receive echo = CA also

But for me i receive all the time 79 from a command CA

See answer of memsread for example:

mems_send_command<>: received one nonmatching byte <79> in response to command CA

mems_init_link<>: Did not see CA command echo

Error in intialization sequence

After several discution, the reference part already tested is:

MNE101320
MNE101140

MNE101160

and all MKC xxx listed on the Mems_diag web page

The open question for me is somebody try on the part number MNE101150 ?

Are they a different protocol and data for this part number ?

If you have any idea , please give me i try what you want ?

Thanks 

BR

Thierry

[Martin Rubenstein]

Al

I see you said NOT THE ONE WITH THE CROSS ON THE COVER.

I see some images of the ECU do have a cross

eg

http://ecutechnologies.co.uk/ecu/products/rover/MNE101150/

But they could also be incorrect photos.

[Thierry Bavois]

Hi Martin

Yes i not clear sorry , mine have no Cross on top cover

see my picture on your mail, i don't want to put too much picture here :-)

And also i forgot to answer to Alan before:

If i don t turn on the key , no answer when i send CA or other command

If i turn the key with red lamp on board without starting engine , i receive 00 00 00 on Rx pin without doing anythink

If i start or not engine CA reply again different answer like 79 

BR

THierry

[Alan Richey]

I think they are 1.9.   See http://memsdiag.blogspot.co.uk/

Al

[Alan Richey]

And also i forgot to answer to Alan before:

If i don t turn on the key , no answer when i send CA or other command

If i turn the key with red lamp on board without starting engine , i receive 00 00 00 on Rx pin without doing anythink

If i start or not engine CA reply again different answer like 79 

Contrary to what Martin said I am mot an expert on this, but your answers are a bit confusing.   Let's try and be specific

1.    When you plug the cable into your PC do you get a 'ping' to show it has been recognised ?
2.    In Device Manager does it show up without a yellow warning triangle ?
3.    What COM port does it allocate?
4.    When you start MEMSGauge, do you get an error message ?
5.    Turn on the ignition.
6.    When you click on Connect do you get an error message ?

Al

[Thierry Bavois]

Hi again

My filling but perhpas i'm wrong my ECU is MEMS 1.6 when is see Lucas doc :

https://blackbox-solutions.com/help/SM002.html

I have not check the full connectivity on my ECU ,but i can check tomorrow to confirm it.

Thanks for the idea 

Can it change somethink on Command to provide to ECU MEMS 1.9 to control it ?

BR

THierry

[Alan Richey]

If it uses the 3-pin connector it MUST be 1.6.   1.9 uses an OBDII connector.

[Thierry Bavois]

HI Alan

1.    When you plug the cable into your PC do you get a 'ping' to show it has been recognised ? YES shorting RX TX on Connector i have echo with the same code i send
2.    In Device Manager does it show up without a yellow warning triangle ? No issue 
3.    What COM port does it allocate? Com7
4.    When you start MEMSGauge, do you get an error message ? no except if i click connect : error connecting ECU on port 7
5.    Turn on the ignition. YES 
6.    When you click on Connect do you get an error message ? yeserror connecting ECU on port 7

[Alan Richey]

Good.  Now, assuming that you have selected COM7 in the Preferences Menu in MEMSGauge then whenever I have seen that it has been a result of a wiring/connecting problem.   I see you used Colin's blog to do the wiring.   I highly recommend you cross check with the MEMS=Diag page as that shows EXACTLY what the wires should look like.

I assume you are not based in the UK ?   If you are I could post you my spare cable.

[Thierry Bavois]

Hello Alan

Really appreciate  Alan your proposal

I'm in france , Toulouse

After eating a pizza and thinking and reviewing all  ideas from the forum , i have my own idea :

My interface is Rs232 / usb type , i used this interface waiting another  TTL /USB from a china site (1/2 month delay).

And RS232 is +12V/-12V type  but it s requiered a TTL 0/+5V type

Tommorrow i solder some components and give you a feedback if i have corrected my mistake

Good night

Best regards

Thierry

[Martin Rubenstein]

I think you have explained where your problem is: the interface. And you cannot be sure that what you get from China will work either; will it come with a driver or at least give you a link to a driver that works? You might wait half s month and still have problems.

I got my parts from Mouser:

http://bit.ly/1X3zfXp

http://bit.ly/1ToSLyD

http://bit.ly1oqm4Uy


I’m not sure where Al got his parts. Unfortunately, I am away from home for some time otherwise I would have sent you a lead to try.


By the way, what is the problem with your car that you need to diagnose ?

[Thierry Bavois]

Hello All

Sorry for my late answer

I have succeed just now  to interface with my ECU with a good rs232 TTL interface it s working fine , Thanks again for all your help

Martin , to answer you , i have a lot issue at low RPM:

Engine limit to stop

Fyre inside  admission entrance

oscillation of Rpm

Now it s time for me to use your software , i have perform 1 min log but it s really strange perhaps it s explained my issue , to be analysised

Thanks again all, if i need help to understood wave on the analyser , i will contact you and also if i have new idea to interface this 3 pins connector( by arduino or others hardware)

BR

Thierry

[Martin Rubenstein]

Hello Thierry,

I did not understand:

“ i have a lot issue at low RPM:

Engine limit to stop
Fyre inside admission entrance

oscillation of Rpm”

By “fyrre ” you mean “fire”? Or perhaps “combustion”?

“admission entrance” do you mean the “throttle body” or perhaps “intake manifold” or maybe “air cleaner”?

“Engine limit to stop”. Do you mean the engine keeps stalling at idle?

I don’t know how good Google translate is especially with technical terms but would it help if you sent the English output from Google Translate?

I don’t mean to criticise your English - I only speak one language - but we need to make sure we understand what you write.

[SuperMario]

Hi guys, i have a question about rest of command from ROSCO which are not in table. I tested it in simply terminal and found more SID (we can call of them Service Identification Command) but they are not available in table. Could you confirm responses on own ECUs? 
I tested it on MKC101600 (Rover 620Ti)
I'm sure then:
SID 0xD0 is software ID...(of course last version on software used this)
SID 0x1D and 0x1E FAN1 and FAN2, turn on few seconds - definitelly confirmed)
SID 0xD1 looks on sometings ASCI characters  to identification hardware ID ?  producent ? something like that ?"C S 6 M R 0 0 4          T F F S X 0 0 0 Q T F F S X 0 0 0 Q $"      

List of other service which give responce 0x0 but nothing change (visually) 0x6,0x7,0xA,0xB,0xC,0xD,0xE,0x10,0x16,0x17,0x1A,0x1B,0x1C,0x65,0x6D,0x7E,0x7F,0x81,0x82,0x87,0x8b,0x8c,0xcb,0xcd,0xd2,0xd3,0xe8,0xeb,0xec,0xed,0xee,0xf0,0xf3,0xf5,0xf9,0xfc

Could you confirm then then same responces are in ours ECU's?

Regards

[leopold....@t-online.de]

Hi supermario,
have you already tested the full version of mems-rosco? Testing fan1 and 2 is already implemented there.But I do not know if it works on a 620.SID 0xD1 should answer with 0xD1 and then the ID of the ecu!

[sa...@o2.pl]

Hi Leopold :)

Definitelly test on fans run on the 620TI both of them (I operate on MKC convention name) and test on it .
Service 0xD1 give answer (directly from terminal):

2019-04-04 18:22:55.896 [TX] - D1 

2019-04-04 18:22:55.911 [RX] - D1 43 53 36 4D 52 30 30 34 09 00 04 00 54 46 46 53 58 30 30 30 51 00 00 00 54 46 46 53 58 30 30 30 51 00 00 24  

If you translate it via asci you've got letters like in previouse my post.

Could you explain me what mean in your question "full version" of rosco...there is some "not full" version ?

[leopold....@t-online.de]

"Could you explain me what mean in your question "full version" of rosco...there is some "not full" version ?"

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/mems-diagnostics/j1c0xOsFyIQ

[SuperMario]

Ha ha, i'm in a clouds :) exactly you create application , sorry Leopold . Of course I run it on my PC, but i did not test a complexity all services....if you want i can do this for you. Quickly i observe some errors like:

1. Fuel injector acturator - open a injectors, but application sent message  "error sending command" sometimes 

2. Button Fan 1 On - close realay for FAN 2 not to 1  (in direct serivce from terminal 0x1e switching Fan1 for few seconds) 
3. Button Fan 2 On - nothing happen  (in direct serivce from terminal 0x12 and 0x1D switching Fan2 for few seconds)

4. heather O2 - notthing happen (but from terminal also)

5. Boost valve - still nothing happen but my question which service you use from table ? 

Could  you extend value of maniffold pressure to 207kPa ? in turbo it's maximal value, gauge is overboosted :) in NA engine its ok, but not in turbo.

I have other question which kind of service is connect with button Reset ECU, Reset IAC, Reset emission seetings (theay are set deafult value Fuel trim,Idle decay,Idle speed,Ignition advance offset)

If i find more time i will test more :)

Coiln Burasa write abotu peeking RAM 0xCD and debug mode ? did you use this service to anything ? Where is a source of this information then this service was used ? Sorry i'm fresh in ths discussion maybe something was write here and i "missunderstandind something" - english is'ny my native language :)

Regards

[SuperMario]

Hi Leopold

One week testing away,  and probably found a huge problem with application, mean communication stack is resolve not in proper way. Why ? How is it observed ?

If ECU run with 800rpm , response for 0x7d and 0x80, take a less time if run with speed 5000rpm, it’s logical because ECU has a lot of to do if rpm  is high and slowest a transmission for ROSCO protocol.

 

On scope it is transparently visible…quick legend: pink – request , yellow – response.

Scope nr 1 is for 800rpm, response is sent below 315ms

Scope nr 2 is for 5000rpm , response is sent by 1400ms

Scope nr 3 show how your response is sent to quick for next service before previous one is processed

 

Main question is how your application control end of response ? Its hardcode timeout  or you count a response bytes ? I think this is a main problem in stack !

 

Anyway I test yet heater for lambda, still works I have a problem on my load. Generally service is ok.

 

Also I discover a problem with chart for lambda. What this mean ? if only choose only lambda voltage , Y axis is set automatically to 2000mV  , high range of  lambda should be visible to 1000mV , half chart is empty. Also problem is with below limit…. Always drop to 0 V, when on generator amplitude is set 100mV-750mV, but this can be also problem in calculation of signal inside ECU ;)