You're saying SSM-based stuff is better and faster, which I agree with.
But he's saying it doesn't work at all with Subarus, and that's the part I'm curious about. What protocol does it use? In other words, which cars does it work with?
Sorry for the misleading comment, what I was refering to was CF doesn't support Openport (tactrix cable) for SSM protocol for use with Subaru / Mitsubishi only ELM.
I love the look of the Nissan GTR screen and wanted the same, but still no SSM support from Centrafuse.
There are some alternatives - http://forums.fluxmedia.net/obd-ii-a...-solution.html
As I am no good with skinning or coding, I would love for someone to port this over to CF as a plugin for use with my Tactrix cable in my Subaru.
Maybe it's possible and already done, but I've yet to find it
Have you seen this?
EDIT: I see that you have. :lol:
Car: 2007 Nissan Versa wit CVT transmission
Used it for the first time last night, few observations I would like the member's thoughts on. Captured video, link below. Used snagit so no shakey camera work :)
1) RPM and km/h readings are choppy. They are smooth for a few seconds and them freezes for a half a second. You can see it in the beginning of the video
2) Accel Pedal doesn't work
3) Nothing in Fuel View works
4) Engine Load in Engine View doesn't work. Neither does Widerange o2 but I beleive I need a widerange o2 sensor to read that
5) Nothing in Fuel Flow View works
6) Gear position view. I have a CVT transmission so how does it work?
Thanks for your advice
You'll need to some customising to your car once you have identified the Parameter IDs (PIDs) your specific vehicle uses. Its quite straight forward, especially if I can do it ;). Seriously though, check out the PPE site and forum for some pointers. It takes a little bit of work but worth it!
<edit> its worth noting that your vehicle may not support the PIDs set by the DashCommand skin developer, such as the widerange o2.
volvoman1, I would guess that it is freezing every few seconds when it updates the low priority PIDs. If your vehicle's protocol is slow (or your interface is slow), it might be a noticeable difference.
DashCommand has 3 PID priorities. Priority 1 PIDs are recorded every frame. Priority 2 PIDs are recorded every 10 priority 1 frames, and priority 3 PIDs are recorded every 5 priority 2 frames. Meaning that every 50th frame it is logging all of the PIDs from the current dashboard. But it might be logging only 1 or 2 PIDs every frame.
I tried to use the dash command and carPc as my main instrument cluster, in my application I had two problems, the fuel level, PID no recognize yet by the dashcommand and the Odometer, this one is located in the BCM .
Now I'm ready to finish the car and start some test and I figure out that when I shut of the car and the CarPC goes on standby the system do not wake up, even better the CarPc crash, I tough at first the Bio set up was the cuprit , I remove the USB boot, but it still crash.
It seems that Palmer is aware of the problem and try to come with a fix, so , If you plan to use solely a dashcommand and a Scantool for a LCD display be careful.:ohwell:
Which problem are you talking about? We aren't aware of any problems that would cause a system crash. If it is a problem with our software we would be very glad to work with you to try and fix it.
It sounds like a driver problem, since a software crash doesn't usually bring down the whole computer.
Not all vehicles support every PID. My 2001 Explorer doesn't support the SAE.FLI PID, but I do have a Ford enhanced PID in ScanXL that reports the same data. Its different for every vehicle.