Accumulated mAh/mWh not working

[KaMyKaSii]

It remains in 0.0 all the time. I'm using a tc66c with 1.16 firmware through USB. The official app can show it in the data group 1.

[kolinger]

Hello, this software doesn't support data groups. It always looks for data group 0. I don't think there is any easy way to implement support for other data groups.

Is there reason for you to use other data group than 0? Can you switch to data 0 on your TC66C? Then it should start to work as expected.

[KaMyKaSii]

Hello, this software doesn't support data groups. It always looks for data group 0. I don't think there is any easy way to implement support for other data groups.

Is there reason for you to use other data group than 0? Can you switch to data 0 on your TC66C? Then it should start to work as expected.

You're right. I had never used the record function and I don't even remember messing with it, so I believed data 1 was the default. After returning to data 0 the accumulated power is being displayed normally. Thank you for your time and this great project!

[KaMyKaSii]

@kolinger another thing: I noticed that all connection rates work except for 250ms and then the connection is made with 500ms. Do you have any idea why?

[kolinger]

This depends on how fast can meter respond. In this case the meter likely can't do more than one measurement in 500ms window thus 250ms is trying to do more but meter delays and thus the actual measurement is not every 250ms but whatever the fastest rate meter can do. I made this selection of rates based on what UM34C could do. 250ms was the fastest speed possible. It wasn't meant as something meaningful. TC66C is very different device and I guess it can't do as fast measurement as UM34C could.

These fast rates (anything faster than 1s) are not very useful in practice, since your load isn't changing that rapidly in most cases anyway. Thus using fast rates doesn't give much or any benefit most of the time yet 250ms stores 4x data or 500ms 2x more data (compared to 1s) - this makes big difference over time. Lots of measurements means slow application. So in practice you want the slowest rate usable not the fastest. Although 1s works fine for me even for sessions lasting half of day or more.

[KaMyKaSii]

This depends on how fast can meter respond. In this case the meter likely can't do more than one measurement in 500ms window thus 250ms is trying to do more but meter delays and thus the actual measurement is not every 250ms but whatever the fastest rate meter can do. I made this selection of rates based on what UM34C could do. 250ms was the fastest speed possible. It wasn't meant as something meaningful. TC66C is very different device and I guess it can't do as fast measurement as UM34C could.

These fast rates (anything faster than 1s) are not very useful in practice, since your load isn't changing that rapidly in most cases anyway. Thus using fast rates doesn't give much or any benefit most of the time yet 250ms stores 4x data or 500ms 2x more data (compared to 1s) - this makes big difference over time. Lots of measurements means slow application. So in practice you want the slowest rate usable not the fastest. Although 1s works fine for me even for sessions lasting half of day or more.

Thanks for the advice that realistically there is no need for very low rates, but I believe there is a problem in the code. Because your program can connect with a 100ms rate, only 250ms that makes the program change to 500ms. But looking at the data tab, there are 5 different data for each second, so I think the fastest response rate of the tc66 is 200ms?

[kolinger]

I see we are talking about different things. I was talking about the actual speed of measurement but now I see what you mean - selecting 250ms will switch to 500ms by itself! So there is no way to select 250ms. This is silly typo from 2018. I'm surprised you are the first to notice! Fixed now.

---

For curiosity I measured the actual speed of measurement with UM34C and timing is bit off overall:

Device	1000ms	500ms	250ms	100ms
UM34C	~1300ms	~840ms	~500ms	~320ms

This is caused by my naïve implementation where measurement is made and then application waits for 1000, 500, 250, 100, ... ms until next measurement is made. But of course measurement itself takes time so if we wait whole time then resulting period will be greater/slower than it should be.

Now I updated waiting to exclude time of measurement. Resulting actual speed is:

Device	1000ms	500ms	250ms	100ms
UM34C	~1010ms	~495ms	~320ms	~320ms
TC66C BLE	~975-1030ms	~470-540ms	~340-450ms	~340-450ms
TC66C USB	~980-1010ms	~480-520ms	~230-260ms	~80-110ms

Here you can see what I did describe before UMC34C and TC66C BLE is too slow to take faster measurement than 300-400ms. TC66C over USB is really fast though!

---

Thank you! Now timing should be fully functional and even better than before! Although faster rates are good only for short measurements. If you want to measure for hours then 1s is smarter choice as said before.

You can obtain new version here.

[KaMyKaSii]

@kolinger thank you very much for the new release! And about getting the data from group 1, this program has this option, so maybe it's possible for you to add an "Import session from device" function in your program if the user wants to be able to see the graph of an offline recording he made on the usb tester itself when there was no computer nearby

[kolinger]

Data groups are just accumulated energy values if I'm not mistaken. Correct me if I'm wrong, but I didn't see any program or script that could extracted recorded data from TC66C including official applications. This would make sense since my application can store many megabytes in one session - TC66C doesn't have that much memory on board to store so much data.

If true then it's impossible to "import session from device" since there is nothing to import. You could only extract the accumulated energy values in Wh or Ah without any history/graph curve and I don't think that would be useful.

This application works by continuously asking for new values each seconds for example. The script you talking about is working in identical fashion as I can see. So there are no graph or table data available inside TC66C. There are only two accumulated numbers. Some kind of script/program/application needs to be polling TC66C all the time to built up data for graph or table.

It would be awesome to do recordings without requiring other device but I don't think that is possible. This would be possible if, for example, RD did make TC66C version with microSD card slot for data storage. If you want to make portable / offsite recordings then Raspberry Pi (as replacement for PC/notebook) could be useful compromise.

[KaMyKaSii]

Data groups are just accumulated energy values if I'm not mistaken. Correct me if I'm wrong, but I didn't see any program or script that could extracted recorded data from TC66C including official applications. This would make sense since my application can store many megabytes in one session - TC66C doesn't have that much memory on board to store so much data.

If true then it's impossible to "import session from device" since there is nothing to import. You could only extract the accumulated energy values in Wh or Ah without any history/graph curve and I don't think that would be useful.

This application works by continuously asking for new values each seconds for example. The script you talking about is working in identical fashion as I can see. So there are no graph or table data available inside TC66C. There are only two accumulated numbers. Some kind of script/program/application needs to be polling TC66C all the time to built up data for graph or table.

It would be awesome to do recordings without requiring other device but I don't think that is possible. This would be possible if, for example, RD did make TC66C version with microSD card slot for data storage. If you want to make portable / offsite recordings then Raspberry Pi (as replacement for PC/notebook) could be useful compromise.

Sorry, I think I confused you again. I wanted to refer to recorded offline data only (the result of writing to the device itself). As I understand the offline data only consists of voltage and current pairs. What I think would be interesting would be for your program to import these values (and also the accumulated energy data) and then draw the graph itself without using Excel (the official program can does this), as it is in live mode, but of course also giving the option to export as a spreadsheet to those who need this function. And if I may give another suggestion, I find it quite confusing for "current" to appear in the "Session name" list, I ended up accidentally deleting a wrong session because of that, I double-pressed "Destroy" because I thought the session "current " would disappear after clicking "Destroy" for the first time because it is my choice to be deleted. Why not just leave the real current session name and old sessions as options? And I also realized that it's possible to create a new session with a blank name, in which case wouldn't it be better for the program by default to save the current time as the new session name or something?

[kolinger]

Oh I see now. There is very limited storage functionality. 1440 seconds with only voltage/current and without time. It is very limited but some graph could be created. I'm very easy to confuse I guess :D.

Well I added import but only for TC66C USB. I don't know how to do it over Bluetooth. Perhaps USB will be enough anyway. You can find it in "Data" tab under "Import TC66C recording".

---

"Current" is used since when you start measurement there are no data. Thus I can't easily show "Some name" since "Some name" doesn't exist from system point of view until some data is saved in database. This is technical limitation due to how application was written. It's not easy to change this so I would prefer sticking with it for now.

I don't think "Current" does too much harm. Only deletion is confusing. I disabled destroy for "current". Not great solution but workaround for accidental deletions. What do you think?

---

I see, empty session name breaks things, wasn't aware of that - fixed, now generic name will be created instead.

---

Changes included in new version - you can find it here.

[KaMyKaSii]

Oh I see now. There is very limited storage functionality. 1440 seconds with only voltage/current and without time. It is very limited but some graph could be created. I'm very easy to confuse I guess :D.

There are 1440 data pairs but tc66 lets the user choose the time rate for each pair between 1 and 60 seconds. So the shortest offline recording time is 24 minutes and the maximum is 24 hours. Do you think it would be possible in the imported session to replace the timestamp with the pair number and maybe even the accumulated time if it is possible to obtain the chosen time rate or would it be too much work? If it is, it's ok not to change.

