pcmhacking.net

Is there any ideas of putting a SIM card into a future OBDX product like the openport has? Stand-alone datalogging was amazing with that. Or is there a product already that does this for GM where I can edit a script on the SIM card to datalog what I want?

Hiya,
I looked at doing the same thing. To me, it's just packet storage that you "should" be able to replay to any scanner.

In-Tech wrote:Hiya,
I looked at doing the same thing. To me, it's just packet storage that you "should" be able to replay to any scanner.

I can’t imagine it to be difficult to do since tactrix did it over a decade ago.

Implementation is not that difficult, board space and board complexity would be the most difficult hurdle. Both add $$

-Enjoy

Gampy wrote:Implementation is not that difficult, board space and board complexity would be the most difficult hurdle. Both add $$

-Enjoy

^^ Gampy is spot on!

Board space and flash memory is actually our limitations. We are moving to a similar size board design to the tactrix in future designs which we *may* have a SD CARD implementation. Main reason for the move though is to go to a bigger processor for more RAM and flash which we are seriously low on.

The next biggest problem is the fact that the scantool would need to have the entire GM logging routine coded onto it for all protocol types. This is so it knows how to setup the logging, then continue it running.
This may not be an issue for GM specifically, but adding this ability to all other manufactures would be a huge task.

I guess an easier option is setting up multiple timer based frames to fire off every "x" interval, and log every single frame that meets the filter requirements. But at this point, might as well just have your phone in your pocket and it can log it all wirelessly to the phone which eliminates all of the complexity.

The biggest request for the SDcard has been related to remote flashing. But this can also be achieved by a smartphone too.

Couldn’t you have the protocol read from a file on the SD card? Read the protocol file always named a specific file name. Then another file that has the variables and addresses to read in another file named specifically too.

Tactrix did that with the file that had the datalogging specifics on a file you had to edit to read what you wanted.

ProfessWRX wrote:Couldn’t you have the protocol read from a file on the SD card? Read the protocol file always named a specific file name. Then another file that has the variables and addresses to read in another file named specifically too.

Tactrix did that with the file that had the datalogging specifics on a file you had to edit to read what you wanted.

Thats still quite a complex command set it will need to be able to cater to ever single manufacture and setup. This then has to also be made user friendly so that people can actually create the files or modify examples to get started (This is the very hard part). No point having a feature if no-one can use it

The best possible option is having a software that creates the files and supports a bunch of manufactures plus logging parameters to generate the file to put onto the tool. Without this, it would be used by only a very few select people which would make the entire addition of it pointless.

Isnt reading PIDs standardised? So the challenge would be creating a database of proprietary pids. Once you had that I dont think it'd be too hard to have a pc app that lists them, lets you select which ones you want to poll from the logger and saves it to a config file. Since there is no display on the interface/logger you could implement the poll in a generic way for each supported OBD2 protocol and just save the pid and raw data part of the response as you log, and handle the decode of the raw data at playback time on the PC. You could come up with ways to go a little further, eg triggering an alarm if something goes out of range. Perhaps that could just be a high or low raw value saved as well.

antus wrote:Isnt reading PIDs standardised? So the challenge would be creating a database of proprietary pids. Once you had that I dont think it'd be too hard to have a pc app that lists them, lets you select which ones you want to poll from the logger and saves it to a config file. Since there is no display on the interface/logger you could implement the poll in a generic way for each supported OBD2 protocol and just save the pid and raw data part of the response as you log, and handle the decode of the raw data at playback time on the PC. You could come up with ways to go a little further, eg triggering an alarm if something goes out of range. Perhaps that could just be a high or low raw value saved as well.

The manufacture specific PIDs are not unfortunately, these also use manufacture specific modes/setups. Some manufactures require manually polling the PID (in their manner) and others will just spam data back on their own after being setup correctly (like DPIDs for GM).

Getting the basic SAE PIDs would be simple, but extremely basic data that would not really be what people want.