Originally Posted by Fobio
I an doubtful that PPE have reduced the speed for the trial version.
Have you added extra PID's to the data logger? some PID's can cause delays in the refresh rate of the gauges/displays, during my test of the software i had the RPM gauge running smoothly (refer to page 13 of my review)
One possibility is the slower transmission of data as you are using a bluetooth OBD interface.
"The reason Bluetooth slows things down, is because of its "burst" nature: you get very high bandwith for a very short period of time, but there is a long delay between the bursts. This works well for streaming large amounts of data (e.g., audio), but is not optimal for OBD where messages are small in size, but need to be delivered as close to real-time as possible. The situation is analogous to transporting five people via a rocket train: even though it has 5000 seats, and can get from London to Liverpool in 30 seconds, there are three hours between departures" (email from Vitaliy @ scantool.net)
All my testing in my review was performed using a usb OBDLink interface.
All your computer spec if fine as per PPE defined system requirements Link
Hope this is of help to you.
I will try to check this out with a new bluetooth device i have not yet tested or used, and will let you know how i get on
If you have anymore questions let me know.
I'm going to try it again tonight with a eee901 to eliminate the NVX3000PC as the culprit...if I can deduce it is a case of the BT dongle, then I shall look into other hardware options before making the purchase.
Given that it is probably a CAN vehicle, I would personally suspect the adapter as well, but I don't think it is fair to say it is inherent to Bluetooth. It is more a matter of how BlueTooth is implemented.
Originally Posted by Moysie
On my daughter's Saturn ION (CAN, 500 Kbit), I can make about 84-90 PID reads a second over Wi-Fi. On the late model Mazdaspeed at the office (also CAN, 500 Kbit), I can get about 60-64 with the same adapter.
I haven't tried Dashcommand on either of those vehicles, but I have tried it with the exact same Wi-Fi interface on my '01 Chevy Suburban (J1850 VPW) and gotten very good gauge responsiveness (I don't know the exact polling speed because I didn't know how to get that info out of Dashcommand when I tried it). So I'm pretty sure it isn't an overtly slow RPM gauge is a software issue.
Now, here is the thing. I have a prototype of the same adapter with BlueTooth, and I can get almost (but not quite) the same performance on the same vehicles. The problem is when you take the simplest path to bluetooth, say replacing the wired serial connection to an ELM chip with an implementation of the BT "SPP" profile.
This might sound logical, but the SPP profile was seemingly designed with an old serial Hazeltine data terminal in mind. Basically keystrokes in one direction and bursts of response data in the other. The per packet latency is high, say 25-40 mS (maybe higher if both host and device have crappy SPP implementations). The ELM serial interface is small blocks of data spaced out in time. So latency can be a killer implementing BT this way.
But, just because something is the easiest path to BT doesn't mean that the performance problems it can cause are inherent in the wireless technology itself. Look at a Wii or Playstation 3, both seem to demonstrate very clearly that low latency, small data block communication over Bluetooth is readily obtainable!
btw...I didn't add any extra PID's as yet...I have used the demmo main gauge set...then also tried a customized Mazdaspeed gauge set...now since I have the demo, I wasn't expecting anything but the RPM needle to respond, so I highly doubt it was a PID set issue, and if I did suspect that ws the case, I wouldn't even have bothered to investigate further...
I also want to mention that the BT OBD2 reader looks exactly like the blue one in construction, except it was the original batch that has a orange base from the OBD2 male plug, but a clear top with a red LED and mini-USB port. I might try to plug that thing into the carpc with USB.
So I went and tested it...
with the eee901, there's still the tiniest, but acceptable latency...so now I know it's not Dashcommand/demo or the BT dongle that is causing the issue, it is strictly my under powered NVX3000PC that hits ~90% cpu usage when Dashcommand is running.
Thanks for all the help guys.
I got an email from PPE and they suggested that I turn off unused pages such as the background. And it made a bit of a difference. I then proceeded to change the priority of Dashcommand's process in task manager from normal to real time. windows gives a warning but everything is now much improved and is close to what the eeepc 901 would be doing...so I went ahead and placed an order on PPE last night.
still waiting for email for license info. =)
Hi I am using dashcommand with elmscan5 usb. car is bmw318i. the rpm is lagging, do you have some pointers to make it smoother?
Originally Posted by Moysie
Tags for this Thread