# Elcon/TC Charger Firmware: DIscussion



## Coulomb (Apr 22, 2009)

*Elcon/TC Charger Firmware: Discussion*

This thread is intended to discuss Elcon/TC charger firmware.

Please post all facts to the Elcon/TC Charger Firmware: Facts thread.

I know it's probably a hopeless task, but I'd like to keep most of the discussion in this thread, and keep the facts thread relatively free of "can I have this feature?" or other discussion, so it's easier to find the "meat" in the facts thread. We'll see how this goes; I can only ask for your cooperation.


----------



## Yukon_Shane (Jul 15, 2010)

Firstly thanks to you (and others) for taking this on and publically documenting your findings. I think this charger is probably the best option for the DIY EV market at the moment with the exception of the (extremely frustrating!) inability to change the charging profile without sending it back to the manufacturer. I hope this turns into something that can be completed by the average person.

With respect to the legal question you raise in the other post, I can't speak to the legality of publically providing this information; however, my understanding is that this design was "borrowed" from delta-Q anyway so I don't think that there's much of a moral argument to be made for not sharing any and all of your findings regarding the charger design and operation.

just my two cents...


----------



## Coulomb (Apr 22, 2009)

Yukon_Shane said:


> Firstly thanks to you (and others) for taking this on and publically documenting your findings.


Thanks for the kind words, and thanks for starting off discussion on the discussion page!



> I hope this turns into something that can be completed by the average person.


Alas, I think it won't be accessible to everyone. But hopefully, they will be able to find someone at their own EV club or at least in their own city that can do it for them. Freight of complete chargers is a problem. Worse is the way that Chinese import restrictions effectively prevent sending anything *into* China. A colleague had his charger fail, sent it back, and it got stuck in customs, and wouldn't get through despite being marked "returned for repair". They eventually sent a complete new charger. They obviously can't afford to do that very often. So even if the manufacturer was more willing to take on repairs and/or firmware updates, they simply can't.



> however, my understanding is that this design was "borrowed" from delta-Q anyway so ...


I've heard that, and I have some Delta-Qs (or maybe clones of those) from people that actually mistook them for Elcons. ("Oh, you repair and upgrade Elcons? Here, take a look at this for me"). I see a lot of similarities, perhaps even a similar basic layout with some exceptions. But the processor is totally different, so from the firmware point of view, nothing we've learned from the Elcons will apply (or if it does, only in a rather general sense).

Maybe Delta-Q's will be next...


----------



## PStechPaul (May 1, 2012)

I'm not familiar with the Elcon chargers, and my only experience has been with the EMW DIY chargers, which are open-source. I am trying to come up with ways to improve that design for those who have had problems with it, and I am curious about the overall design of the Elcon. I will be following your "facts" thread to see if you will have some block diagrams, schematics, and theory of operation, and I might use parts of that for my purposes. I don't intend to compete in any way with either manufacturer, but perhaps I might be able to provide alternative monitor and control modules that could be used with the basic hardware of either.

I just noticed that this is about the firmware, and I am mostly interested in the hardware, but it is interesting to see some of the assembly code and peculiarities of the 8051 type device. It seems the Elcon website does not have very much detailed information.
http://www.elconchargers.com/index.html


----------



## Coulomb (Apr 22, 2009)

PStechPaul said:


> I am curious about the overall design of the Elcon. I will be following your "facts" thread to see if you will have some block diagrams, schematics, and theory of operation...


Well, there is already the Elcon/TC charger 1.5 kW schematics and Troubleshooting and Repair threads. I was thinking about separate Elcon/TC charger FAQ page as well.




> It seems the Elcon website does not have very much detailed information.
> http://www.elconchargers.com/index.html


 That's the Elcon distributor in California; these are re-branded TC chargers from China. Though I note that Elcon have some models (the 2.5 kW models) that TC are not advertising. I suspect that the 2.5 kW models are no longer made, but they are still in stock in Sacramento. Or perhaps their web site is out of date. There is a little more information on the TC charger site:
http://www.tccharger.com/english/ .


----------



## kennybobby (Aug 10, 2012)

It seems to me that the difficulty in making changes is compounded by the fact that each model of the charger has specific voltage, current and power ratings, calibrations and limits that are unique for that model in both the hardware and the controller.

