Using TM-Spy for iOS

[garygid]

Ok, Ben...
I am glad the link works to get the file. Thanks for testing.
Now, here is a link to a copy of my fixed User Plots file that does not have the crash feature.
Dropbox - Public

Cheers, Gary

 

[Benjamin Brooks]

Ok, Ben...
I am glad the link works to get the file. Thanks for testing.
Now, here is a link to a copy of my fixed User Plots file that does not have the crash feature.
Dropbox - Public

Cheers, Gary

Thanks, all better

 

[garygid]

Using the new v0.1.30, the View Recipes spreadsheet is quite nice.
The first column seems wider than necessary, apparently not auto- sizing like the rest of the columns.

Cheers, Gary

 

[Turbo3]

Here is what it looks like on my device. Column 1 looks ok. All columns have auto sizing.

Using the new v0.1.30, the View Recipes spreadsheet is quite nice.
The first column seems wider than necessary, apparently not auto- sizing like the rest of the columns.

View attachment 172265

Cheers, Gary

 

[garygid]

Notice in the top row of recipes in the two screenshots aboce, that the margins around the values in my iPad version are noticably wider than those in your screenshot, like in the Z column, for example.

Is there some "squeeze as much as possible (or expand) to fit to screen" default, and in yours it squeezes a lot to try to fit, but in mine, for some reason, it thinks that it has managed to fit the screen and does not need to squeeze any farther?

Perhaps here is a clue, using View Recipes in portrait mode on the iPad, where the screen is only about 75% as wide, the spreadsheet is squeezed more, to almost but not quite fit, almost the same as the spreadsheet was drawn expanded wider to "fit", when the screen was in landscape mode, as seen in my post above. Here in portrait mode:

Then, if I turn the screen from portrait to landscape AFTER the spreadsheet is constructed in portrait mode, one can see the entire width of the spreadsheet, shown below.

Apparently an "interesting" spreadsheet drawing routine, right?
But, basically it works well enough to be very useful, I think.
Cheers, Gary

 

[Turbo3]

I found the cause earlier today. There is code to expand if the table will not fill the screen width. It looks like it does not account for the vertical lines only considering the space for the text. Another problem is they used integer numbers instead of float so there is some rounding up. End result is they overshoot the expansion by just a little. That is why you have the problem in both orientations.

Also this calculation is only done once when the Table routine is entered so if you rotate the screen the widths are not recalculated.

I need to work on another project so it will be a while before I release another version. I don't think these are critical problems so can wait.

 

[garygid]

Working in integers is probably appropriate, since they must display in whole pixels, but it does need to be done correctly. Although they use a thin line, presumably only one pixel, to separate rows, they use a thicker line, perhaps 2 or 3 pixels, to separate the columns. They use a thin vertical line on the right side of the spreadsheet, and none on the left side. They use no line, or the title box on the top, and just a thin line at the bottom. Probably just hurried, slightly careless work, but somebody's idea of "good enough". It happens frequently in library functions, even my own at times.

We wish you well in your other projects, and I will try to get some real, all-msgid Logs accumulated, while charging, while Supercharging, while driving, and while parked.

With a new function in CAN-Do, after I read one Log file, I could write a coordinated set of over 300 X-files for others to look at. Then, even those without an adapter or an appropriate OBD dongle, or reluctant to dig into their car to access the Tesla Diagnostic Connector, could have real, parallel msgid data files to look into, investigate, examine, or just "play with", even while totally off-line. I will try to accomplish this "soon".

 

[garygid]

I captured Pack Power data while Supercharging today, one file of about 159,000 frames, and a second file of about 200,000 frames, both at about 95 f/s. Overall, a successful experience. Some comments:

1. After Stop Rec (stopping the data gathering), I Saved, but then there was no option to Clear. I thought that there was one, but maybe I am mistaken, or has Clear just gone missing? Presumably, some would like to have the option to Clear the captured data instead of Saving it.

2. Then, moments later, when I started gathering again ... the magnification was not reset to 1x, but remained at something like 900x, causing the data gathering screen to show the new data way, way over-expanded. If I stopped gathering, ran the zoom down to 1x manually, and started again, the data gathering display appeared OK.

3. Instead of capturing at about 95 f/s, I would have been happy with recording at about 1 or 2 per second, but the Settings option to record at 10 f/s was no longer there. Perhaps it disappeared waiting for the new ROON (Record-One-Of-N) frames feature, which would better allow for very long recordings. Or, perhaps I just did not recall the trick filter values in the Recipe, if that is implemented. Was it set Byte C# to 9 and Equals to N ? Is that working yet, or is a Settings Option intended for the future? I do not see it mentioned in the Change Log.

