OBD2 scanner?
For basic code & pending code reading the Scangauge II is great (mine is mounted inside my D2 under the in dash cup holder or blank plate). However when it comes to more LR specific the iCarsoft LR2 scanner is great. It can go into each LR specific module & you can test items in each module. It also fully reads all ABS issues, and does even more on RRS/LR3’s. When I got mine it hadn’t been out long and it was buggy, but they released several updates (I check every month or so). It does not program modules like a Hawkeye, or Lynx but I grabbed my LR2 for just over 120.00.
If you ever get a newer RRS/LR3 a newer LR specific scanner like the LR2 or higher is a MUST!!!
If you ever get a newer RRS/LR3 a newer LR specific scanner like the LR2 or higher is a MUST!!!
It looks very much like a re-badged Autel. The secret is in the word "generic" codes and not specific data of the exact problem. It'll maybe do the job but a Scangauge will do exactly the same.
Unless Harbor Frieght has changed their OBDII line up none of their scanners could read or clear LR ABS Fault Codes. It would be great if they do, but last time I checked they did not.
You've got to do Option B, which is EASY, to get rid of those 3 lights.
That is cheaper and compatible with most of the software as the one I posted, but it's not as good
Here's the technical reasons.
1. The update rate on the generic elm327 compatible devices is much slower than the st.net based devices. If you are logging live data you are much more likely to catch an anomaly with the st.net chipset.
2. 5baud init https://10carbest.com/best-obd2-scanner A few of the generic ones (le link) don't have the timing correct for the "33" byte that ISO 9141-2 uses to synch. As a result it takes longer for the device to synch to the car since it is constantly retrying to connect. My le link takes about 30 seconds, the others take 1 second. Probably because 9141-2 is the least popular of the half dozen possible protocols under the obd2 umbrella no one cares to fix it or even notices. It took a logic analyzer for me to catch it.
3. The generic elm327 chips can't do advanced stuff like send a single byte or disable checksum. You'll likely never need this since you probably know someone with a real Rover dealer level scan tool, but that program I wrote that syncs alarms and clears the adaptive values requires those features in the st.net adapter
I'm pretty sure the st.net could be the last scan tool you'll ever need, it's configurable enough to adapt to future protocols and works with some odd ball stuff like GM lan and fords whatever bcm protocol
There are a lot of cool YouTube videos on this subject, here’s one of them. Good luck!
Here's the technical reasons.
1. The update rate on the generic elm327 compatible devices is much slower than the st.net based devices. If you are logging live data you are much more likely to catch an anomaly with the st.net chipset.
2. 5baud init https://10carbest.com/best-obd2-scanner A few of the generic ones (le link) don't have the timing correct for the "33" byte that ISO 9141-2 uses to synch. As a result it takes longer for the device to synch to the car since it is constantly retrying to connect. My le link takes about 30 seconds, the others take 1 second. Probably because 9141-2 is the least popular of the half dozen possible protocols under the obd2 umbrella no one cares to fix it or even notices. It took a logic analyzer for me to catch it.
3. The generic elm327 chips can't do advanced stuff like send a single byte or disable checksum. You'll likely never need this since you probably know someone with a real Rover dealer level scan tool, but that program I wrote that syncs alarms and clears the adaptive values requires those features in the st.net adapter
I'm pretty sure the st.net could be the last scan tool you'll ever need, it's configurable enough to adapt to future protocols and works with some odd ball stuff like GM lan and fords whatever bcm protocol
There are a lot of cool YouTube videos on this subject, here’s one of them. Good luck!