And the unique factors are stored in the chip's eeprom which is separate from the flash memory of the firmware.

It can be done, but it is not a one-click and done process as yet.


----------



## Coulomb (Apr 22, 2009)

kennybobby said:


> And the unique factors are stored in the chip's eeprom which is separate from the flash memory of the firmware.


This is true; this is notionally a good separation.

Unfortunately, in way too many of the firmwares that I've examined, they don't read the unique factor from the EEPROM as they could and should, but use "constants" that end up in the flash. When I say constants, I mean values that won't change day to day but will change if the voltage or current limit is changed. That makes our job a little harder.

But once we have found all these, we can actually fix them, and our canonical firmware(s) can be nicely independent of the unique factors.


----------



## Caps18 (Jun 8, 2008)

kennybobby said:


> It seems to me that the difficulty in making changes is compounded by the fact that each model of the charger has specific voltage, current and power ratings, calibrations and limits that are unique for that model in both the hardware and the controller.
> 
> And the unique factors are stored in the chip's eeprom which is separate from the flash memory of the firmware.
> 
> It can be done, but it is not a one-click and done process as yet.


But, could you clone the eeprom of a version of the charger with the voltage level you want then?


----------



## pdove (Jan 9, 2012)

Caps18 said:


> But, could you clone the eeprom of a version of the charger with the voltage level you want then?


Yes most definitely. We can extract the EEPROM values from one an put them in another. 

However, the EEPROM is uniquely tuned for the resistors present in that unit so they won't be exactly the same.

We have replaced processors and created the EEPROM values based on the resistors dividers in the unit.


----------



## piotrsko (Dec 9, 2007)

What I have seen is the max voltage is based on the transformer ratio and detector resistor network, or in the case of my 216 max unit, 216 vdc. Lower parameters to about 170 are possible (20%) with the eeprom settings but not higher. Custom fiddling with the divider could get you lower still at the expense of higher tops. This appears to be limited by the 0 -5 range of the comparator.


----------



## Coulomb (Apr 22, 2009)

piotrsko said:


> What I have seen is the max voltage is based on the transformer ratio and detector resistor network, or in the case of my 216 max unit, 216 vdc. Lower parameters to about 170 are possible (20%) with the eeprom settings but not higher.


I'm not sure what you are saying here. With the right firmware, you can go pretty much as low as you want. I have converted a 144 V nominal charger (170 V max) to a 48 V nominal lithium charger. It's still 30 A (it is a 5 kW charger, 30 A at ~170 V), and I'm still limited to 15 A. I got this charger free as part of an EV kit; I really only wanted the lithium batteries for a solar power system. So I don't mind throwing away about 66% of the charger power by running at one third voltage. So a lot more than 20% reduction in output voltage is possible.

Edit: I experimented with forcing more current out of it, assuming that the bottleneck was the front end. I did manage 18 A out of one side (normal maximum is 15 A per half; a 5 kW charger has two 2.5 kW chargers paralleled inside). But I figured that the output stage has limits too, so I put the limit back to 15 A.


----------



## Coulomb (Apr 22, 2009)

I'm having trouble finding a way to post snippets of code.

There is the code tag, but that puts the code into a narrow window with a scrollbar, about a third of my desktop screen, and not adjustable. The scrollbar is a nuisance. I tried saving the result in HTML, which looks great in color, but the HTML tag shows the HTML code, and doesn't render it.

I tried attaching an image, and that works well. I can get the URL of the attachments, and insert them inline, so I can refer to them with next near the code. But it's a lot of work, and it leaves these large thumbnails at the bottom of the post. I think I've seem others get rid of these thumnails, but can't find a way to do this. I tried removing the attachments, and that seems to work, but I was horrified to find that it was only showing them from my browser's cache, and now a few days after posting them they've disappeared. They likely never appeared for anyone else.

I've tried just pasting text and using a fixed point font like Courier New, but multiple spaces are compressed to a single space, making the code unreadable.

Does anyone have a good solution for this?

Now I'm off to re-upload all my images. Joy.


----------



## Coulomb (Apr 22, 2009)

Roy Von Rogers said:


> My question is this, are they doing this on purpose to make it hard for someone else to program, or is it to using older and maybe cheaper processors etc.
> 
> I saw Jack showing how to program with the CAN unit, and it was easy to re program. I'm just amazed that the software the factory used has not been hacked, I'm sure that the hardware they use cant be anything special.


I see no evidence that they are making this hard for others to program, other than the security bits, which are pretty standard in the industry.

Yes, the CAN version is easy to program, and I'm a little surprised that more people don't go that route. But I guess many people want a one box set and forget solution. Perhaps if they put a real, isolated RS232 port on the charger instead of the CAN bus, more people might have chosen the CAN option. But I can see that CAN is more suitable for cars, which is surely their main market.

Or maybe make them all CAN, but with a plug-in, easily removable (say with one screw) module that controls the parameters for stand alone applications, and that module is friendly for people to program/reprogram. But I guess that would add a lot to the cost. Actually, I guess I'm describing Jack's programming box; I suppose I'm suggesting making that box either part of the charger, or readily available from the manufacturer (as a sort of ordering option, like the CAN box is now).


----------



## PStechPaul (May 1, 2012)

The way I display images is to store them on my web space and then use the image button to wrap the [ img ] tags around the URL.

I thought there might be a BB code equivalent to the HTML < pre > tag but I could not find it.

Perhaps it would be useful to post a direct link to the code in TXT or ASM format which would be recognized by a smart text editor like Notepad++ and displayed as source code. I think you can attach text files and source code. I see that TXT is supported but not ASM or CPP. Maybe use DOC format?

The images may be helpful to show comments and highlight parts of the code, but having the actual text may be more helpful.


----------



## dcb (Dec 5, 2009)

PStechPaul said:


> I thought there might be a BB code equivalent to the HTML < pre > tag but I could not find it.


use CODE (or the hashtag button)

```
this
   text
      is
        really
           pre
```


----------



## CKidder (Dec 12, 2009)

Is there any information available on how to update the charging profile yourself? I need to change the parameters on a TCCH 4kw charger and I'd rather not have to send it to California. Would this be possible with the same tools required to work with the firmware or is there some different pathway? Is it just an EEPROM edit?


----------



## kennybobby (Aug 10, 2012)

CKidder said:


> ...I need to change the parameters on a TCCH 4kw charger


Same tools are needed and you could easily do this. If this is a factory TCCH Lithium charger then it might be a good candidate for reading the firmware before making changes--we suspect that the elcon versions are slightly different than the TCCH and it would be a big help to see for sure.


----------



## CKidder (Dec 12, 2009)

kennybobby said:


> Same tools are needed and you could easily do this. If this is a factory TCCH Lithium charger then it might be a good candidate for reading the firmware before making changes--we suspect that the elcon versions are slightly different than the TCCH and it would be a big help to see for sure.


Oh, sorry, it's an Elcon PFC4000. Is there any write up somewhere about how to tweak the EEPROM settings or would I have to figure out the format?


----------



## pdove (Jan 9, 2012)

CKidder said:


> Oh, sorry, it's an Elcon PFC4000. Is there any write up somewhere about how to tweak the EEPROM settings or would I have to figure out the format?



You do not need to Change EEPROM.

The curve data is located in the firmware.

You modify the curves.c for your requirements. Then you'd modify the curves.Uv2 Microvision project file to use that file name, and save that as a new file. Use Microvision 3 to compile it to a .SRC (assembly language) file.

This .SRC file has to be massaged a bit; modify the edit_curves script to produce a new .a51 file from the .SRC file. Save this new script and use Cygwin to run it and actually produce the new .a51 file compile and link it... produce a new ordered hex file.


----------



## Coulomb (Apr 22, 2009)

CKidder said:


> Oh, sorry, it's an Elcon PFC4000.


They are all much the same inside, except that there is a 1500 W model and a 2000+W model. In the USA (Elcon branded chargers) there seems to be a distinction between 2000W and 2500 W, with the former somehow optimized for 120 V operation. A 4000 W charger will have two 2000 W units inside it, a "master" and a "slave".



> Is there any write up somewhere about how to tweak the EEPROM settings or would I have to figure out the format?


As mentioned above, you don't need to change the EEPROM values (as you would expect), but it's all in the 8 KiB firmware image.

