iMFD Protocol Update Help

Anything related to the PLX brand of wideband devices.

Moderator: Matt

iyarovoy
 

Posts: 39
Joined: Wed Dec 23, 2015 3:47 pm
Location: California

iMFD Protocol Update Help

Post by 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
Attachments
PLXApp018.pdf
(69.97 KiB) Downloaded 226 times
nistune-1218-2236.log
(8.8 KiB) Downloaded 277 times
Last edited by iyarovoy on Thu Dec 21, 2017 5:22 am, edited 2 times in total.
iyarovoy
 

Posts: 39
Joined: Wed Dec 23, 2015 3:47 pm
Location: California

Re: iMFD Protocol Update Help

Post by 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?
Attachments
iMFD_Table_New.pdf
(119.25 KiB) Downloaded 199 times
iyarovoy
 

Posts: 39
Joined: Wed Dec 23, 2015 3:47 pm
Location: California

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
 

Posts: 39
Joined: Wed Dec 23, 2015 3:47 pm
Location: California

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
 

Posts: 39
Joined: Wed Dec 23, 2015 3:47 pm
Location: California

Re: iMFD Protocol Update Help

Post by 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!
Attachments
SerialPortEmulate.txt
(1.21 KiB) Downloaded 207 times
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
 

Posts: 18
Joined: Sat Feb 17, 2018 9:42 pm

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
 

Posts: 18
Joined: Sat Feb 17, 2018 9:42 pm

Re: iMFD Protocol Update Help

Post by nismoS14 »

HI, Matt

Please log analysis.
We are expecting bug repair.
Attachments
nistune-0303-1624_1.2.81_NG2.log
(17.06 KiB) Downloaded 149 times
nistune-0303-1623_1.2.81_NG1.log
(6.38 KiB) Downloaded 133 times
nistune-0303-1627_1.2.76_OK.log
(342.7 KiB) Downloaded 146 times
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: iMFD Protocol Update Help

Post by 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)
Attachments
imfd_replay.png
(86.03 KiB) Downloaded 10671 times
Post Reply