WRONG RESPONSE : NR: Service Not Supported In Active Session(7F2E7F)

[Yamh631]

Hello,

I need to program a blank car radio, it's a Radio First : R-Plug&Radio+, not a R-Link.
It is impossible for me to send a long line of code in Hexadecimal (example image below : Write Phone accoustic1)
--->
WRONG RESPONSE : NR: Service Not Supported In Active Session(7F2E7F)

How to proceed ?
Thx.

EDIT : I tried on another car radio (same reference) by rewriting "Phone acoustic1" with Hexa code already present and the problem is the same.
So the problem does not come from the code sent.

[AndyIreland]

i dont know for certain but how about changing the session at the top. its set to aftersales support 10C0 - try changing it to another setting maybe?

Or it might be in wrong scenario, try setting it with engine off, gear in 1st gear (Drive in auto gearbox )

[Yamh631]

Thank you but unfortunately I had already tried.

[KarelSvo]

Do you find BUFFER FULL messages in the elm_ddt log file?

[Yamh631]

no no you are right...I delete my message.
I only found a discussion on a forum which said that long hexadecimal strings could not be transmitted with an ELM327 (PIC18F25K80), and the person had remedied the problem with a 16-bit OBDLink SX (original, not an Aliexpress clone )

I attached the 3 logs files in ZIP : logs files.zip

[KarelSvo]

I don't see any BUFFER FULL.
The command is sent in its entirety. The ECU responds to the complete request with
Service Not Supported In Active Session
Any conditions for the change are not met.

[Yamh631]

I have already reprogrammed the essentials, but I still have to send the Hexa code in the attached text file, but impossible due to the subject's error --> Reprog.txt

EDIT : I tried on another car radio (same reference) by rewriting "Phone accoustic1" with Hexa code already present and the problem is the same.
So the problem does not come from the version code sent.

[shrlnm]

Hi. I suppose that you may find the answer in the elm.log and the ecu.log. I am pretty sure the the problem in a slow conversation between elm and an ecu. Look at time took by sending long command. I suppose that it longer then 5 second. The session is closing while elm is sending the long command. Yes, the RL1 have such issue. It count the session timeout not from the last frame in the session but from last command.
I faced with this issue in the pyren and tried to solve it by turning elm timeout on the fly. You may try to use the pyran3 with cfc option enabled for writing this long command or find more faster ELM, and of course you have to use USB-ELM with serial speed not less then 215 kbod

[Yamh631]

Hi. I suppose that you may find the answer in the elm.log and the ecu.log. I am pretty sure the the problem in a slow conversation between elm and an ecu. Look at time took by sending long command. I suppose that it longer then 5 second. The session is closing while elm is sending the long command. Yes, the RL1 have such issue. It count the session timeout not from the last frame in the session but from last command. I faced with this issue in the pyren and tried to solve it by turning elm timeout on the fly. You may try to use the pyran3 with cfc option enabled for writing this long command or find more faster ELM, and of course you have to use USB-ELM with serial speed not less then 215 kbod

Hi,
Thanks I think the same thing, but i don't have R-Link, it's Radio First (R-Plug&Radio+).

With Clone ELM327 PIC18F25K80 :
I tried on Pyren3 with the CFC option, I got the same error, Uploading is much faster but takes 6 seconds.
Here is the Macro that I created for Pyren3 and the logs :

• Macro Radio 2012 V2.4.txt
• Logs.txt

---

Yesterday I ordered a very fast Vgate vLinker FS USB compared to the PIC18F25K80.
Receipt of order and Test tomorrow.

Baudrate :
PIC18F25K80 : 38'400bps
Vgate vLinker FS usb : Up to 3'000'000bps

OBD Request max size :
PIC18F25K80 : 1Kb
Vgate vLinker FS usb : 4Kb

RAM :
PIC18F25K80 : 3,6Kb
Vgate vLinker FS usb : 8Kb

Compatible Instructions :
PIC18F25K80 : ELM327 v1.4b
Vgate vLinker FS usb : ST, VT, ELM327 v2.3, ELM329 v2.2

[Yamh631]

Amazing !!!!

