Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Using TM-Spy for iOS

This site may earn commission on affiliate links.
If one defines a Plot for acceleration (bytes 9 and 10), and uses it on a data file that does not have data bytes 9 and 10 appended, the v0.1.25 app appears to use ... maybe the D1 and D2 values (perhaps at k-8) ... is that the intended operation?

Would using the value zero (or 0xFF) be less confusing to the user?
If you try to access bytes that do not exist the app will crash.
 
Strange, when I selected Menu, Load, and then selected a new UserPlot that graphs data bytes 9 and 10, the v0.1.25 app appeared to draw some data, like perhaps D1 and D2, and not crash ... I guess I will have to try again ... or wait for a fix?

However, you are right, when I stopped the app and attempted to restart it, it just crashed, and I had to uninstall and then install the app again. Presumably, if the only frame data file was an old msgid with only 3 data bytes, and the builtin Power Plot was used by default ... the app would crash again. But, a fresh install has just a 0x102 frame data file, which is captured from an 8 data byte msgid, so the app restarts ... good.

Strangely, after the re-install, only the one default frame data file is available to Load. Isn't the app supposed to copy down the frame files from dropbox after it is enabled and restarted? The app does download my UserPlots file, but apparently not the frame data files from Apps/TM-Spy/Frames/ ... what am I missing?

Perhaps "Sync Interval" means Upload Interval, not really Sync (Upload and Download) for the frame files?

Thanks, Gary
 
Last edited:
In v0.1.25, are the frames in old frame files padded to 8 data bytes after they are read, or are the individual frames just padded to 8 data bytes before being written to a new file ... possibly with the new acceleration bytes appended?

Eventually, would there be an option to Not Append Acceleration?

In Settings, the "When app starts graphing starts" label probably means "Auto-Start Data-Gathering" (when the app starts) ... so data-gathering, not graphing perhaps, as space and font size permit?
 
Last edited:
When looking at the Data-Gathering frame (4 of 4), after going to Settings and choosing a new Plot, the chosen Plot does not get reflected into the top title line of the data-gathering page, ... except perhaps the very first time, when I thought that my selections in Settings did appear.

The selection of a new msgID in Settings does cause an update to the second line of the data-gathering page, so perhaps both lines should just be handled and updated together, like is done with the second line?
 
Last edited:
When looking at the Data-Gathering frame (4 of 4), after going to Settings and choosing a new Plot, the chosen Plot does not get reflected into the top title line of the data-gathering page, ... except perhaps the very first time, when I thought that my selections in Settings did appear.

The selection of a new msgID in Settings does cause an update to the second line of the data-gathering page, so perhaps both lines should just be handled and updated together, like is done with the second line?
The top line reflects what you are looking at on the graph at the moment so will not be updated until you take another graph. The second line says "Ready to graph..." so is telling you what you will graph next. They will only be in sync when capturing data or after capturing data and you have not gone into settings and selected a different frame to capture. Just because you go into settings and change what you want to graph next that does not change what you previously graphed and have displayed on the screen.
 
In v0.1.25, are the frames in old frame files padded to 8 data bytes after they are read, or are the individual frames just padded to 8 data bytes before being written to a new file ... possibly with the new acceleration bytes appended?

Eventually, would there be an option to Not Append Acceleration?

In Settings, the "When app starts graphing starts" label probably means "Auto-Start Data-Gathering" (when the app starts) ... so data-gathering, not graphing perhaps, as space and font size permit?
If you are looking at old data that has less than 8 bytes it will be considered an error and be padded to 8 bytes with an error message displayed on the console. No plan to make acceleration data optional. I would need to pad the bytes anyway so why not just add it. If I don't add it you are going to use a recipe that wants it and then want me to handle that case in some special way. So I avoid having that special case by just adding it.
 
Strange, when I selected Menu, Load, and then selected a new UserPlot that graphs data bytes 9 and 10, the v0.1.25 app appeared to draw some data, like perhaps D1 and D2, and not crash ... I guess I will have to try again ... or wait for a fix?

However, you are right, when I stopped the app and attempted to restart it, it just crashed, and I had to uninstall and then install the app again. Presumably, if the only frame data file was an old msgid with only 3 data bytes, and the builtin Power Plot was used by default ... the app would crash again. But, a fresh install has just a 0x102 frame data file, which is captured from an 8 data byte msgid, so the app restarts ... good.

Strangely, after the re-install, only the one default frame data file is available to Load. Isn't the app supposed to copy down the frame files from dropbox after it is enabled and restarted? The app does download my UserPlots file, but apparently not the frame data files from Apps/TM-Spy/Frames/ ... what am I missing?

Perhaps "Sync Interval" means Upload Interval, not really Sync (Upload and Download) for the frame files?

Thanks, Gary
Downloading from the Copy to TM-Spy does not depend on the Sync Interval. Just press the Home button then select TM-Spy to start the download again. It might take some time to download all the files if there are a lot of them.

Wednesday's release will pad all frames to 10 bytes but this is done on the fly while graphing so will add additional time. These old graphs should be replaced by taking new ones that have all 10 bytes of data.
 
