iMFD Protocol Update Help
Posted: Tue Dec 19, 2017 6:47 pm
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
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