Stand-alone datalogger
-
- Posts: 139
- Joined: Tue Oct 03, 2023 9:33 am
- cars: 04 Monte SSSC
04 Tahoe
92 Trans Am - Location: AZ USA
Stand-alone datalogger
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?
Re: Stand-alone datalogger
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 looked at doing the same thing. To me, it's just packet storage that you "should" be able to replay to any scanner.
-
- Posts: 139
- Joined: Tue Oct 03, 2023 9:33 am
- cars: 04 Monte SSSC
04 Tahoe
92 Trans Am - Location: AZ USA
Re: Stand-alone datalogger
I can’t imagine it to be difficult to do since tactrix did it over a decade ago.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.
Re: Stand-alone datalogger
Implementation is not that difficult, board space and board complexity would be the most difficult hurdle. Both add $$
-Enjoy
-Enjoy
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: Stand-alone datalogger
^^ Gampy is spot on!Gampy wrote:Implementation is not that difficult, board space and board complexity would be the most difficult hurdle. Both add $$
-Enjoy
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.
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
-
- Posts: 139
- Joined: Tue Oct 03, 2023 9:33 am
- cars: 04 Monte SSSC
04 Tahoe
92 Trans Am - Location: AZ USA
Re: Stand-alone datalogger
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.
Tactrix did that with the file that had the datalogging specifics on a file you had to edit to read what you wanted.
Re: Stand-alone datalogger
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 itProfessWRX 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.
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.
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
- antus
- Site Admin
- Posts: 8261
- 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: Stand-alone datalogger
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.
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: Stand-alone datalogger
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).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.
Getting the basic SAE PIDs would be simple, but extremely basic data that would not really be what people want.
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