iMFD Protocol Update Help

[nismoS14]

Is the pasted data nistune-0303-1624_1.2.81_NG2.log?
Even in my environment, it will be displayed for around 10 seconds, but then the connection will be broken.

Hardware configuration has not changed with 1.2.76 and 1.2.81.
Even if software is switched alternately, 1.2.76 is no problem,
A problem occurs only by 1.2.81.

I think there is something wrong with the software.
Please investigate the cause.

[Matt]

I need more logs if possible....

Currently what I am seeing is that the data to Nistune is being cut off (incomplete) which looks like I would normally see with a hardware fault. I have taken the data you have sent to far and put into my simulator and am able to maintain a steady connection. So I have not been able to repeat the problem on this end

I understand that the previous version worked for you okay, but the more logs you can provide, it might give me a better clue as to why it is dropping out

[nismoS14]

I understand one thing.
There was no problem with SM-AFR single unit connection.
However, problems occur when connecting daisy chains(SM-EGT, SM-VAC/Boost).

It seems that communication class update affects daisy chain connection.
Because the 1.2.76 version has no problem.
I will attach a log. Please continue your investigation.
-->Daisy chain connection has been disconnected for about 10 times.

[nismoS14]

Hi, Matt

I am in trouble, so can you fix it as soon as possible?
Thank you for your help in advance.

[iyarovoy]

It seems as though my connection is more stable than the other user, but still disconnects about 2 min into streaming while driving the car.

Ill have to capture some logs and so some troubleshooting whether the issue gets better with Daisy Chain vs Single stream modules. Ill report as soon as my car is driveable again.

[Matt]

Thanks for logs:

Good frame:
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 04 00 00 00 01 37 00 12 00 0B 11 00 19 00 01 25 00 1A 00 0F 28 [40]

Bad frame:
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 04
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 06
[80 00 03] 00 01...

Good frame:
[80 00 03] 00 01 38 00 04 00 00 00 00 01 00 03 07 00 00 00 01 39 00 12 00 0B 16 00 19 00 01 25 00 1A 00 0F 28 [40]

Bad frame:
RX:[80 00 03] 00 01 36 00 04 00 00 00 00 01 00 03
[80 00 03] 00 01 36 00 04 00 00 00 00 01 00 03 06 00 00 00 01 37 00

35 00 04 00 00 00 00 01 00 03 07 00 00 00 01 39 00 12 00 0B 11 00 19 00 01 25 00 1A 00 0F 28 [40]
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 07 00 00 00 01 38 00 12 00 0B 14 00 19 00 01 25 00 1A 00 0F 28 [40]
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 07 00 00 00 01 37 00 12 00 0B 13 00 19 00 01 25 00 1A

Missing data:
01 37 00 12 00 0B 16 00 19 00 01 25 00 1A 00 0F 28 [40]
[80 00 03] 00 01 36 00 04 00 00 00 00 01 00 03 08 00 00 00 01 36 00 12 00 0B 12 00 19 00 01 25 00 1A 00 0F 28 [40]
[80 00 03] 00 01 36 00 04 00 00 00 00 01 00 03 08 00 00 00 01 37 00 12 00 0B 12 00 19 00 01 25 00 1A 00 0F 28 [40]
[80 00 03] 00 01 35 00 04 00 00

Bad frame:
RX:[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 12
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 13
[80 00 03] 00 01

RX:[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 22
[80 00 03] 00 01 35 00 04 00 00 00 00 01 00 03 22
[80 00 03] 00 01


Okay so problem is
1. AFR data only then stays connected without problem (2.14 mins)
2. Chain data, the PLX will not send the PC a whole frame (you can see the RX data it is only sending part frames, without the tail [40] byte.

Did you do chain data when running older versions of Nistune? Its just I do not see and missing data from those logs, like I am seeing here in this 'chain' log

[nismoS14]

I upload it again.
This log is chained data in the 1.2.76 version.

[Matt]

Okay thanks. This doesn't make sense since that log does not show any data received with incomplete frames

I can only think that data is being dropped whilst it is being 'read'. Perhaps a buffer overrun? I'll check the code, but not sure how this is caused

The way the truncated data occurs happens in 3x sequence. I'll add a workaround to handle the bad data, but it looks like it is coming from the device. I'm not convinced its the way Nistune is receiving the data

[nismoS14]

> I'll add a workaround to handle the bad data, but it looks like it is coming from the device.

When will the release be around?
I will cooperate in the test.

[Matt]

I will try and get one done this week. I have some other work middle of progress, so the release is not ready until that is finished also.

[Matt]

Just checking out how 1.2.76 worked and it was more tolerant to bad frame data compared to the latest version. That saying, you probably were getting bad data the whole time, but now Nistune is more sensitive to it. Appears it was looking for less bytes of data compared to current version (which is timing out and hanging up)

[Matt]

Fix has been made and tested for bad data. Details in problem report. Available in next release

[nismoS14]

Thank you to the corresponding.
I think I'm OK.
I will continue to test.

[iyarovoy]

Using Nistune 1.2.82 and a PLX AFR and Boost module in a chain, I had 0 connectivity issues over a 2 hour period, in both tuner and streaming mode.

[Matt]

Thanks. The fix was in the error detection and continuation. This means the PLX stream is sending out corrupt data occasionally, as I can see from the logs