Turbo3
Member
Don't understand as DC-DC Power plots 12 volt output voltage and current. What other parameter are you referring to as both of these are in the wk document.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
in v0.0.16 ...
1. Zoom continues to work well, nicely centering around the "time" of the touched point.
2. However, Scrolling still has the same problems (on the iPad), jumping twice on a quick scroll-swipe ... ending up too far, and following a slow drag-swipe, getting further and further ahead, and doing a final after-swipe jump that puts it even further out of place. But it does move the data left and right.
3. The message-gathering filter in the Recipe line is Byte C#, Mask C, and Equals.
When the byte # is zero, filtering is OFF.
Setting byte to 1, mask to 255, and equals to 4 with msgID 0x6F2 (1778) for the Cell Voltages would capture the brick voltage data of the first four bricks in module three (as we number them).
My next post will show how to decode the four voltage values there.
1. Zoom continues to work well, nicely centering around the "time" of the touched point.
2. However, Scrolling still has the same problems (on the iPad), jumping twice on a quick scroll-swipe ... ending up too far, and following a slow drag-swipe, getting further and further ahead, and doing a final after-swipe jump that puts it even further out of place. But it does move the data left and right.
3. The message-gathering filter in the Recipe line is Byte C#, Mask C, and Equals.
When the byte # is zero, filtering is OFF.
Setting byte to 1, mask to 255, and equals to 4 with msgID 0x6F2 (1778) for the Cell Voltages would capture the brick voltage data of the first four bricks in module three (as we number them).
My next post will show how to decode the four voltage values there.
Last edited:
Turbo3
Member
You have probably reached the limit of refresh on your iPad. Swipe up and see how long it takes to redraw the screen. That is now the limit on how fast you can scroll-swipe left/right. It is also dependent on how many points must be plotted each time so the more plots the longer it will take.
I don't have this problem on my iTouch 6 Gen with A8 processor.
Keep in mind that cell voltages frames, when filtered that way, only appear every 3.2 seconds so you are going to get a very very slow graph.
The basic battery cell/brick/module voltage and temperature info, copied from my post in a Battery thread:
For those that do not speak "code", the 8 data bytes (8 bits each) can be called D1, D2 ... D8.
The D1 value is an Index value, a counter for the 24 0x6F2 messages.
Each message has bytes D2 through D8 (7 bytes) used for 4 values, of 14 bits each.
So, string out the 8 bits of the 7 bytes as 8 x 7 = 56 bits, and use those bits, in groups
of 14 bits, as the 4 voltage (or temperature) values (14 x 4 = 56).
The 14 bits for the voltages are an unsigned integer. Multiply by 0.000305 to get cell voltage.
The 14 bits for the temperatures are a signed integer. Multiply by 0.0122 to get degrees C.
Thanks to wk057 for the exact scale factors.
For those that do not speak "code", the 8 data bytes (8 bits each) can be called D1, D2 ... D8.
The D1 value is an Index value, a counter for the 24 0x6F2 messages.
Each message has bytes D2 through D8 (7 bytes) used for 4 values, of 14 bits each.
So, string out the 8 bits of the 7 bytes as 8 x 7 = 56 bits, and use those bits, in groups
of 14 bits, as the 4 voltage (or temperature) values (14 x 4 = 56).
The 14 bits for the voltages are an unsigned integer. Multiply by 0.000305 to get cell voltage.
The 14 bits for the temperatures are a signed integer. Multiply by 0.0122 to get degrees C.
Thanks to wk057 for the exact scale factors.
Could be wrong, but the DC DC output voltage is not equal to the 12 V battery voltage. It will always be slightly higher, otherwise no current would flow.
Turbo3
Member
To graph two of the four cell voltages in the 0x6F2 message TM-Spy will need to be upgraded to support three byte variables (i.e. the "D" values).
You can capture the data now but you will only be able to graph the first and last cells in the frame.
Graphing the middle two values will required the upgraded TM-Spy and of course the recipes.
To be precises you can actually still plot the middle two values but at reduced resolution as you will be missing some low order bits.
You can capture the data now but you will only be able to graph the first and last cells in the frame.
Graphing the middle two values will required the upgraded TM-Spy and of course the recipes.
To be precises you can actually still plot the middle two values but at reduced resolution as you will be missing some low order bits.
Last edited:
Turbo3
Member
TM-Spy only displays/graphs the DC-DC 12 v output voltage.
1. Extracting the first 14 bits from D2 and D3: 2, 255, 6 and 3, 0xFC, -2
(gets 8 bits from D2 and 6 bits from D3)
2. Extract the next 14 bits from D3, D4, and D5: 3, 0x03, 12 and 4, 255, 4 and 5, 0xF0, -4
(gets 2 from D3, 8 from D4, and 4 from D5)
3. Extract the next 14 bits from D5, D6, and D7: 5, 0x0F, 10 and 6, 255, 2 and 7, 0xC0, -6
(gets 4 from D5, 8 from D6, and 2 from D7)
4. Extract the last 14 bits from D7 and D8: 7, 0x3F, 8 and 8, 255, 0
(gets 6 bits from D7 and 8 bits from D8)
Yes, TM-Spy would need to support 3-byte extraction for doing #2 and #3, but the existing version should be able to do the first and last exreactions, to see two of the voltages ... a good test.
(gets 8 bits from D2 and 6 bits from D3)
2. Extract the next 14 bits from D3, D4, and D5: 3, 0x03, 12 and 4, 255, 4 and 5, 0xF0, -4
(gets 2 from D3, 8 from D4, and 4 from D5)
3. Extract the next 14 bits from D5, D6, and D7: 5, 0x0F, 10 and 6, 255, 2 and 7, 0xC0, -6
(gets 4 from D5, 8 from D6, and 2 from D7)
4. Extract the last 14 bits from D7 and D8: 7, 0x3F, 8 and 8, 255, 0
(gets 6 bits from D7 and 8 bits from D8)
Yes, TM-Spy would need to support 3-byte extraction for doing #2 and #3, but the existing version should be able to do the first and last exreactions, to see two of the voltages ... a good test.
Last edited:
The DC to DC converter's output is probably connected to the "12v" bus, and the 12v battery is most likely also connected directly to that bus. So, when the DC to DC converter is running (like the alternator running in an ICE), the battery voltage will typically be higher and the battery will be charging.
When the 12v battery gets "fully or sufficiently" charged, the DC to DC concerter will either produce less current, or shut itself Off, and then the 12v battery will power all the car's electronics for several hours, then the DC to DC converter should turn On again, and recharge the somewhat discharged 12v battery. This cycle typically repeats 4 or 5 times a day.
Gathering the "DC-DC" data for around 6 to 12 hours should show this charging cycle.
The Plot Recipe lines for Brick Volts (hopefully correct):
PT:Brick Volts:V1:v, 2, 255, 6, 3, 252,-2, 0,5, 0,0.000305,0, 2,1,255,3,1778, 0,0,0, 0,0,0
PT:Brick Volts:V2:v, 3, 003, 12, 4, 255, 4, 0,5, 0,0.000305,0, 2,1,255,3,1778, 5, 240, -4, 0,0,0
PT:Brick Volts:V3:v, 5, 015, 10, 6, 255, 2, 0,5, 0,0.000305,0, 2,1,255,3,1778, 7, 192, -6, 0,0,0
PT:Brick Volts:V4:v, 7, 063, 8, 8, 255, 0, 0,5, 0,0.000305,0, 2,1,255,3,1778, 0,0,0, 0,0,0
I discovered that the Recipe items Mask and MsgID cannot be written in hex, like 0x6F2 for 1778.
It would be handy if the 0x... hex values were accepted ... in some future version.
Remember, in v0.0.16, that the Byte D# values are ignored, but this Recipe should still work now.
Questions:
1. If we did not use the filter when capturing the 0x3F2 messages, would the capturing be able to capture all the messages in each clump? At 8 values per module / 4 values per message ... that is 32 messages in a clump. If the 32 messages are too big of a clump, perhaps we could filter for half, or a quarter of the messages, by using a Mask C with some bits set to zero.
2. Assuming we can capture clumps of some size, does graphing use the Byte C# values to filter the captured data for the purposes of display? If not yet, in the future perhaps?
If we can do both, that would be very helpful, being able to capture all the voltage and temperature dara at one time, and then be able to see any brick voltage and/or module temperature, 4 at a time. In the future.
PT:Brick Volts:V1:v, 2, 255, 6, 3, 252,-2, 0,5, 0,0.000305,0, 2,1,255,3,1778, 0,0,0, 0,0,0
PT:Brick Volts:V2:v, 3, 003, 12, 4, 255, 4, 0,5, 0,0.000305,0, 2,1,255,3,1778, 5, 240, -4, 0,0,0
PT:Brick Volts:V3:v, 5, 015, 10, 6, 255, 2, 0,5, 0,0.000305,0, 2,1,255,3,1778, 7, 192, -6, 0,0,0
PT:Brick Volts:V4:v, 7, 063, 8, 8, 255, 0, 0,5, 0,0.000305,0, 2,1,255,3,1778, 0,0,0, 0,0,0
I discovered that the Recipe items Mask and MsgID cannot be written in hex, like 0x6F2 for 1778.
It would be handy if the 0x... hex values were accepted ... in some future version.
Remember, in v0.0.16, that the Byte D# values are ignored, but this Recipe should still work now.
Questions:
1. If we did not use the filter when capturing the 0x3F2 messages, would the capturing be able to capture all the messages in each clump? At 8 values per module / 4 values per message ... that is 32 messages in a clump. If the 32 messages are too big of a clump, perhaps we could filter for half, or a quarter of the messages, by using a Mask C with some bits set to zero.
2. Assuming we can capture clumps of some size, does graphing use the Byte C# values to filter the captured data for the purposes of display? If not yet, in the future perhaps?
If we can do both, that would be very helpful, being able to capture all the voltage and temperature dara at one time, and then be able to see any brick voltage and/or module temperature, 4 at a time. In the future.
Last edited:
Turbo3
Member
All values except min,max,scale are loaded into integer variables so if one supports the 0x hex format I don't see why another would not. Will test when I have time.
1. 0x6F2 messages come in at 10 per second which is very slow. So no problem capturing all of them. They are not sent together but equally spaced out which is why it takes 3.2 seconds to get all 32 frames.
2a. Filtering is done during capture so only the frames passing the filter are saved. Excluded frames are discarded so not saved
2b. To filter after capture would in the general case require a second frame buffer to hold all the filtered frames so zoom in/out would work. However, since there are so few filtered frames when you have one every 3.2 seconds zoom is most likely not needed. I could add filter support to "saved data" but if used on frames in the 100 per second rate the results could be very strange. To use this with the 0x6F2 frames you would capture without the filter so you get all the frames then use a recipe with the filter to view it. Version 0.0.17 that is waiting for review does not have this so it will be in 0.0.18. I could use an unfiltered 0x6F2 X_ trace file for testing.
As far as I know, no Recipe entries are accepted by TM-Spy in hex 0xHHH format.
It just would be nice if you would accept that format, because it makes the Masks much easier to debug.
I will add a Brick Capture Plot to my User Plot file, to use for unfiltered capturing.
Then, I will try to use it for a while to get a reasonable X file, and ... send both to you
It just would be nice if you would accept that format, because it makes the Masks much easier to debug.
I will add a Brick Capture Plot to my User Plot file, to use for unfiltered capturing.
Then, I will try to use it for a while to get a reasonable X file, and ... send both to you
When I change to capture a new msgID, screen 4 of 4 shows the new msgid on the second line, but still shows the old Plot name on the first line.
Then, if I try to use Menu to select a new Plot, it only allows me to select those plots that apply to the old msgID ... perhaps a little, but confusing, bug?
Worse, now the app just quits, and I cannot fix the conflict between the two msgIDs, even with a restart, so I await your sage advice to get the app usable again. I will try an uninstall and install ... that worked to get the app up, so I can try gathering data.
Then, if I try to use Menu to select a new Plot, it only allows me to select those plots that apply to the old msgID ... perhaps a little, but confusing, bug?
Worse, now the app just quits, and I cannot fix the conflict between the two msgIDs, even with a restart, so I await your sage advice to get the app usable again. I will try an uninstall and install ... that worked to get the app up, so I can try gathering data.
Last edited:
v0.0.17 appeared while I was uninstalling and then installing again ... and again ...
This version seems to work differently, not updating the two top lines on screen 4 of 4 until you start capture.
I used this no-filter Plot to capture data:
PT:Brick Capture:V1:v,2,255,6,3,252,-2,0,5,0,0.000305,0,2,0,255,3,1778,0,0,0,0,0,0
I got repeating sets of data like this, with Index values in D1 of 0x00 through 0x1F (0 through 31):
6F2007673DD6C37DBCD
6F2017973DD6C37DFCD
6F2027573DE6C37DBCD
6F20373B3DC2C37D3CD
6F20474F3DC2C37D7CD
6F20575B3DD4C37DBCD
6F20676F3DD6C37DBCD
6F2077873DE5C37D7CD
6F2087573DD5C37DBCD
6F2097573DD5C37D3CD
6F20A7433DD7C37DFCD
6F20B74B3DD8C37D7CD
6F20C6D73DBBC36AFCD
6F20D6BF3DA6C37DBCD
6F20E76B3DD6C37D7CD
6F20F7573DD6C37D7CD
6F2107873DD7C37D7CD
6F2117573DD6C37D7CD
6F2127373DC2C37CBCD
6F21371F3DC6C37DBCD
6F2147573DD8C37E3CD
6F21576F3DD6C37DBCD
6F21679B3DD5C37DBCD
6F21772B3DD5C37DBCD
6F21803054B51518414
6F2190E454561504C14
6F21A1A854721514814
6F21B01054001513014
6F21C27C53BE14F7814
6F21D118547B1516C14
6F21E11C54731528814
6F21F21054BB152F414
Graphing the first 14-bit value in each message, there are 24 voltages followed by 8 temperatures.
Converting the extracted values to voltages, I get too-low values, so something is wrong.
Of course, the temperatures would need a different conversion, probably with this Plot:
PT:ModuleTemps:TC1:degC,2,255,6,3,252,-2,-55,55,1,0.0122,0,2,1,24,24,1778,0,0,0,0,0,0
The graph shows the groups of 24 and the groups of 8:
More Later, Gary
This version seems to work differently, not updating the two top lines on screen 4 of 4 until you start capture.
I used this no-filter Plot to capture data:
PT:Brick Capture:V1:v,2,255,6,3,252,-2,0,5,0,0.000305,0,2,0,255,3,1778,0,0,0,0,0,0
I got repeating sets of data like this, with Index values in D1 of 0x00 through 0x1F (0 through 31):
6F2007673DD6C37DBCD
6F2017973DD6C37DFCD
6F2027573DE6C37DBCD
6F20373B3DC2C37D3CD
6F20474F3DC2C37D7CD
6F20575B3DD4C37DBCD
6F20676F3DD6C37DBCD
6F2077873DE5C37D7CD
6F2087573DD5C37DBCD
6F2097573DD5C37D3CD
6F20A7433DD7C37DFCD
6F20B74B3DD8C37D7CD
6F20C6D73DBBC36AFCD
6F20D6BF3DA6C37DBCD
6F20E76B3DD6C37D7CD
6F20F7573DD6C37D7CD
6F2107873DD7C37D7CD
6F2117573DD6C37D7CD
6F2127373DC2C37CBCD
6F21371F3DC6C37DBCD
6F2147573DD8C37E3CD
6F21576F3DD6C37DBCD
6F21679B3DD5C37DBCD
6F21772B3DD5C37DBCD
6F21803054B51518414
6F2190E454561504C14
6F21A1A854721514814
6F21B01054001513014
6F21C27C53BE14F7814
6F21D118547B1516C14
6F21E11C54731528814
6F21F21054BB152F414
Graphing the first 14-bit value in each message, there are 24 voltages followed by 8 temperatures.
Converting the extracted values to voltages, I get too-low values, so something is wrong.
Of course, the temperatures would need a different conversion, probably with this Plot:
PT:ModuleTemps:TC1:degC,2,255,6,3,252,-2,-55,55,1,0.0122,0,2,1,24,24,1778,0,0,0,0,0,0
The graph shows the groups of 24 and the groups of 8:
More Later, Gary
Last edited:
The all-Index brick voltage and module temperature data, graphed as collected but expanded (Zoomed by a factor of 4X), looks like this: Note the dip in the cell voltages when I turned the A/C on high for almost a minute.
Later, Gary
Later, Gary
Turbo3
Member
Version 0.0.18 has just been released. Note it says it supports hex notation in the recipe files but that is only partially true. Only for byte values so don't use hex for the MsgID or your MsgID will be converted to 0. Fixed in next release.
The one addition in this version is post capture filtering.
Three releases in one day. That is a record. I am starting to think one of my testers is also an Apple Beta reviewer.
The one addition in this version is post capture filtering.
Three releases in one day. That is a record. I am starting to think one of my testers is also an Apple Beta reviewer.
Turbo3
Member
After fixing a few bugs and changing the right side scale control parameters from integer to float here is what the post filtered data looks like on tomorrows version 0.0.19. Looks like post filtering messes up the time scale big time.
Something is strange with decoding these groups of 14 bits ...
are these bits high order on the right instead of on the left?
If so, we are going to need a way to reverse the order of the bits in a byte,
like making the byte # negative to flip the bits from right-to-left to left-to-right.
WAIT, WHAT DID YOU DO TO MAKE IT WORK ... recipe for Plot, please?
are these bits high order on the right instead of on the left?
If so, we are going to need a way to reverse the order of the bits in a byte,
like making the byte # negative to flip the bits from right-to-left to left-to-right.
WAIT, WHAT DID YOU DO TO MAKE IT WORK ... recipe for Plot, please?
Last edited: