Nicometer i Nye Think

[twirk]

I have a yellow 2010 Think with zebra battery. Would I be able to use this setup to diagnose my battery charging problems?

[bcx238h]

I have a yellow 2010 Think with zebra battery. Would I be able to use this setup to diagnose my battery charging problems?

Work in progress...but I'm definitely working with diagnostic functions. 

[bcx238h]

Hello guys!

I have done few small changes in the programcode.
I wrote a lot of comments and changed some variablenames to be more consistent.
The batterypage is displaying the three SoC values, now.

If somebody want to take a look, I uploaded the zip-file. Just change the extension from .txt to .zip as usual.

Aside from that I uploaded a pdf-file. It's a scan of the original Nicometer with some extra informations and a lot of comments/explanations.

Perhaps some of you always wanted to know more about the program structure and so on.

The autorun.bas in the zip-file can be opened with the normal texteditor, too.
There are a lot of comments/explanations, too.

Remember that I use a joystick with x- and y-axis and button to move around. The program is a little bit different.

ZEBRA-battery-drivers have to change the variable "_is_enerdel" to 0. Because of debugging, I change it manually.

I have to logg more telegrams with Savvy-CAN. I want to get more informations from the 16 battery modules. Since my battery is working fine, now, I can concentrate me more on the "Nicometer". 

Just two pictures of the Nicometer as it's now...no big differences! *Debug mode with random values*

[Myles Twete]

Hi guys-
Any updates on this in the past 2 years now?
As I am now using OVMS occasionally with my 2 THINK cars, I have updated the OVMS code base for THINK City to enable capturing TPMS pressure values for display in the Android/iOS App.  OVMS also has a UI App that has its own code base and tools---simply log into the OVMS itself with 192.168.4.1 and configurations can be changed and status, etc. checked.  One thing NOT yet implemented for this UI for THINK is detailed Cell Voltage displays and analysis.  OVMS already has generic code base written to handle the display and graphical analysis of cell voltages, standard deviation, temperatures, etc. for easier diagnosis to find weak cells.  Kia Soul EV enthusiasts appear to have implemented this for their cars on OVMS, but for THINK City this has not been done yet.  The main challenge as I see it is the need to get the BMS to send detailed RLEC cell and temperature details (presumably on CAN ID's 0x0612 - 0x61d).  Given what I have read here in this thread, at least a couple of you know how to get the BMS to send this data as CommTool does.  Can you share with us here what those details look like?

BattMonitor on OVMS UI: https://docs.openvehicles.com/en/latest/components/ovms_webserver/docs/bms-cell-monitor.html

OVMS THINK City code base at GitHub: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/tree/master/vehicle/OVMS.V3/components/vehicle_thinkcity

[Warlock]

There are two IDs that the Diagnostics software sends aditional requests to the BMS-system

The Pack_command on 0x61E  (and receives answer on 0x61F).
This range needs also to be set in Commtool for it to work

The Diag_Command at 0x745 (which receives answer on 0x74D)

Depending on the content of the message, one receives a lot of info from the internals of the enerdel battery, and one can even control the contactors and bleed-resistors.

I have not tested this extensively my self, but you can always grab the communication with SavvyCAN if you use two PEAK (clone?) adapters, one for Commtool and one for SavvyCAN and go through the communication for these messages step by step.

Also there are some more info for what does what in the file "THINK City Enerdel Battery Pack Master.pdf". Some of the pictures there show a long list of special commands for Commtool to send (but maybe not the corresponding ID). Anyway, be careful if you decide to try this out...
I'm not sure what the Sec13 option do....

[Warlock]

One can actually see the communcation in commtool if one checks the "Display Raw Data"
So to get more info for the first 8 blocks Commtool sends:

61E 01 04 00 01 01
61E 01 04 01 01 01
61E 01 04 02 01 01
61E 01 04 03 01 01
61E 01 04 04 01 01
61E 01 04 05 01 01
61E 01 04 06 01 01
61E 01 04 07 01 01

so one can easily see which byte correspond to the block-number...
(third byte would be set 08-0F for the 8 next blocks)

Hints on how to decode the values returned in 0x61F might maybe be found in the Analog_xx.msf-files in addition to watching the returned raw can message and filtered and prepared values in Commtool

[Myles Twete]

Thank you, Warlock, for your detailed explanation.  I'll have to spend some time with CommTool.