Xantrex C40 CM meter interface to Arduino controller

Discussion in 'The Projects Forum' started by CatawbaBud, Jun 29, 2012.

  1. CatawbaBud

    Thread Starter New Member

    Jun 25, 2012
    1
    0
    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
     
  2. wtfmate

    New Member

    Dec 28, 2012
    2
    0
    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.
     
  3. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,164
    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 [​IMG]

    http://www.wind-sun.com/ForumVB/showthread.php?7396-DIY-battery-monitor-charger/page2
     
  4. wtfmate

    New Member

    Dec 28, 2012
    2
    0
    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.
     
  5. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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?
     
  6. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,164
    Maybe dak664 can answer your questions.

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

    New Member

    Aug 11, 2013
    13
    3
    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.
     
  8. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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.
     
    T3chNique likes this.
  9. Auda

    New Member

    Jan 18, 2015
    3
    1
    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
     
  10. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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?
     
  11. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,164
    Wow, this old thread is still alive with new information.
     
  12. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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.
     
  13. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,164
    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.
     
  14. Auda

    New Member

    Jan 18, 2015
    3
    1
    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
     
    slcasner likes this.
  15. Auda

    New Member

    Jan 18, 2015
    3
    1
    Have a look here http://www.waghornswood.net.nz/Manuals/Solar_power/ for the Tracer C40-C60 Assembly and Schematic drawings, also the firmware.
    If any one has other files relating to the controllers of solar in general I would like to put a copy there as well.
    Thanks Auda
     
  16. slcasner

    New Member

    Aug 11, 2013
    13
    3
    Thanks for these.
     
  17. Maxzillian

    New Member

    Apr 29, 2015
    8
    0
    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: Apr 29, 2015
  18. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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?
     
  19. slcasner

    New Member

    Aug 11, 2013
    13
    3
    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?
     
  20. Maxzillian

    New Member

    Apr 29, 2015
    8
    0
    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.
     
Loading...