Xantrex C40 CM meter interface to Arduino controller

Thread Starter

CatawbaBud

Joined Jun 25, 2012
1
I have a camper at a remote location that uses a Xantrex C40 controller to charge (solar and wind) a 230AH battery bank. I have remote access via the internet to an Arduino controller and would like to monitor the status of the C40 getting the same information as presented on the CM meter. I read an old thread where NSASPOOK was doing something similar, but the the results were not posted.

From old thread:

"The current problem is interfacing with the XANTREX C40 controllers remote LCD display serial interface connection. It seems to be lowspeed 300 baud RS-422. They provide no help on the wiring or protocol but I have a 422 converter on order to dump the data-stream. With this data sent to the PIC I can then use the C40 charge status to switch cells instead of a timed/voltage method."

Any suggestions would be appreciated.

Buddy Helms
 

wtfmate

Joined Dec 28, 2012
2
I am also working on this, it seems noone has done this successfully (publicly) yet.

I managed to get a logic analyzer hooked into mine and get a dump out. (http://ge.tt/83BV0LU/v/0?c) if anyone is interested in trying to reverse the protocol without actually having the device hooked up.

If I make any progress, I will post back here.
 

nsaspook

Joined Aug 27, 2009
13,081
I decoded most of the data but never used it. I built my own BMS system to monitor the system status instead because the data from the C40 metering was low resolution and inaccurate. Sorry, I don't have the C40/DVM code anymore.

From:
dak664


Probably that was from an earlier post of mine on this newsgroup: http://dakx.com/aps/c40out.gif http://dakx.com/aps/batcharge.gif The modular RJ connector to the meter has power, ground, and two TTL serial outs, everywhere complementary except for the start-of-block sync. I combined them capacitively to get a single serial signal with a large sync pulse. This was fed to a Mac audio in port and decoding was done in an interrupt routine. I’ve figured out most of the bytes, they seem to be various analog signals multiplexed through an 8 bit A/D converter. For example, when you press/release the reset button it slowly discharges/charges a capacitor, and the voltage on this cap is in one of the channels. There are quite a few channels that don’t change, I’m guessing they could be temps of the switching FETs and battery temp probe (which I don’t have). Possibly these or other spare channels could be usefully appropriated to monitor some external voltages. Trace expressed willingness to provide me with the complete datastream description but so far (6 months now) has not done so.

The data format is a standard one for Optrex LCD displays. Embedded in the serial bitstream are some formatting commands (cursor control), though you can filter these out in your host program. The Optrex LCD in my C40 is a 16205LG or LY variant with some kind of private labelling.
http://www.wind-sun.com/ForumVB/showthread.php?7396-DIY-battery-monitor-charger/page2
 

wtfmate

Joined Dec 28, 2012
2
Wow, that's quite a solution. I figured I'll give it a swing since it's what I have to work with. I have ordered an rs422-rs232 converter which I believe should allow me to access the data over a more traditional serial interface with Python. I'll post more later when more work is done.
 

slcasner

Joined Aug 11, 2013
13
I've just joined this forum after finding the posts in this thread about interfacing the C40 controller remote display to a computer. I have a Trace PV system installed in 2000 with C40 controllers and have been recording daily data by hand from the remote display along with the power consumption or generation readings from the PG&E time-of-use kWh meter. Now that PG&E has finally installed a SmartMeter I have hourlly data accessible from their website, so I am finally prodded to complete my long-ago plan to collect automated generation data from the C40 meters.

Have any of you in this thread made progress?
 

nsaspook

Joined Aug 27, 2009
13,081
I've just joined this forum after finding the posts in this thread about interfacing the C40 controller remote display to a computer. I have a Trace PV system installed in 2000 with C40 controllers and have been recording daily data by hand from the remote display along with the power consumption or generation readings from the PG&E time-of-use kWh meter. Now that PG&E has finally installed a SmartMeter I have hourlly data accessible from their website, so I am finally prodded to complete my long-ago plan to collect automated generation data from the C40 meters.

Have any of you in this thread made progress?
Maybe dak664 can answer your questions.

https://www.google.com/search?q=dak...g.mozilla:en-US:unofficial&client=iceweasel-a
 

slcasner

Joined Aug 11, 2013
13
For the benefit of anyone else who might search and find this thread, I file this report.

I used my oscilloscope to examine the signals on the pins of the RJ-45 connector. Pins 1 and 6 carry pulses in sync with the LED blink, so they may be driving the LED directly. Pin 4 is ground and pin 5 is 7.5 VDC, which is regulated on-board to 5 VDC. Pins 2 and 3 carry the complementary TTL signals as described by dak664.

Following the lead of dak664, I recorded the signals (with attenuation) using the audio input of the Mac running the audacity program, essentially working like a digital oscilloscope, and then analyzed the recordings with a small C program. The bit rate is approximately 235 bps (4.25 ms/bit). During half of each bit time, both pins are low, then in the other half they carry complementary bit values. The data is in blocks of 23 8-bit values, with at least one bit time between values where both pins stay low for the whole bit time. The beginning of the block is marked by a bit where both pins are high to act as a sync pulse. I did not determine which of the two pins carries the inverted bit value since I just flipped the bit sense and the bit order until the data values looked plausible. Based on the observation that one of the channels increases in successive blocks and the drops back to zero, while another decreases to zero and then jumps up, I decided that the order of the bits in each 8-bit values is MSB first.

dak664 described the data values as analog signals multiplexed through an A/D converter, calling them channels. I made two 60-second recordings of the bit stream, one during the daytime and one at night so that I could try to infer the meaning of some of the channels based on the differences between the two recordings. Some of the values varied while others were constant, and some were similar between the two recordings while others changed. Here is what I found. The values are in decimal, with some also shown in hex in parentheses:

01 dark 170-171, light 168-171
02 dark 0, light 35-36 may be amps*2
03 132
04 dark 132, light 95-96
05 dark 0-1, light 154-158
06 153-157
07 dark 146, light 144
08 174
09 255
10 185
11 174
12 dark 173, light 130
13 dark 167-168, light 165-168
14 counts up by 3 or 4 between blocks, 0 - 227 seen
15 0
16 dark 0, light 36 may be amps*2
17 dark 0, light 128 (80)
18 0
19 11
20 mostly 2, sometimes 10 or 26 (00, 0A, 1A)
21 dark 8, light 40 (08, 28)
22 dark 146, light 18 (92, 12)
23 counts down 6 or so between blocks, 40 - 0 seen

Channels 02 and 16 are plausible for amp measurements on my solar system. The amp display always shows .0 or .5 for the fraction, so I expected to find a value in units of half-amps. Unfortunately, I can't clearly identify any of these values as representing the voltage reading, which is in the range of 52.4-53.6 on the display, always with even fractions. The closest possibilty would be channel 05 for the voltage on the solar panel side of the controller (which would be open at night) and channel 06 for the battery side. However, this would be a multiple of 3, which would be unusual, and the values are a little too small.
 

slcasner

Joined Aug 11, 2013
13
Is anyone still reading here? I have designed and built a small PC board to go inside the C40 DVM, attaching to the 1x16 header that carries the signals to the LCD module and the 2x4 header where jumpers are installed to select the battery voltage. In addition to providing physical support, these attachments pick up power and the two differential data signals described in earlier posts. Those signals are wired to two of the pins on the LCD header that are not used for the LCD itself. This board carries a PIC12F1572 microcontroller (MCU) and a MAX202 RS-232 level converter. I have written firmware for the microcontroller to parse the differential data and send it out as RS-232 serial data.

I have determined conclusively that the first two bytes of the 23-byte frame are the ones that drive the LCD volts and amps values. I did this by repurposing one of my PC boards to pick up the characters going to the LCD so I could put out both my decoded data and the LCD display data at the same time for comparison. The binary voltage value is divided by 12.867 and rounded to one decimal place to get the real voltage as displayed for a 12V system, or subsequently multiplied by 2 or 4 for a 24V or 48V system. (The DVM has jumpers to tell its MCU to do the multiplication by 2 or 4.) I suspect that the DVM does not divide but instead uses a lookup table, but the calculation I describe produces the same results as the DVM displays for voltages 12.1 - 15.5 on a 12V system or 48.4 - 62.0 for a 48V system. Note that in several cases there are two binary values that result in the same display value. The amps display is just the binary value divided by 2, except that both 0x00 and 0x01 are shown as 0.0 amps.

I believe dak664's assertion that the differential data stream includes LCD formatting commands is not correct. Some of the bytes are related to voltages, some to currents, and some appear to be control signals representing things such as the switch between on and off states. The bytes going from the DVM's MCU to the LCD module are all in a fixed repeating pattern writing to the 32 characters of the display.

I have much more information that I can provide if anyone is interested: PC board CAD file (I had mine fabricated by OSH Park, just $15 for 3 boards), firmware, photos.
 

Auda

Joined Jan 18, 2015
3
Is anyone still reading here?
Yep I am. I have been thinking about making a display for my C40 but have had many other things to do like getting the panels installed first :)
I have a couple of files you may like :
Tracer_Xantrex_C40_C60_Controller_PCB Assembly.pdf and Tracer_Xantrex_C40_C60_Controller_Schmatic.pdf