Well I added import but only for TC66C USB. I don't know how to do it over Bluetooth. Perhaps USB will be enough anyway. You can find it in "Data" tab under "Import TC66C recording".

From what I've seen it's not really possible to get offline recording over bluetooth, only over USB.

I don't think "Current" does too much harm. Only deletion is confusing. I disabled destroy for "current". Not great solution but workaround for accidental deletions. What do you think?

It's fine by me.

One thing I noticed is that the spreadsheets generated by the official program and by TC66.py have six digits as well as in the tc66 display while on rd-usb some data has values with several digits, why does this happen? I know that mathematically there is no difference in values, but I think it would also be good to lie in the six-digit place.

Also, in the last data could you write the value of the energy accumulated in data group 0?

[kolinger]

There needs to be timestamp in order to make it look like live data and to make it work with rest of the application. Currently 1 point is always 1 seconds. It would be significant amount of work to make rest of the application work with pair number instead of timestamp.

Easier fix would be to generate timestamp in correct time scale. Then I can calculate what 1 point is and then I can generate more sensible timestamp. Is there a way to extract time scale information from TC66C? I'm not aware of that. Do you know if any other application can extract time scale for recordings? Recording itself is composed by two numbers, voltage and current, there is no time information in recording itself. Alternative would be select time scale manually when you importing. What do you think?

The digits phenomenon is natural behavior of numbers with floating decimal point. That's how float numbers behave in programming world. These numbers don't know how many decimal places they have and thus computer can miscalculated due to limited precision and make funny numbers like you see. Although mathematically they are correct. This can be fixed by rounding to fixed number of decimal places. Will do.

You are writing about "last data" you mean like to put energy only in last row? I'm not sure if recordings is "bound" to accumulated energy in TC66C. Imagine use-case where you have load connected, power is being counted and you end recording - power still continues - doesn't the accumulated power still increase beyond recording? If yes then it would be misleading since the accumulated power doesn't have directly relation to recording. It's just guess I didn't use recording what so ever.

From voltage and current I can easily calculate rest of the values like power in W. Energy in Wh or Charge in Ah needs time component thus this is related to first issue above. If I would know time scale then I can generate also accumulated energy values. Time related values will be dependent on time scale so they can generate bogus numbers if incorrect timescale is selected. Of course you can do this too in excel. Perhaps accumulated energy would not be as easy in excel as in programming.

[kolinger]

I fixed number of decimal places by rounding (voltage rounds to 4 places, current 5 places, power 3 places, resistance 1 place, accumulated to whole unit).

I don't know how to import period from TC66C but you can now specify period manually (1-60s). This will adjust timing in graph and this is also used for calculating accumulated values.

Accumulated values (mAh/mWh) are not related to recording. If recording stops - then accumulated values continues to count. Thus using these values would be confusing since they may or may not relate to recording. Thus I added the next best thing - option to calculate remaining values from current/voltage. Calculated values may not be accurate since sampling period is very long but that's the best we can get here. TC66C recording is very limiting.

Changes are available in new version here.

If you have any other suggestion let me know.

[YoungseobPark]

I think there is a problem with rate timing.. (for TC66C USB and BT) The refresh rate described by the manufacturer is 2Hz. (500ms)

Even if the value is extracted ten times for one second using the 100ms setting, there are only two changes in the data value. Of the ten data, five or more represent the same value.

Therefore, even if the program reads data every 100ms cycle, in reality, it should be judged to be a value of about 400ms to 600ms cycle.

Since I used a translator for this report, the sentence may be incorrect. :)

[kolinger]

Rate represents what rd-usb does, not what meter does.

How there can be problem with timing if you see repeating values? If you see repeating values then you are pulling data faster than the meter can measure. This may not be useful at first, but in this way you will see everything as fast as possible. Of course at expense of making duplicate measurements.

It's impossible to synchronize with TC66C exactly. Brute force with much faster rate is only possible way to improve timing. But as I said previously. Don't take <1000ms seriously, it's for fun only. 1000ms is plenty for serious measurements.

Do you have idea how to make this better?

[YoungseobPark]

I fully understood what you answered. 100% ~~ I agree. I apologize. I didn't mean to raise the issue seriously. It hasn't been long since I used this program you made.

Except for the release of a new product that is better than the rate TC66 has, I do not have a way to solve this.

I was not satisfied with the program provided by the manufacturer, so I was looking for a customized program created by someone for a while. I finally found the program you made, and I'm very satisfied. Thank you so much!