4. In v0.1.30, what is the maximum number of frames in one recording? There should be somewhere for the user to see that MaxFrames number. What happens when that maximum is reached? Is there the possibility of an automatic Stop, Save, and re-Start Gathering, which would be rather cool feature?

5. When ax X-file is loaded, the frame number at the left margin is shown as 0, but perhaps 1 of 159000 would be more useful, to indicate the number of frames stored in the loaded file?

Cheers, Gary

 

[Turbo3]

1. Why would you want to clear the graph you just captured? When you start another capture it will auto-clear.

2. Gathering always starts at max magnification. To change you just need to go into Zoom mode (you don't need to stop capturing) and tap the top of the graph to zoom out. This may be changed in the future to default to one minute of data because I find it annoying to always need to zoom out. But at the moment that is the default behavior of the code and to change means adding some special code for that case.

3. Capture 1 of N has been there for a while now. Just set "C#" to 9 and the "Equals" to N. Then only every Nth frame is captured.

4. Max frames is 760,000. Any additional frames are discarded. That equates to 2 hours at 100 frame/second.

5. The left margin number is time not frame number so for a loaded graph 0 is correct. If you want to see how many frames there are go to the bottom of settings and select Debug. The first number on the third line of the graph is the total frames captured.

 

[garygid]

1. because the second graph did not start the same as the first, and ...
because it was not obvious that it would auto-clear and not append to the previous in-memory data.

2. seemed to start at 1x the first time, but not the second time. I will test again tomorrow.
I will try to get some screenshots.

3. Great, I coded some 1/5, 1/10, 1/50, and 1/100 800-Capture Recipes, which I will try tomorrow.

4. 760,000 frames max, thanks. It would be nice to be able to see that number in the app, perhaps as a note on the Settings screen in Options. Or, perhaps as 0 of 760000 (or 123456 of 760000) on the header of the data capture screen.

5. Settings Debug Enable On. Good thanks.
I will try that while gathering data ... or does supporting the Console screen adversely affect, or possibly kill, the data gathering, even when not looking at the Console screen?

Cheers, and Thanks, Gary

 

[Turbo3]

The Console is always there. You just can not get to it unless you enable it on Settings. If you go the to Console and enable live viewing of frames that might impact collection of frames but I have not tried it to see if the frame rate drops. You should only tap that feature on then quickly off again to collect a few frames to see what they look like.

There is no "Appending" of frames with a second start capture. When you start capturing it has always reset the pointer to zero. Frames are captured until you stop it. There is no "Pause". That was dropped long ago. Once the end time stamp is written that is it. Nothing else can be written to that data array. You can save the data array or start another capture which overwrites the previous data.

While capturing you see the current sample number in the lower right corner status area.

 

[garygid]

Thanks, I had noticed a comma and a growing number appended to the normal status number ... but maybe it is the number of frames captured modulo 10000?
Also, a comma space number might be more understandable, if there is sufficient room.

You know the app and its complications well. New arrivals (or old, sometimes forgetful guys like me) do not have your store of knowledge. I am trying to see the app through the new arrivals eyes, where some have said that it is difficult to figure out how to use this very-capable app.

For example, somebody is playing with data gathering, called variously capture (a good, short, descriptive term) as in "ready to capture 102" and Rec as in "Stop Rec". To you, Save means Write any captured data to an X-file, or "Write X-file". To new arrivals, the question of save what, to where, overwriting what, if anything, might come to mind. As you get closer to a Release version, a few extra well chosen words for more consistancy and easier learning might be very helpful.

Thoughts on Releasing, just thoughts... hoping for other comments or suggestions:
1. How about Releasing a free Lite version that only shows the Battery Voltages screen and the screen 1 of 4 (the voltage Histogram) so that people can easily see if the app works with their hardware? That would be only one line of code different from the Standard version, I suspect.
2. Then, add the Module Temperatures (2 of 4) and X-file viewing (3 of 4) in the standard version, and perhaps Capture and look, but possibly no Save, and no User Plots ... just a few lines of code from this to the Pro version, ... for perhaps $15, $20, or even $25 or so.
3. The Pro version, with Capture (and Save) and User Plots enabled, would also include an 800-expanded "internal Plots" so that the magic msgID (800) functions would automatically become available, as would the list of msgIDs, ... for an additional $10, $15, or some such, perhaps as an in-app "upgrade" purchase, if you know how to do that.

In any case, I plan to test more captures today. More Later.

 

[garygid]

See a discussion of the capture of "Steering Pot" data (msgID 00E) starting at post #239 in the nearby "Using TM-Spy to see Model S Data" thread.

I will try msgid 106 next ... perhaps rear drive RPM (thus Speed) and Pedal Percentage ...
so, first to gather some data in an X-file, then look at the raw data, look for 2-byte variables, try to determine zero offsets, if any, or signed values, like for the RPM, and possible scale factors.

If you cannot yet capture data with TM-Spy, you may ask for a copy of my X-file, to explore the data for yourself, if interested in such foolishness. (grin)

Cheers, Gary

 

[garygid]

See a discussion of the capture of msgID 106 starting at post #247 in the nearby "Using TM-Spy to see Model S Data" thread.
Cheers, Gary

 

[garygid]

See a discussion of the capture of msgID 102 during a Supercharging session, starting at post #252 in the nearby "Using TM-Spy to see Model S Data" thread.
Cheers, Gary

 

[garygid]

When using the LELink BT 4.0 LE dongle, if I leave it attached and powered On,
can anyone else just walk by and attach to the LELink dongle in my car?

If so, is the only practical security procedure to unplug the dongle, or install a power On/Off switch for it,
or possibly access 12v switched power somewhere near the cubby?

If one uses a WiFi dongle, at least it can have its Access Point's security password set, right?
If so, how does one set the SSID and password, if possible?

Thanks, Gary

 

[Turbo3]

When using the LELink BT 4.0 LE dongle, if I leave it attached and powered On,
can anyone else just walk by and attach to the LELink dongle in my car?

If so, is the only practical security procedure to unplug the dongle, or install a power On/Off switch for it,
or possibly access 12v switched power somewhere near the cubby?

If one uses a WiFi dongle, at least it can have its Access Point's security password set, right?
If so, how does one set the SSID and password, if possible?

Thanks, Gary

Yes, anyone with TM-Spy can stand next to your Tesla and capture data. Makes not difference Bluetooth 4.x LE or WiFi. Even WiFi with a password as the only one I know of uses 12345678 as the password. I don't know any that allow you to set your own password.

But Bluetooth 4.x LE does not show up when you go to the Bluetooth Settings menu and scan for Bluetooth devices. It only shows up there after you have connected. A normal app would only look for Bluetooth 4.x LE adapters it knows about. You would need to use an app that scans for Bluetooth 4.x LE devices to see the LELink. Then you need to know how to talk to the LELink as each Bluetooth 4.x LE adapter has its own connection parameters.

If you are really worried then power the LELink only will the Tesla is ready to drive. Or you could add a switch on the console somewhere.

 

[apacheguy]

There are indications that Telsa scrambled some messages in the most recent software. How is TM-Spy doing with motor torque and pedal position?

 

[Roadrunner13]

I manage to get my LE Link BT 4.0 delivered here in the Great White North.
So I started playing with the iOS version and this is really fun stuff!!!

I wish I could be spending more time...but after spending a couple of (scattered) hours re-reading the thread and trying to access all of its goodies,
I picked up a couple of important quotes from you, Gary and if you don't mind, I'll link back here for any new-bee trying to figure this out.

To get access to the 'View recipe' menu (discussed higher in this page),
you need some manipulation since when the app is downloaded from the store, the menu is gray out.
You want it to look like this in 'blue' when you select the top-right corner "Tesla E symbol"

To achieve this, you must download Gary's file (spyvarparmlist.csv) from Dropbox's link below (also higher on this page)

Ok, Ben...
I am glad the link works to get the file. Thanks for testing.
Now, here is a link to a copy of my fixed User Plots file that does not have the crash feature.
Dropbox - Public
Cheers, Gary

and then install it as per:
Using TM-Spy for iOS

This unlocks the 'View Recipes' gray menu.
The recipes shown can be:
1. Either the internal recipes used by the user graph recording option in the application OR
2. The custom recipes from Gary's file if you just chose to record one of these custom graphs

 

[garygid]

Making smaller X-files:
I have been logging the Pack Volts and Amps (msgID 102) using the "capture just 1 of N" feature of TM-Spy, with N set to 50. Then, a 50 minute file is only 6000 frames, instead of the 300,000 frames which would be captured when recorded at the CAN3 bus's full 100 f/s rate for the 102 msgID. To set the 1 of 50 in a Recipe, the C-byte is set to 9 and Equals is set to 50 (the desired N).

Today's Supercharger test with an S85 shows some unexpected oscillations in the charging power, in the amps or the kWatts. Does anyone actually know why these oscillations are there?

Possibly reducing power while the Pack is being cooled ... see the snapshot of module temperatures below.

The ambient temperature was only 65F this morning.

Here are the normal cell-brick voltages, and the same voltages while charging (click the thumbnail to see the full screenshot):

and

Quite a noticable voltage difference for the 6 bricks in each module, while charging, it appears. But, note that the voltage varies with basically the same patern in each group of 6 voltages (presumably within each module). This might indicate that the variation has something to do with the design or construction of the module. Possibly the apparent cell-brick voltage variations are just due to the brick voltages being not measured accurately when high currents are flowing through the module?

What are others seeing?

Cheers, Gary