Ill have them on a website to download in about a week if you want them.

Auda
 

slcasner

Joined Aug 11, 2013
13
Auda, I just saw your post now. I had not looked for a while and apparently I'm not getting email notifications any more.

The two files you mention are for the circuit in the C40 or C60 controller itself? Yes, I would like to see them.

Are you making a display to use as an alternative to the C40 DVM that Trace/Xantrex sold?
 

slcasner

Joined Aug 11, 2013
13
Yes, when I submitted post #8 there was a warning about the thread being old, but I decided that continuing here where the old information was present made more sense than starting a new thread.
 

nsaspook

Joined Aug 27, 2009
13,081
I looked at the display information long ago but my take is that with a little extra effort you can build an external voltage/current meter for a PV system that will provide much better resolution and accuracy than the supplied data from the C40 using a uC with a few ADC inputs for the basic voltages (PV voltage, CC output voltage , battery terminal voltage, etc ...) and current sensors for charging and/or load currents.
 

Auda

Joined Jan 18, 2015
3
I'll put the files on my website later this week. I also have the firmware for the C40. Well the person I got it from said it was I haven't checked it
Not sure what I'm going to do. I may make a display or as nasaspook says build one from scratch. First off I have to get the panels on the bus roof !
Auda
 

Maxzillian

