iMFD Protocol Update Help

[iyarovoy]

I hope this is the correct section to post this up.
Software: Im running latest Nistune SW with FP and ROM Pack installed.
Hardware: PLX Devices SM-AFR Gen 4 Module Only (No other device in the chain)
USB Interface: CP2102 Micro USB To TTL/Serial Module UART (I've used these in the lab at work multiple times with great success)

I am trying to tune my car but cannot log AFR with Nistune even though Nistune advertises it as a ready feature.

When connecting Nistune to the PLX module, I get one quick good read of the AFRs and then the connection times out. I've attached the logs which seems like a buffer overflow issue.

Now I contacted PLX Devices for the iMFD protocol description and received a document attached below, which seems to be outdated when comparing the document to the data flowing out of the PLX module.

The AFR module is outputting the following packet non stop @ 10Hz: 0x 80 00 00 00 01 37 00 12 00 09 25 00 19 00 01 25 00 1A 00 0F 28 40
The document describes that the packet should look like the following: 0x 80 00 00 00 01 37 40

I Decoded the packet to the following:
|0x80| |0x00 00 00| |0x01 37| |0x00 12 00| |0x09 25| |0x00 19 00| |0x01 25| |0x00 1A 00| |0x0F 28| |0x40|
{0x80}(Start Bit)
{0x00 00 00}(Address 0 Instance 0 = AFR Module)
{0x01 37}(Raw data = 0x77 shifted and when converted is equal to 14.66AFR, which is what my gauge is showing)
{0x00 12 00}(Address 18 = Volt meter)
{0x09 25} (voltage input to the module)
{0x00 19 00 01 25 00 1A 00 0F 28} (????)
{0x40} (Stop Bit)

It seems as though PLX Devices updated the protocol but has no documentation to back it up. It also seems like Nistune is not updated to support the larger packet or does not handle the situation well when the packet is not of the, what I am guessing, a hardcoded length value.

Mr Matt, can you update the PLX iMFD->Nistune driver to receive a data stream until a "0x40" byte is received or a maximum of 162 Bytes is Received (iMFD supports upto 32 devices @ 5 bytes each + 1 Start byte + 1 Stop Byte = 32*5 +2 = 162 Bytes) and then just use the first device in the byte stream as the device of interest. This way I can have 2 USB to TTL converters, one for the AFR and one for the Boost, and use the "second AFR meter" option in Nistune to log boost (if we can make it THAT configurable as described in the iMFD protocol document) since it will be the only device in the second stream.

I was really looking forward to getting my car running this holiday break only to run into this hurdle.

Thank you for the help

[iyarovoy]

I got a response from PLX Devices with an updated table of all possible devices in the iMFD protocol; it is attached below.

Decoding the Packet from a Gen4 PLX device:

|0x80| |0x00 00 00| |0x01 37| |0x00 12 00| |0x09 25| |0x00 19 00| |0x01 25| |0x00 1A 00| |0x0F 28| |0x40|
{0x80}(Start Bit)
{0x00 00 00}(Address 0 Instance 0 = AFR Module)
{0x01 37}(Raw data = 0x77 shifted and when converted is equal to 14.66AFR, which is what my gauge is showing)
{0x00 12 00}(Address 18 = Volt meter)
{0x09 25} (voltage input to the module)
{0x00 19 00} (Wideband AFR Health)
{0x01 25} (Raw data = 0x101 = 100% sensor health)
{0x00 1A 00}(Wideband Response)
{0x0F 28} (Raw Data = 0x3e8 = inf response as my sensor is not connected)
{0x40} (Stop Bit)

However Nistune falls apart when trying to decode a packet of such length. Is it possible to create a full iMFD driver for Nistune so it is able to display all the data from a a complete chain, and be log-able?

[iyarovoy]

To isolate the issue to Nistune, last night I set up 2 virtual comports connected to each other, Virtual COM4 and COM5. I used python and serial libraries to drive an input stream into COM5, which in return came out of COM4. This allowed me to play around with the packet sizing, packet rate, and packet data.

I formatted a 32byte iMFD packet and sent it at 10Hz.

Using putty/teraterm/terminal, I was able to connect to the COM4 and see my python iMFD packet stream being received at 10HZ, indefinitely.
python -> COM5 -> COM4 -> Putty = Good continuous data flow

Using Nistune
python -> COM5 -> COM4 -> Nistune = One good data read on the display and then a communication timeout.


Looking at the logs, seems Nistune is looking to read exactly 102bytes before processing any of the serial stream. This means that its looking for three 32 byte packets before parsing and displaying data. So I gave Nistune just that.

iMFD Packet: 8000000001370001000123001200092440 (AFR + EGT + Volt Meter)

I got one good read display on the nistune gauges and then communication timeout. Nistune logs show that it received 3 good iMFD packets (102Bytes), Nistune parsed it out, and then the famous "HandleNoData(): Counter: x"

As a note, during this test, no hardware was connected to the computer, all com-ports were virtual SW comports.

Any help at this point would be great.

[Matt]

Sorry for delay in reply. Communication timeout might be due to new comms code

Please use the version 1.2.76 this week until I make a fix in next few days. It is an older version but uses original comms code (not subject to timeout)

I will do an update with fix in day or so

[iyarovoy]

Thank you for the response Matt.

Do you think it could be related to windows 10? I can install windows 7 on a separate partition on the same hardware and retry the latest nistune.

Is it possible to make the com protocol user configurable? Terminate timeout, error masks, flush yes/no?

Always ready to help in anyway I can to support this product.

[Matt]

It is fixed. It is a coding problem. In the 1.2.77 version the communications class was updated to require a set amount of bytes to wait for. Consult and emulator code works fine, but most of the wideband units were affected (!) so I am going through all units and updating the code to use the SetWaitBytes() function where required

I've completed 3/4 of the coding today and just got a few more wideband units to connect up and test. I will have a release available tomorrow which fixes all units

[Matt]

Release is up. 1.2.77 was fine, but updates in 1.2.78 to communications code caused the problem for this one

[iyarovoy]

Newest release of Nistune works like a charm.

Here is the test code I used with python and a program called com0com (com port emulator).

Matt, can we have the option of what devices we want displayed? I added the attachment of the available iMDF devices from PLX in an attachment in my first few posts. Maybe like an some check boxes next to available devices in the device stream.

Thank you for the help!

[Matt]

Check boxes are a good idea (similar to consult streaming). Will require a bit of coding work, since there are many different wideband devices and each are handled differently in their own controller (but then the sensors are all combined together with the consult sensors for logging etc)

Something to look into the new year

[nismoS14]

Hi, Matt

This problem is not solved.

<Test results>
1.2.76 OK
1.2.77 Not checked
1.2.78 NG(timeout)
1.2.79 NG(timeout)
1.2.80 NG(timeout)
1.2.81 NG(timeout)

<Connected device>
SM-AFR, SM-EGT, SM-VAC/Boost --> iMFD

Can you update it?

[Matt]

Original poster iyarovoy said he was able to connect with it.

Can you please provide a debug log file so I can see the issues you are having (with the latest version). I don't have a PLX here but use a simulator so I may need to update it to reflect your configuration

[nismoS14]

HI, Matt

Please log analysis.
We are expecting bug repair.

[Matt]

Thanks. I've reviewed logs. Were these taken side by side at same time?

Details so far:
http://www.nistune.com/mantis/view.php?id=195

One of logs shows incomplete data from the PLX (iMFD frames start with 80 00 03 and finish with 40) but there are two frames with no finish (so received data was corrupted, like iMFD had reset)

Second log shows it could not connect at start, and appears to be a bug since data looks valid. I will look into that one further

[Matt]

Other log I've looked into further and shows only a limited amount of data available. I cannot see a software issue with this so far

[Matt]

I've copied/pasted the raw data into my simulator (so it just keeps sending out two different packets) and looks okay (see attached)