Replacing old data is very time consuming, and reconstructing the old circumstances that were carefully logged is essentially impossible to do.

It would be relatively easy to add a function to "Standardize All Frame Files" preserving the user's carefully gathered data. Loading each frame file, doing the padding if needed, adding zero acceleration bytes if needed, and writing out to overwrite the same file ... would be very helpful, please.

Also, when Loading any frame data, seeing unpadded message data bytes and/or missing acceleration bytes could trigger a message "Standardize this frame file Now? Yes ... or ... Don't Use" would help keep all your internal checking to a minimum, and have all the fixing in one spot. Doing an app Update would trigger the requirement to re-Load any Frame file in use, just in case the Standards have changed.

The data-gathering page says "ready to gather", not ready to graph. When the gathering page is empty, cleared, and shows no data, one can change the Plot, but Settings still says that the "recipe group for next CAN capture" is something else ... somewhat confusing to most users, I suspect.

However, great progress.
 
Last edited:
To restore my frame files after an uninstall and fresh install, I need to do basically these steps?

1. Stop the TM-Spy app
2. access Dropbox and copy all the frame files from Apps/TM-Spy/Frames/ to Apps/TM-Spy/Copy to TM-Spy/
3. Start the App ... the copied frame files would be downloaded
4. probably pause the app
5. access Dropbox and erase all the frame files that I just copied, in case the app Standardizes any of my frame files ... but be careful to NOT erase my UserPlots file.
6. probably close Dropbox
7. continue using TM-Spy

Just checking to see if that is what you intend, Thanks.
 
To restore my frame files after an uninstall and fresh install, I need to do basically these steps?

1. Stop the TM-Spy app
2. access Dropbox and copy all the frame files from Apps/TM-Spy/Frames/ to Apps/TM-Spy/Copy to TM-Spy/
3. Start the App ... the copied frame files would be downloaded
4. probably pause the app
5. access Dropbox and erase all the frame files that I just copied, in case the app Standardizes any of my frame files ... but be careful to NOT erase my UserPlots file.
6. probably close Dropbox
7. continue using TM-Spy

Just checking to see if that is what you intend, Thanks.
TM-Spy will not copy down a frame file that already exists in the TM-Spy folder on your iOS device so no need to erase them from the Copy to TM-Spy folder.

It may take some time between copying files into the Copy to TM-Spy Dropbox folder until they are actually seen by TM-Spy. It takes time for Dropbox to sync everything up.
 
Replacing old data is very time consuming, and reconstructing the old circumstances that were carefully logged is essentially impossible to do.

It would be relatively easy to add a function to "Standardize All Frame Files" preserving the user's carefully gathered data. Loading each frame file, doing the padding if needed, adding zero acceleration bytes if needed, and writing out to overwrite the same file ... would be very helpful, please.

Also, when Loading any frame data, seeing unpadded message data bytes and/or missing acceleration bytes could trigger a message "Standardize this frame file Now? Yes ... or ... Don't Use" would help keep all your internal checking to a minimum, and have all the fixing in one spot. Doing an app Update would trigger the requirement to re-Load any Frame file in use, just in case the Standards have changed.

The data-gathering page says "ready to gather", not ready to graph. When the gathering page is empty, cleared, and shows no data, one can change the Plot, but Settings still says that the "recipe group for next CAN capture" is something else ... somewhat confusing to most users, I suspect.

However, great progress.
As I said tomorrow's release will handle short frames. There is just a speed penalty in padding out the short frames.

I will look into handling the case of no current graph and allowing the recipe selection to be immediately seen on the first line.
 
The msgID 0x00E is one of over 300 msgIDs that have been observed on the Tesla's CAN3 bus ... most that we know little or nothing about. The msgIDs that you see in post #161 are just the beginning of a very long list of the observed msgIDs, subject to corrections as we learn more. Those on the list that we know something about usually have a short description included there.
 
  • Like
Reactions: apacheguy
Anyone know? I ask because I see it in the screen grab in post #161 and thought someone would know the answer.
Don't know what it does but here is a trace of the first four bytes. I made up two universal plots. The first plots the first four bytes of a frame and the second the second four bytes.

There is something strange happening with the scale of the third byte I need to look into.

2016-04-12 14.20.31.png


Here are the second four bytes. You can clearly see a counter in the seventh bytes. The fifth (B4) and sixth (B5) are constant value (0x04, 0xFF).

2016-04-12 14.28.03.png
 
Last edited:
  • Like
Reactions: apacheguy
Suggestion:
On the "Graphing Saved Data" screen (3 of 4), in the Menu, it would be very helpful to have a "Show Plot's Recipes" function that would do a wide semi-transparent overlay containing the csv text of the current Plot's Recipe(s), perhaps only in landscape mode.

The overlay background would be sufficiently transparent to see a reasonable ghost of the graph behind it, yet sufficently opaque to be able to read the text of the recipes. Then, a screenshot could show, if desired, both the data graph(s), and the Plot that produced the graph(s).
 
Last edited: