Page 2 of 3

Re: iMFD Protocol Update Help

Posted: Tue Mar 06, 2018 2:20 pm
by 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.

Re: iMFD Protocol Update Help

Posted: Fri Mar 09, 2018 5:59 pm
by 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

Re: iMFD Protocol Update Help

Posted: Sat Mar 10, 2018 9:12 pm
by 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.

Re: iMFD Protocol Update Help

Posted: Mon Mar 19, 2018 2:30 pm
by nismoS14
Hi, Matt

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

Re: iMFD Protocol Update Help

Posted: Tue Mar 20, 2018 5:21 am
by 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.

Re: iMFD Protocol Update Help

Posted: Thu Mar 22, 2018 11:53 am
by 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

Re: iMFD Protocol Update Help

Posted: Thu Mar 22, 2018 2:33 pm
by nismoS14
I upload it again.
This log is chained data in the 1.2.76 version.

Re: iMFD Protocol Update Help

Posted: Fri Mar 23, 2018 12:45 am
by 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

Re: iMFD Protocol Update Help

Posted: Fri Mar 23, 2018 2:37 pm
by 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.

Re: iMFD Protocol Update Help

Posted: Sun Mar 25, 2018 3:24 pm
by 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.

Re: iMFD Protocol Update Help

Posted: Wed Mar 28, 2018 5:46 pm
by 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)

Re: iMFD Protocol Update Help

Posted: Thu Mar 29, 2018 11:42 am
by Matt
Fix has been made and tested for bad data. Details in problem report. Available in next release

Re: iMFD Protocol Update Help

Posted: Tue Apr 03, 2018 2:30 pm
by nismoS14
Thank you to the corresponding.
I think I'm OK.
I will continue to test.

Re: iMFD Protocol Update Help

Posted: Fri Apr 06, 2018 5:45 am
by 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.

Re: iMFD Protocol Update Help

Posted: Sat Apr 07, 2018 7:07 am
by 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