@antus: Lots of great info there, thanks for the response! I did see the "keep-alive" info in the ELM datasheet and also that it wouldn't send them during a ATMA monitoring command. However, with the KOEO it's my understanding that there are a bunch of administrative packets constantly being sent and the interested modules won't go to sleep. Not certain until I can finally monitor the bus (which hopefully won't be very long because the VCXNano is scheduled to arrive for next Tuesday). However, this has piqued my interest and I now have a few more newbie questions...
I'm looking for a serial cabled device to use with a standard communications terminal program (which addresses a COM port) to send my own command requests. I didn't know of anything other than ELM devices, but, after reading the above posts by @antus and @kur4o, I now see that there is an OBDLink product called SX that seems to fit the bill. It doesn't seem to support GMLAN (high speed), but will do J1850 VPW. Is this considered a quality device? Are there any other recommendations for non BT or WiFi devices?
Also, does the statement from the previous post which ends with "...or a (good) J2534 device" imply that the VCXNano I purchased isn't a "good" device? Are there any other reasonably priced (meaning for a hobbyist like myself) J2534 devices available? I see there are a bunch of Chinese cloned MDS2s out there, but just assumed that they are junk so I went with the VCXNano (which is from a US seller and, supposedly, isn't a clone). It looks like the next choice is a GM Mongoose cable, but they certainly aren't cheap (at least not to someone like me who is just playing around).
Trying to monitor the data bus with an ELM327
- antus
- Site Admin
- Posts: 9044
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Trying to monitor the data bus with an ELM327
OBDLink is a rubbish product (my opinion). No 4x speed for VPW, lots of hardware failures reported here (though lots of hardware in the wild too), small buffers when used with pcmhammer at 1x speed. LS-Droid dropped support completely, and we get a lot of reports of trouble from PCMHammer users even though it will still work with that. You are better off with the OBD-XPro which was developed by a couple of our members here after being unhappy with other options. https://obdxpro.com/
I just read the ELM327 datasheet and it does say it'll continue to monitor if it gets nothing else from the PC side, so it must be some of the alternate firmwares that get sold as ELM thesedays (anything 2.x but also with versions that clash with the original elms) that often cant do that.
I just read the ELM327 datasheet and it does say it'll continue to monitor if it gets nothing else from the PC side, so it must be some of the alternate firmwares that get sold as ELM thesedays (anything 2.x but also with versions that clash with the original elms) that often cant do that.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Trying to monitor the data bus with an ELM327
My issues with the VX nano are:
1) They install the DLLs into the system32 folder. Almost every single antivirus is triggered by their DLL due to its activity.
2) Basically zero support from the developers when trying to trouble shoot the tools. Its always the softwares fault unless you can literally provide them with 100% evidence of the issue by producing the problem using your own code and providing source code (I know this from experience).
As Antus mentioned, you can always use an OBDX Pro GT to achieve the same goal. It supports ELM commands, DVI commands (our custom byte based command protocol) and also J2534.
I actively work with dozens of developers regularly to help get them on their way with our tools

Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: Trying to monitor the data bus with an ELM327
Ok, thanks. So, the OBDLink is out and I'll look into the OBDX Pro.antus wrote: ↑Sun May 12, 2024 10:23 am OBDLink is a rubbish product (my opinion). No 4x speed for VPW, lots of hardware failures reported here (though lots of hardware in the wild too), small buffers when used with pcmhammer at 1x speed. LS-Droid dropped support completely, and we get a lot of reports of trouble from PCMHammer users even though it will still work with that. You are better off with the OBD-XPro which was developed by a couple of our members here after being unhappy with other options. https://obdxpro.com
Confused here. I spent more for the v2.1 because the datasheet listed it as the latest version. The other option was a v1.5, but the datasheet didn't even list a v1.5 (pages 90-91). Are you saying the v2.1s all have alternate firmware and I would probably have better luck with a v1.5? Are there still American makers of the ELM (I believe my 9-pin serial port one was called like ELM Scan 5, or something like that)?antus wrote: ↑Sun May 12, 2024 10:23 am I just read the ELM327 datasheet and it does say it'll continue to monitor if it gets nothing else from the PC side, so it must be some of the alternate firmwares that get sold as ELM thesedays (anything 2.x but also with versions that clash with the original elms) that often cant do that.
.
.
Ouch! Well that sucks! As for the system23 folder, thanks for the heads-up. I'll look for the files it puts there and exclude them from my virus program. This info probably saved me a ton of 'ghost in the machine' headaches.Tazzi wrote: ↑Sun May 12, 2024 12:05 pm My issues with the VX nano are:
1) They install the DLLs into the system32 folder. Almost every single antivirus is triggered by their DLL due to its activity.
2) Basically zero support from the developers when trying to trouble shoot the tools. Its always the softwares fault unless you can literally provide them with 100% evidence of the issue by producing the problem using your own code and providing source code (I know this from experience).
Nice to hear customer service isn't dead these days! Sadly, it so often seems as though that's the case. I'll definitely look into the Pro GT. Had I known about it prior to buying the VCXNano I would have went that route. Hopefully, the Nano is useful as I'm expecting it today!Tazzi wrote: ↑Sun May 12, 2024 12:05 pm As Antus mentioned, you can always use an OBDX Pro GT to achieve the same goal. It supports ELM commands, DVI commands (our custom byte based command protocol) and also J2534.
I actively work with dozens of developers regularly to help get them on their way with our tools![]()
- antus
- Site Admin
- Posts: 9044
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Trying to monitor the data bus with an ELM327
ELM has closed down, as far as I know everything is either a clone or alternate implementation but it is possible you have genuine, even if unlikely. According to their site they did make a 2.0, 2.1, 2.2, 2.3
The problem is the cloners always try to copy the genuine and do not gracefully use difference version numbers so that you can tell what you have. YMMV.
https://www.elmelectronics.com/
https://www.elmelectronics.com/obdtips.html#the327
When I said good J2534, I was referring to the fact there are a lot of cheap devices on ebay which claim to be J2534 compatible, but in reality they were built to only meet the minimum requirements of one particular manufacturer or anothers program. These ones are out there, and if you end up with one of them you may be in the same situation as with the ELM. J2534 is a good protocol, but it's impossible for me to say every tool with J2534 on the box or the description is going to work for all applications.
The problem is the cloners always try to copy the genuine and do not gracefully use difference version numbers so that you can tell what you have. YMMV.
https://www.elmelectronics.com/
https://www.elmelectronics.com/obdtips.html#the327
When I said good J2534, I was referring to the fact there are a lot of cheap devices on ebay which claim to be J2534 compatible, but in reality they were built to only meet the minimum requirements of one particular manufacturer or anothers program. These ones are out there, and if you end up with one of them you may be in the same situation as with the ELM. J2534 is a good protocol, but it's impossible for me to say every tool with J2534 on the box or the description is going to work for all applications.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Trying to monitor the data bus with an ELM327
My original serial port ELM Scan is authentic, but I believe the firmware is old (like 1.2). As time permits, I'll dig it up and look into it.
In other news, the VCX Nano I ordered arrived yesterday. It most certainly does work with Universal Patcher's Logger! Monitors the bus absolutely perfectly and I was able to determine a number of things of interest:
1) The USB ELM unit I have doesn't send any message over seven data bytes (total, including the 3-byte header) regardless of the AL setting.
2) The ELM will send physical requests but the response is either "NO DATA" or just a line feed. This is hugely problematic because, If one is querying a module for data, the module's response won't ever appear. This is as useful, or useless, as not even sending the command. Thus, no enhanced PID or specific module VIN requests.
3) If a command is sent, for example, to lock the doors, the response will be "NO DATA," but the doors will lock since it sends the command. Again, commands are 7-byte limited so no special OEM module commands such as IPC tests, etc.
4) All commands (7 bytes or less) which begin with 68 6A will show the returned response. Apparently the hardware watches only for 48 6B as the first two bytes of messages. Otherwise "NO DATA," or in some cases just a LF are returned.
A quick note about UP's Logger... It worked flawlessly, and it also sent every message I manually typed in regardless of length or validity (as should be the case). The only issue I had with using the software and VCX Nano was that the Nano needed to be plugged into the USB port before it was connected to the OBD2 port. If it was connected to the OBD2 port and then plugged into the USB port, UP wasn't able to connect to it and returned a device error message (not a big deal at all, just thought I would mention it in case it helps anyone else).
In other news, the VCX Nano I ordered arrived yesterday. It most certainly does work with Universal Patcher's Logger! Monitors the bus absolutely perfectly and I was able to determine a number of things of interest:
1) The USB ELM unit I have doesn't send any message over seven data bytes (total, including the 3-byte header) regardless of the AL setting.
2) The ELM will send physical requests but the response is either "NO DATA" or just a line feed. This is hugely problematic because, If one is querying a module for data, the module's response won't ever appear. This is as useful, or useless, as not even sending the command. Thus, no enhanced PID or specific module VIN requests.
3) If a command is sent, for example, to lock the doors, the response will be "NO DATA," but the doors will lock since it sends the command. Again, commands are 7-byte limited so no special OEM module commands such as IPC tests, etc.
4) All commands (7 bytes or less) which begin with 68 6A will show the returned response. Apparently the hardware watches only for 48 6B as the first two bytes of messages. Otherwise "NO DATA," or in some cases just a LF are returned.
A quick note about UP's Logger... It worked flawlessly, and it also sent every message I manually typed in regardless of length or validity (as should be the case). The only issue I had with using the software and VCX Nano was that the Nano needed to be plugged into the USB port before it was connected to the OBD2 port. If it was connected to the OBD2 port and then plugged into the USB port, UP wasn't able to connect to it and returned a device error message (not a big deal at all, just thought I would mention it in case it helps anyone else).