Joined Apr 29, 2015
8
Hi, new poster here, but since this thread served to help me figure out how to interface with the charger it's only fair I share the results:

https://hackaday.io/project/5167-xantrex-c35c40c60-display

You'll find there a list of parts, pictures and most importantly the source code to make a basic display for the charger using an Arduino and 2x16 LCD. Ultimately it offers roughly the same set of features as the Xantrex display, but there is a multitude of more data that isn't being used and yet more that has yet to be cracked. Enjoy!

Edit: I should note that this is only tested on a 12 volt system. Switching my C35 to 24 volts does screw with the battery voltage scale, but not the input voltage.
 
Last edited:

slcasner

Joined Aug 11, 2013
13
Thanks for posting. As I said in my post #8, I am sure that the first byte of the frame is the voltage value that the C40 DVM displays.

One interesting observation I've made since my last post was that the time interval between frames varies in a pattern that is affected by whether the C40 is in day or night mode. The minimum value of the envelope of those times has a slow variation that correlates very closely with the value in byte 7 that appears to be related to temperature. You have identified it as battery temperature. How did you determine that?
 

slcasner

Joined Aug 11, 2013
13
Sorry, make that byte 12 rather than byte 7. I had looked for correlation with 7 first, then changed to 12. You've identified this as transistor temperature. How did you determine that?
 

Maxzillian

Joined Apr 29, 2015
8
Assuming the first byte is the one that intermittently has both communication lines pulled high for the first bit, the first byte is definitely not battery voltage; although it is affected by the battery voltage by a small degree. Still, the value does randomly change every now and then.

For the transistor temp I placed my finger on the thermistor and looked for a value in the stream that was increasing. Pulling my finger away would reveal the value decrease; showing me I was on the right track. That said, it actually turned out that temperature is inverted (value drops as temp goes up) so that took a little while to notice. While I don't have a battery temperature sensor, I did put a short pigtail connector in the plug and then placed the tip of my finger across the bare leads. The resistance of the skin is low enough that a change in the reading could be observed.

Many of the voltages were determined by using one or two 9 volt batteries tied to a 10k potentiometer so the voltage could be varied. By watching the raw value in the stream and comparing to what was read on my digital volt meter I was able to determine conversion formulas in Excel. Once I got a rough idea of what was what, I hooked up a large battery charger (one that uses a transformer, not a switching circuit) and began feeding the voltage input with it. Being able to run the system in a controlled environment makes it a lot easier than trying to decrypt the stream with it on a solar panel.

Ultimately the easiest way to do all this was to first get the Arduino to produce a reliable byte stream and getting it to reliably sync on the first byte. Once that was done I configured it to dump out the values, separated by commas, to the serial terminal. When a new string of bytes was started, I used the println() function to start a new line. This stream of data can be copied and pasted into excel which will give you an option to import it using the commas as a delimiter. Once in Excel you can pick a column and graph the data to get an idea of just what it is.

Admittedly I fumbled for a few days until I realized that I had the two communications lines backwards, producing a 0 when I needed a 1 and vice versa.
 
Top