I do intend to publish full details on how to do the firmware upgrades, along with all the firmware source code needed. I'm just a bit snowed under (not literally; it's the middle of summer here).

I note that this is moderately complex software; this will not be for everyone.


----------



## Weisheimer (May 11, 2009)

I suspect that Collin can handle it...

Collin,
I have one of the LPC9XX-USB programmers with an "Elcon/TCCH" plug on it.
If you want to pull the firmware from your processors I can send it to you.


----------



## pdove (Jan 9, 2012)

Coulomb said:


> I note that this is moderately complex software; this will not be for everyone.


Ckidder is a top notch programmer.


----------



## Weisheimer (May 11, 2009)

pdove said:


> Ckidder is a top noth programmer.


I dunno, maybe he is a Top Goth Programmer...

(he is indeed, a top notch programmer)


----------



## Weisheimer (May 11, 2009)

Coulomb, Paul, and Kenny,

Fine job you fellows are doing here and I applaud your work.

The Elcon/TCCH/Chennic chargers are a very decent charger and making this information available opens up the 2nd most popular (only the Zivan is used in more DIY projects) DIY EV charger to further use.
If looking at the numbers by most recent purchases, the E/T/C charger is more popular.

I have a question about the firmware. Coulomb mentions the role of "calibrated" voltage values in the EEPROM. Are there any calibrated values for current as well?
Do you see any process or routine for determining these calibration numbers in the current firmware available?
I envision a bench set up where a known DC voltage(s) is presented, the value is measured by the existing divider network, and the calibration numbers are thus read and available for use in the EEPROM.
Or is the only choice to read the EEPROM values and re-use them when reflashing?


----------



## kennybobby (Aug 10, 2012)

Quick answer is Yes, there is need for calibration of the current measurement in addition to the voltage.

There is no calibration routine in the firmware, but Mike is better positioned to answer on this subject.


----------



## pdove (Jan 9, 2012)

Weisheimer said:


> Coulomb, Paul, and Kenny,
> 
> Fine job you fellows are doing here and I applaud your work.
> 
> ...


Not sure I follow what you are wanting.

The values in EEPROM are numbers to convert counts to voltage and current and values to change these to PWM pulses. They need calibration because they are tuned to the particular resistors in each charger.

Currently I read the resistors and calculate the values then program the charger. Power it up and measure the output to what the charger is spitting out the serial port and then tweet the numbers and try again and iterate till it reads the same.

These things are sensitive so if you are off very much it won't even turn on it gets stuck in a loop somewhere. So it tedious if you loose this EEPROM info.


----------



## dcb (Dec 5, 2009)

Sorry for my ignorance here, does one need the can "option" in order to use can control of volts/current, or can it be done directly via the 8051 uart?


----------



## Coulomb (Apr 22, 2009)

pdove said:


> ... then tweak the numbers and try again and iterate till it reads the same. ... So it tedious if you lose this EEPROM info.


As mentioned, there is nothing in the normal firmware to aid with calibration. However, I did find some leaked source code for firmware with the word "adjust" in the file name. These appear to assume a precision or at least strong power supply capable of absorbing all (or a good chunk of) rated charger current (per charger unit, so you "only" need a 2 kW supply/load for a 4 kW charger that has two 2 kW units paralleled).

I suppose that we could build such equipment and use their special firmware, then replace with final (charging) firmware. But it seems more convenient to roll our own, where there doesn't need to be a precision source, just a suitable battery, and measurements from a decent multimeter could be typed in. It would process these, perhaps do some iteration, and when ready would program the EEPROM automatically. It could also spit out some data used to print a record of what was programmed.

That calibrator is on the list of things to do.

Calibrating is necessary in the case where the processor is damaged, so the original EEPROM values can't be read. It's not a completely unheard of type of fault, and Paul has successfully revived more than one charger this way (well done, Paul). Interestingly, Elcon in Sacramento won't even attempt to repair a charger where the processor is dead.


----------



## Coulomb (Apr 22, 2009)

*Re: Elcon/TC Charger Firmware: Discussion*



dcb said:


> Sorry for my ignorance here, does one need the can "option" in order to use can control of volts/current, or can it be done directly via the 8051 uart?