• I turned off the PC, then turned it back on a few hours later.
• I deleted the "DocDB_RU" folder from "pyrendata*.zip" (I don't understand the RU language)
• I retry my Pyren3 macro which sends a single parameter.....and it works! It sends the command very quickly less than 5 seconds
• I haven't changed anything else!

---

So I configure a Macro which integrates all the parameters, but it no longer works from sending the 2nd parameter, PIC18F25K80 becomes slow again (over 5seconds per parameter) --> Service Not Supported In Active Session :

• MyMacro FULL parameters.txt
• ecu_logFULL.txt
• elm_logFULL.txt

---

So I understood that I had to send 1 parameter only by Macro, and it worked for all the others (less than 5 seconds) :

• MyMacro ONE parameter.txt
• ecu_logONE.txt
• elm_logONE.txt

---

I confirm your hypothesis relating to the duration of sending Hexadecimal frames :

• If it lasts more than 5 seconds (approximately), it doesn't work.
• If it's less than 5 seconds (approximately), it works!

So I will be more comfortable when I use my Vgate Vlinker FS usb! :D

---

@shrlnm --> Windows 11, But CH340 drivers doesn't have latency adjustment.

[shrlnm]

@Yamh631 Thank you very much for logs. I suppose I found the problem. I'll try to fix it. My algorithm of tuning elm timeout on the fly is based on rtt of few previous responses. During initialisation of elm in the beginning the rtt is very low as so there is only AT commands, so before first long command it set as small timeout as 4ms. But during sending the first long command the rtt increasing up to 16 or 32 ms as so windows round it up. So before sending next commands the algorithm increase the elm timeout up to 24-28 ms and it is not small enough to send a command in 5 second.

you may try to edit the line 1666 in mod_elm.py

from
min_tout = min( 300, 2*self.response_time*1000, 4700.//len(raw_command)-16)
to
min_tout = min( 300, 2*self.response_time*1000, 4000.//len(raw_command)-16)
or
min_tout = min( 300, self.response_time*1000, 4700.//len(raw_command)-16)

Regarding DocDB_RU I don't know who is inserting it to pyrendata ). For making documentation it is better to use a telegram bot.

16ms problem is a well known Windows problem, not a CH340 driver.
https://stackoverflow.com/questions/1938048/high-precision-clock-in-python

[Yamh631]

@shrlnm Thank you for your reply.

With :
min_tout = min( 300, 2*self.response_time*1000, 4000.//len(raw_command)-16)
The first 2 parameters are sent quickly and are OK.
But from the 3rd parameters it becomes slow again --> Service Not Supported In Active Session

• ecu_log1.1666.txt
• elm_log1.1666.txt

With :
min_tout = min( 300, self.response_time*1000, 4700.//len(raw_command)-16)
The first 1st parameter is sent quickly and is OK.
But from the 2nd parameters it becomes slow again --> Service Not Supported In Active Session

• ecu_log2.1666.txt
• elm_log2.1666.txt

[shrlnm]

@Yamh631 Ok. Then you may edit the next line 1667

from
if min_tout<4:
to
if min_tout<100:
But it is not universal fix, it is only for your case

[Yamh631]

if min_tout<100:

Thanks It works ! with this modification on Pyren3 by sending "MyMacro FULL parameters.txt" (with PIC18F25K80) :

• ecu_log3.txt
• elm_log3.txt

---

---

---

I received the Vgate vLinker FS USB:
-->

On Pyren3 with Macro function, it works without modification at 2Mb/s :

• ecu_log_2Mbps.txt
• elm_log_2Mbps.txt

--

On Pyren3 with DDT function, doesn't works without modification even at 2mb/s
And therefore same error at this speed :
Service Not Supported In Active Session

• ecu_log_pyren3_ddtmode.txt
• elm_log_pyren3_ddtmode.txt

--

On DDT4ALL, impossible to connect above 115200bps.
And therefore same error at this speed:
WRONG RESPONSE: NR: Service Not Supported In Active Session(7F2E7F)

• screens.txt
• ecu_ddt.zip

[shrlnm]

@Yamh631 your new device is STN compatible

>[10/17/23 10:02:49.134]STI
<[0.016]STI
STN1170 v4.3.2

You may try to disable СFC option for it.
And also there is no profit for using speeds higher than 230Kbps as so the RTT highly depends on the same Windows 16ms problem ((

>[10/17/23 10:02:58.331]AT E1
<[0.016]AT E1
OK

>
>[10/17/23 10:02:58.347]AT S0
<[0.016]AT S0
OK

>
>[10/17/23 10:02:58.363]AT H0
<[0.016]AT H0
OK

>

[shrlnm]

In ddt4all there is another problem. It's not tune the timeout automatically, so there is RTT around 125ms (<[0.125])
You may change the timeout manually in the ddt4all

>[10:29:01.889]13282E2B2505D200
<[0.103]13282E2B2505D200
3001008181818181

>
>[10:29:01.992]2101220300000000
<[0.125]2101220300000000
3001008181818181

>
>[10:29:02.117]2200000002000000
<[0.11]2200000002000000
3001008181818181

>
>[10:29:02.227]2300000000004253
<[0.11]2300000000004253
3001008181818181

[Yamh631]

@shrlnm

My tests are now only done with the Vgate vLinker FS USB
I updated its internal firmware (Chip MIC3322) v2.0.92 to v2.3.02

I changed the minimum latency of the device which was from 16ms to 1ms, photo below.
The RTT can finally go below 16ms with the Pyren3 Macro function, see before/after logs :

• 16ms setting : elm_log_16ms_setting.txt
• 1ms setting : elm_log_1ms_setting.txt

Unfortunately this operation does not change anything on the latency of Pyren3's DDT mode, its latency is still very high (~60ms for long code with/without CFC)

---

---

I managed to connect DDT4ALL at speeds above 115200bps, just had to use the "vLinkerFSBaudrate" utility to set a higher speed (so must match with the speed chosen on DDT4ALL).

What DDT4ALL settings should I enter so that I can minimize latency for sending long commands ?

Thanks you for your help.

[Yamh631]

@Yamh631 Hi I just made a small fix in ddt mode. The mod_ddt didn't use STN adapter features before. Now it should be compatible but I can't check because I have no STN adapter. Could you please check?

I checked the code of ddt4all and found that the timeout defined on the main screen is not affect the sending of long commands and is hard coded in elm.py line 965

I'll try to do a patch for this issue but I also have no chance to check it and have to ask someone to test

@shrlnm

It doesn't work unfortunately with new Pyren3 DDT_Mode
(No CFC option)
ecu_DDT_Mode.txt
elm_DDT_Mode.txt

---

---

It doesn't work unfortunately with DDT4ALL
I enter a 1ms Timeout.

Before update code :
ecu_ddt_before.txt
elm_ddt_before.txt
screens_before.txt

After update code :
ecu_ddt_after.txt
elm_ddt_after.txt
screens_after.txt

[shrlnm]

@Yamh631
Thank you very much for testing.
I suppose I need to buy STN compatible adapter for testing myself. (( It took some time

The dd4all do not check the entered value of timeout and it have to be multiple of 4. So when you enter 1ms it round it to 0 and as a result ELM do not accept it

>
>[19:56:54.502]AT ST 0
<[0.0]AT ST 0
?

>

You may try to enter 4 ms.
I'll do one more patch for dd4all but probably not today

[Yamh631]

@shrlnm Thanks

DDT4ALL :

DDT4ALL : here with 4 ms timeout (not ok)

>
>[10:45:30.448]AT ST 1
<[0.001]AT ST 1
?

ecu_ddt_4ms.txt
elm_ddt_4ms.txt
screens_4ms.txt

---

Pyren3 Macro Mode :

MIC3322 Chip on my Vgate vLinker FS is compatible with AT ST (log Pyren3 Macro Mode) :

>
>[10/22/23 11:18:20.430]AT ST FF
<[0.0]AT ST FF
OK

Page 64 on MIC3322 Datasheet :

[shrlnm]

Ok. Then the problem in command format. It should have 2 digits like AT ST 00
I made a fix 642b00e
But I don't know how it will behave with 0 timeout so I suggest to set it not less then 4

[Yamh631]

@shrlnm well done 🥇

It works for Write at 4ms timeout with 629b672 and 642b00e
ecu_ddt.txt
elm_ddt.txt
screens.txt

But impossible to Read before 96ms timeout -> NO DATA :