The CAN "option" (in the sense of that external box that connects to CAN at one end and the 7-pin round connector at the other) is not necessary, and in fact it's a bit useless (or was, I don't know if they've improved it lately). The problem is that it converts to 2400 bps serial, and doesn't have an enormous buffer in it, so it's easily overwhelmed by CAN traffic. More than about 2 frames per second can cause overflows. So you have to have a dedicated CAN bus just for the charger. For most people, this is inconvenient.

Certainly, you can use an ordinary charger (whether it came with the CAN firmware or not), and use firmware that accepts voltage and current settings over the serial BUS. You can even use slave firmware; the slave does exactly that. The CAN firmware is a little different to the slave firmware, e.g. it drives the 3-color LED and I think it does some work with temperature measurements. (With the slave firmware, these are expected to be done by the master).

So you can make a simple serial interface, and connect it to some small computer in your vehicle. Remember, it's not RS232, but it is standard serial protocol. They run at 2400 bps, so they can use the cheapest, slowest opto couplers (that's my theory, anyway). 2400 bps is adequate.

We haven't done much with the serial controlled versions so far. But we do have firmware for them.


----------



## Coulomb (Apr 22, 2009)

*Re: Elcon/TC Charger Firmware: Discussion*

I forgot to mention that with an Elcon/TC charger with original CAN firmware, you don't need the CAN "dongle" that they supply. The dongle literally just translates CAN packets of a particular format into 2400 bps serial data in a particular format. From memory, it's a very simple 12-byte format, with the first 4 bytes being a particular extended CAN id. The voltage and current settings are in an integer format using tenths of a volt and tenths of an ampere. There is one bit in one byte that turns on and off the output relay (but for turning on it checks to make sure the battery isn't reversed or very low in voltage, the usual thing).

So even if you choose not to change the firmware (and it's a non trivial exercise to do that), you can still talk to the "CAN" firmware (really it's 2400 bps serial firmware) through a simple serial interface. I think I saw a BMS system that would talk to an Elcon/TC charger serially, without needing the CAN dongle.


----------



## dcb (Dec 5, 2009)

wow, so a 2400 baud protocol, slave firmware available, saw the arduino programmer on the facts thread... It will tell you the volts/amps/temp? and all you do is tell it what to do next?

if you please, a few more questions:
1. is the slave firmware model specific. i.e. pfc-1500, pfc-2500, etc.

2. with a microcontroller master, can it manage the calibration instead of eprom fun?

3. each model has specific voltage/amp ratings, I am thinking there are different components involved, but by any chance are they universal? i.e. can a 48v charger make 240v (assuming you limit the current) with slave firmware?

4. how does one obtain said firmware (and details on slave control)?

Thanks kindly, and nice work!


----------



## pdove (Jan 9, 2012)

dcb said:


> wow, so a 2400 baud protocol, slave firmware available, saw the arduino programmer on the facts thread... It will tell you the volts/amps/temp? and all you do is tell it what to do next?


The slave firmware is in all the dual chargers. 3kw, 4kw, 5kw etc.
These chargers have two halves or two 1.5kw chargers bolted together in the 3kw instance with slave firmware in one and master in the other.
The slave firmware does not put data out the serial bus only the master. 
However, Mike modified it to output this info for one that I programmed for someone and he put it in the master half of the charger and used a PC to command voltage and current.



dcb said:


> 2. with a microcontroller master, can it manage the calibration instead of eprom fun?


Not sure what you mean.



dcb said:


> 3. each model has specific voltage/amp ratings, I am thinking there are different components involved, but by any chance are they universal? i.e. can a 48v charger make 240v (assuming you limit the current) with slave firmware?


The voltage is hardware specific

Mike will have to give details on the slave code.


----------



## dcb (Dec 5, 2009)

thanks for clarifying, it may be a moot point though since you don't see to many second hand 1500-2500w units that can handle a 240v nominal. And new means don't forget the can interface and bump up the voltage. But if I knew where to find a bargain on a used one I'd love to experiment w/it.

edit, looks like canbus adds $100+, did I read something about analog bms control? Any info on that?


----------



## pdove (Jan 9, 2012)

dcb said:


> thanks for clarifying, it may be a moot point though since you don't see to many second hand 1500-2500w units that can handle a 240v nominal. And new means don't forget the can interface and bump up the voltage. But if I knew where to find a bargain on a used one I'd love to experiment w/it.
> 
> edit, looks like canbus adds $100+, did I read something about analog bms control? Any info on that?


The high voltage units don't put out much current

Can code can be put in any of them.

Only two ways to control them current and voltage with the can model or e
The enable pin on the front connector with the no can version.

I think Mike was talking about the elithion BMS.
http://lithiumate.elithion.com/php/elcon.php


----------



## Coulomb (Apr 22, 2009)

dcb said:


> It will tell you the volts/amps/temp? and all you do is tell it what to do next?


I'm quite rusty on the slave firmware. I think by default it doesn't put any info on the serial port, as Paul stated, but it's easy (if you are modifying firmware anyway) to make it emit the same data that a master does. Usually this makes no sense, as the master is already outputting this info. So this would be only for "stand alone slave" firmware.



> 1. is the slave firmware model specific. i.e. pfc-1500, pfc-2500, etc.


I had a quick look, and the first one I looked at had a lot of voltage/current/power specific code in it. But that was for if the EEPROM doesn't have an expected value, but that value is there for every charger we've ever examined. So that part is never called.

But it's probably like the master code; they could have written it to be completely model independent (reading anything model specific from the EEPROM values), but they haven't. In our "canonical" firmware (just one of the Lithium-based ones that looked recent), we've been modifying it to be model independent. We think we've achieved that, or maybe there are one or two places left that aren't quite independent. But it works well enough to run a 96 V nominal charger (originally a 144 V nominal, from memory).



> 2. with a microcontroller master, can it manage the calibration instead of eprom fun?


No, the masters don't have any capability for calibration. The normal charger software uses about 7.7 kiB of the 8 kiB flash memory, so there is no room for anything special.



> 3. each model has specific voltage/amp ratings, I am thinking there are different components involved, but by any chance are they universal?


Most of the charger components are model independent. The things that affect the output voltage and current are
1) The high voltage transformer. It usually has something like "144 V 14:8" written on it, meaning 144 V nominal (some 190 V max), and a turns ratio of 14:8. So it outputs some 8/14ths of the voltage at the output of the PFC stage. If you work on 330 V at the DC bus, multiplying by the turns ratio (8/14) will get you close to the max voltage. For this ratio, 330 x 8/14 = 189 V. Of course, as the ratio increases (more voltage), the current decreases.
2) The MOSFETs may change, though we've often found the same or similar ones in widely different voltage models.
3) The output rectifiers may change. In particular, the very high voltage models (say 300+ volts) have two output windings, each with their own rectifiers, which are put in series. I believe that this is because it's difficult to get fast rectifiers that handle high voltage. For example, I've seen "300 V 13:8:8" written on a transformer. This one puts out 417 V maximum. So it's really a 13:16 transformer (step up, not step down), with the secondary split into two windings.
4) The 1500 W and 2000+W models are similar too. In the larger models, the 12 V transformer may be bigger, the PFC inductor is larger and is placed horizontally, and there are three capacitors instead of two in the PFC area. The back ends are much the same, possibly identical. Of course, due to the larger current capability for a given voltage, the current-reading shunt (R20) will have a different resistance.
Edit 2016/Mar:
Actually, the PFC inductor looks superficially to be the same size on 1.5 kW and 2.0 kW models, just horizontal and heat sunk on the 2.0 kW models.
5) The top ends of the voltage dividers (R20 and R10) are model-voltage dependent, and are calibrated in EEPROM. The DC side rectifiers (D1/D4/D5/D6) can vary with model-current. The snubber resistors (R33 and R4) have been observed to vary between models. 
The capacitance and voltage rating of the three electrolytic capacitors on the DC side (near the output relay) are model-voltage dependent. The large inductor on the DC side (near these three capacitors) seems to have varying number of turns, and may have different core composition. It is marked with the power and nominal voltage of the charger, indicating that it probably changes with these parameters. There may be other differences.



> i.e. can a 48v charger make 240v (assuming you limit the current) with slave firmware?


This would require a "transformer transplant". Someone has tried this, and I can't remember what the result was. I think it worked. [ Edit: that would be Vectrix150V in this post. Thanks for chiming in, Vectrix150V. ] 

Once the hardware is modified for the different voltage/current, it would not matter if it's a master or slave or CAN version (assuming that you change the firmware to suit, of course). If it's a slave or CAN model, there is a slim chance that you could get away with keeping the original firmware. The problem is how they haven't strictly used the EEPROM data everywhere. You'd think it would be in their interest to keep the number of firmwares down, but they seem to treat nearly every customer as a unique build. All the "curves" are in the master firmware, so that makes almost every firmware unique to start with.



> 4. how does one obtain said firmware (and details on slave control)?


You either wait patiently for me to post it (coming soon!), or if you are in a hurry, PM one of us (Coulomb, PDove, or KennyBobby). We don't intend to sit on this; it's just I've been busy on other things lately.


----------



## Vectrix150V (Dec 13, 2013)

Yeah I swapped the transformer with success (ie. it still worked afterwards).

Slave firmware is interesting, I did a lot of PIC microprocessor coding years ago to talk to GSM Modems via serial, wouldn't be too hard to make up a simple programmer that you can just have connected all the time.

Arduino would work as well, but I haven't had time to play with these yet. This would probably appeal a bit more as you don't need to make PCB's etc. due to the availability of prefabricated boards.


----------



## z_power (Dec 17, 2011)

I'll ask this question here since firmware gurus are probably subscribed to this thread  

Can you describe the algorithm for calculation of checksum byte in data spit out serial port by master, non-CAN board (the last one in 79B data frame)? I'm looking for elegant way of validation of received frames. I'd be grateful for math description or posting part of charger's FW code responsible for generating this checksum.

Mike


----------



## Coulomb (Apr 22, 2009)

z_power said:


> I'll ask this question here since firmware gurus are probably subscribed to this thread


Very likely 



> Can you describe the algorithm for calculation of checksum byte in data spit out serial port by master, non-CAN board (the last one in 79B data frame)?


Yes, I can.

All the serial data packets are the same. The checksum is a straight xor. The packets start with FF FE; these two bytes are *not* part of the checksum. Then there is a comms descriptor, like F0 for the "listen" data. This is the first part of the checksum. You can start with the checksum initialized to zero and use this as the first byte, or equivalently initialize the checksum variable to the descriptor (since 0 xor X = X). Then there is a length byte, in this case 74 (there are 5 bytes of overhead; the FF FE at the start, the comms descriptor, the length, and the checksum itself). The length is also part of the checksum calculation.

Next comes the actual data, in this case 74 bytes of it. Just xor the checksum variable with each byte of data. At the end of this, the checksum should equal the last byte, the checksum. Alternatively, include the checksum in the checksum calculation and you should end up with zero (since X xor X = 0).

In pseudo code; lets suppose you have the packet in an array called data[]. So data[0] = FF, data[1] = FE, data[2] = descriptor (F0), data[3] = 74 decimal (length), and so on.


```
byte sum = 0;
for i=2; i < 74+5; ++i {
   sum ^= data[i];
}

if (sum != 0) {
  printf("Checksum error!\n");
  ...
}
```
The ^ is C's xor operator; in other languages, you might write something like sum := xor(sum, data_) .

I hope I have the indices right. You want to include all the data (indices 0-78) except the first two._


----------



## z_power (Dec 17, 2011)

Your explanation makes it look quite simple  
It's not critical to catch every single frame in my application (simple controller for limiting power and switching off charging at given U/I combination); I could for example use averaging values from a few seconds but to make use of checksum is more elegant way and adds some redundancy.

Thanks very much!


----------



## kennybobby (Aug 10, 2012)

Check out the Facts thread for some great firmware reveals--Mike has updated it and spilled the beans... He has done some excellent work, as usual!


----------



## ErvB (May 13, 2016)

Greetings! Coulomb suggested that this might be the proper place to ask the following question:

I have a 6kw TCCH charger that had blown a fuse in the master section output. It appeared to be a cold solder joint at base connection. I replaced it and it now works. However, in the event that the master fails, how difficult and what would the steps be to use the remaining two sections as a 4kw charger? Thanks!


----------



## Coulomb (Apr 22, 2009)

I'll copy my response here for completeness.

The last one must have been the master. With a triple charger, there would be one master and two slaves. I haven't looked at that part of the code for a while, but from memory, the master knows how many total chargers there should be, so for example it divides the total current by 3 if there should be 3. So you'd have to change that constant to 2 for a 4 kW (2 x 2 kW units) charger. So I guess this belongs on the Firmware discussion thread:
http://www.diyelectriccar.com/forums...on-134233.html

Now that I think about it, the difference may be in the EEPROM, not the main flash code. Of course, if it is your master that died, then one of the slaves would have to turn into a master.

The short answer is: it can be done, but it would be a fair bit of work.

Addendum: I've found a free 8051 assembler, so I may be able to make the firmware update process a lot easier. However, there are a few problems:
* The source code has to be in one file, no linking. But it has $include so that's not a big problem.
* All expressions are done in 16 bits. So even though it has macros, it looks like it will be a royal pain to handle floating point constants. I do have a few ideas, but it may take some time and it certainly won't be pretty.
* I've run into a "segment exceeds bounds" problem that has me temporarily stuck. Hopefully I'll think of a workarond and get back to it soon.


----------



## pdove (Jan 9, 2012)

Coulomb said:


> Addendum: I've found a free 8051 assembler, so I may be able to make the firmware update process a lot easier. However, there are a few problems:
> * The source code has to be in one file, no linking. But it has $include so that's not a big problem.


Cool, I was going to go another route and convert all the assembly into c code. Maybe it is time to get going.


----------



## Coulomb (Apr 22, 2009)

pdove said:


> Cool, I was going to go another route and convert all the assembly into c code. Maybe it is time to get going.


That would be even better. But is there a free or even reasonably priced 8051 C compiler? 8051 is one of the few popular architectures not supported by GCC. Supposedly because 8051 is "register starved".

Edit: also, the four address spaces would require untidy special handling, I think.


----------



## ErvB (May 13, 2016)

Coulomb said:


> I'll copy my response here for completeness.
> 
> The last one must have been the master. With a triple charger, there would be one master and two slaves. I haven't looked at that part of the code for a while, but from memory, the master knows how many total chargers there should be, so for example it divides the total current by 3 if there should be 3. So you'd have to change that constant to 2 for a 4 kW (2 x 2 kW units) charger. So I guess this belongs on the Firmware discussion thread:
> http://www.diyelectriccar.com/forums...on-134233.html
> ...


Thanks for the efforts! My charger seems to be functioning well since the fuse repair so hopefully it will live a long life without paring it down. I have always wanted to be able to understand and repair things at the level you folks are talking about ~ but for now, I am thankful that you are all willing to assist. ErvB


----------



## Angelito (Jul 5, 2013)

Good day: 

First time diyer here. 

I just would like to ask for advise regarding my TC Charger TCCH-48-25 that I ordered from EVLITHIUM.com in china. When I tried to charge my battery pack of 16 pcs of 180ah CALB Lifepo4 for the first time, the charger will not charge. It shows Red-Green-Red flashing lights, which means "bettery overcharged". However when i checked each cell, the cells are all within the range of 3.270volts to 3.383volts each. Far from being fully, let alone over charged.. What could be the possible problem and solution to this? Is my charger defective or is there a problem with my battery pack? please help.. Thank you.


----------



## Angelito (Jul 5, 2013)

By the way, my charger does not have can bus, only the red and black thin wires for the 12 volts power source.. I coupled it to LIGOO BMS to turn on/off the charger.. I thought the problem was with the bms..However, i tried removing the BMS and I hooked up charger to 12 volts battery, still the result is the same. The indicator still blinks red-green-red..


----------



## kennybobby (Aug 10, 2012)

i think R-G-R means "no battery connected/detected".

The charger senses the voltage at the output side before engaging the output relay. It does this in order to raise the internal output voltage to match that of the connected Pack, and so that there will be no current flowing across the contacts when they are engaged.


----------



## Djgabriel2004 (Jun 19, 2016)

Hello, I’ve downloaded the Arduino sketch, but I’m getting all 0 when hitting the “r” with my custom wire.

if I disconnect one of the pins it shows all FF FF FF










Any advice?


----------



## kennybobby (Aug 10, 2012)

So you have a CAN buss version and want to convert it to a button-select-voltage version, per this request  #1 .


----------



## Djgabriel2004 (Jun 19, 2016)

Exactly, thanks for clarifying it @kennybobby.


----------

