DIY Electric Car Forums banner

1 - 20 of 118 Posts

·
Registered
Joined
·
3,141 Posts
Discussion Starter #1
I have finally gotten started on my efforts to work on a couple of these chargers that forum members have had trouble with, and sent to me to see what I might be able to do. I am still recuperating from cervical spine surgery so my mobility is a bit limited, but I have made some progress, and I will report here as I go.

Today, I removed the display and controller board, and connected it to the FTDI module, which supplies 5 VDC sufficient to light the display and it shows the default information for the uLCD-144-G2 module. But the red and green buttons do nothing.

I will say that the control board was rather difficult to remove, because it is held in by four screws, four unthreaded spacers, and four locknuts, one of which was almost impossible to reach with long pliers. I also had to bend the front panel somewhat so the board could be removed, and one connector (12 VDC to the fans) came loose from the board and it is not polarized or keyed so it's not easy to figure out where it goes.

My next step was to try and use the FTDI module to read the program (sketch) already programmed in the Arduino Pro Mini. The basic Arduino IDE seems only able to erase and program a compiled sketch to the AtMega328P, although it must be able to read it in order to verify.

So I searched and found an application called AVRDude, but it is a command line interface which needs various parameters and it does not appear to support the FTDI module. I had purchased the AVR Dragon some time ago and I decided to use it. But first I had to go to www.atmel.com/avrdragon, and I had to install various support files as well as the Atmel Studio 6.2, which also required additional support files such as Visual Studio 10 and such, so now more than two hours later it is finally installed. But I still need to find out how to connect the Dragon to the Arduino...

More later.
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #2 (Edited)
Here is the Dragon:



These are the connections from the Dragon SPI programming interface to the ATMega328:



And here is the schematic of the Arduino Pro Mini:



So now I just need to make up a header to connect the Dragon to the Arduino, and I should be able to read and write the flash memory. I'm not sure if it will allow debug in ISP mode. There is apparently a "Debug Fuse" that needs to be programmed, and it can be done with the SPI connection. Then, debugging is done through the "DebugWire" interface, which uses only one signal wire (RESET) and the Vcc and GND:

http://www.atmel.com/webdoc/avrdragon/avrdragon.dw_description.html
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #5 (Edited)
Here is the overall schematic of the EMW charger in PDF format:

http://enginuitysystems.com/files/EMW/EMW_PFC_Overall.pdf

Here are images (not very clear, but you can get the idea:





I had to grit my teeth and try not to slather red ink on all the poor design choices and oddities, but this is mostly how it is actually built. There are probably some mistakes that I may have made trying to interpret the schematics, and I did not show some unused circuitry. Please have a close look and make any corrections as needed. ;)

[edit] I made some corrections, especially the Arduino Pro Mini.

[edit2] I can see a few more errors, which I will correct as I go and the files will update if you refresh the page. For one thing, the control circuitry is isolated from the power circuit, and now I see how that is done.
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #6 (Edited)
I made an adapter cable and connected the Arduino Pro Mini to the Dragon.



I was able to read the flash program memory and save it in a HEX file. However, I was unable to run the code in the debugger. I think the HEX file needs to be converted to a .COF, .D90, .ELF, .OBJ, or .DBG file. I had a difficult time converting the HEX file to BIN format so that I could see the text characters in the program code. I wound up importing the HEX file into an MPLABX project, and then looking at the program memory. Here are some snippets of display text:

Code:
                32316400      6961665F      6572756C      3164003A      .d12_fai lure:.d1             
                31702D32      6165725F      676E6964      3164003A      2-p1_rea ding:.d1             
                32702D32      6165725F      676E6964      3264003A      2-p2_rea ding:.d2             
                61665F30      72756C69      74003A65      6C61746F      0_failur e:.total             
                5F6F695F      6C696166      73657275      7276003A      _io_fail ures:.vr             
                665F6665      756C6961      003A6572      66657276      ef_failu re:.vref             
                6165725F      676E6964      0064003A      000F000E      _reading :.d.....
Code:
                91F49005      94092DE0      CFFF94F8      66657276      .....-.. ....vref             
                74756F20      65646973      6D696C20      00737469       outside  limits.             
                66657276      736E6920      20656469      696D696C      vref ins ide limi             
                50007374      20747261      3D410031      42202C30      ts.Part  1.A=0, B             
                4100313D      30324344      003A003A      74726150      =1.ADC20 :.:.Part             
                41003220      202C313D      00303D42      6C696166       2.A=1,  B=0.fail             
                3A657275      0E006400      10000F00      03001200      ure:.d.. ........
I thought there would be more display text, but I don't really know if this code even works. It is what I found in the charger I got from JKN.

[edit] BTW, I found out that the Dragon will not work with the Arduino in the target. Some of the critical lines are connected to circuitry that loads them down, while others are unused. Obviously the design was not done with the intent of using a professional ICSP debug/programming tool. The FTDI seems not as versatile.

Mostly, D13-SCK is used for BMSIN, D12-MISO is used for EOCOUT. D11-MOSI and RST- seem unused.
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #7
Here is the display with the original code as I received it and saved above:



I compiled and uploaded the sketch for 2013_07_31_V12 using Arduino 1.0.6 and I got the following displays:









 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #8
If anyone has the Arduino code in Intel Hex format, I have made a simple Hex2Bin program that displays the hex file and also the corresponding text, which may help identify the version (which may or may not be included in the sketch, but should be). Here is a screen shot:



If you would like to use this application, it is available for download here:

http://enginuitysystems.com/files/EMW/Hex2Bin.exe

The use of the AVR Dragon to extract the code from the Arduino is explained above.
 

·
Registered
Joined
·
2,170 Posts
fyi, should be able to extract the bin without a dragon, just usb and bootloader (i.e. for an UNO):
avrdude -F -v -pm328p -cstk500v1 -P/dev/ttyUSB0 -b19200 -D -Uflash:r:program.bin:r
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #10
I see that the : p translates to a stick-out-tongue emoticon in the command line you show above. Yes, I found similar information, and also some other command-line utilities that might translate Intel hex to binary, but I wanted a more convenient Windows-based GUI to do that. Here is info:

http://www.evilmadscientist.com/2011/avr-basics-reading-and-writing-flash-contents/

It should be simple enough to write a shell program that essentially generates the command line and then reads and displays the contents of the generated BIN or HEX file. Here is the documentation for the AVRdude:

http://www.nongnu.org/avrdude/user-manual/avrdude_4.html

I was unable to determine the programmer to use, which you show to be stk500v1, or Atmel STK500 Version 1.x firmware. I don't know where you got that? I thought it should be FTDI, which may be:

Code:
avrftdi          FT2232D based generic programmer
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #11
It is now time to do some testing of the charger. I first made a copy of the working V13 firmware as a starting point, and when I started the Arduino IDE it asked me to upgrade from 1.0.6 to 1.6.4. So I did, and I even contributed $5 to the project. However, when I tried to compile it, it didn't find the "MemoryFree.h" file. When I commented it out, it did not throw an error, but seemed to hang up on the compile.

I tried a simple "Test.ino" sketch, and it compiled OK, but when I tried to upload it, there were error messages from avrdude about being unable to sync. So I went back to 1.0.6 and all seems good.

I added the following code as a way to explore the means to write to the display:

Code:
  prog_char msg_lcd_15[] PROGMEM = "P S Tech Test 1";

 
 int x = 0;
    
  if(LCD_on) {  
    myLCD->clrScreen();
    myLCD->setOpacity(1);
  } else {
    state=STATE_DONE; // skip config altogether if no LCD
  }    
  
  printConstStr(0, 0, 2, 0x1f, 0x3f, 0x00, MSG_PSTECH);
   while(1)
{
  sprintf(str, "count = %d", x); myLCD->printStr(0, 8, 2, 0, 0, 0x1f, str);
  x++;
  delay(100);
}
I had some problems with the display showing the text incorrectly or in the wrong position, and I also had problems with the programmer not being in sync. This may have been because the display and backlight is being driven from the USB port and may be too much load. It worked better when I turned off the display with the ON/OFF switch on the charger. But it would come back up in random condition. The only reliable way to get a good reset of the display and proper operation seemed to be to break the USB connection.
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #12 (Edited)
I was able to add some code to read the mv_in (Mains Voltage IN) pin, and show the value on the display with various AC voltages applied to the charger input:

Code:
while(1)
    {
    fpnum = (float)analogRead(pin_mV)*5.0/1024;
    dtostrf(fpnum, 6, 2, str);
    myLCD->printStr(0, 6, 2, 0, 0, 0x1f, str);
    sprintf(str, "count = %d", x); myLCD->printStr(0, 8, 2, 0, 0, 0x1f, str);
    x++;
    delay(100); }
One thing I noticed is that the count "x" seems to update at about 300 mSec intervals, so the rest of the code takes about 200 mSec. Probably a lot of overhead in the floating point routines.









 

·
Registered
Joined
·
25 Posts
Paul,

I think the not in sync message is actually saying that it is not able to talk. Since the display and the programmer are both communicating with the Arduino via the same port they can't both be connected at the same time. That is the reason for the power switch on the display, to turn it off when programming. Then the Arduino needs to be reset when the display is re-powered to initiate the communications with the display again. I think there is some code in the beginning of the EMW sketches that is checking for the response from the display and goes into programming mode if it doesn't see a response within some time limit.

I believe the MemoryFree.h is a "standard" library file and a web search should turn it up. I don't know if it is somehow linked or limited to the older versions of Arduino or not. I'll send a zip file over so you can have it if you need it.

respectfully,
John
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #14
I saw a similar sync error with the 1.0.6 software, so you are probably right that it was a comm error and turning off the display was needed to avoid that when programming. I never know why it had an on/off switch - now I know!

The MemoryFree.h file must be part of the older framework, but actually I found that it is not even needed, nor is pgmspace.h which was in the EMW sketch. I think Valery may have had issues with running out of memory and used the functions while debugging and updating the software.

I plan to pare down the EMW_Charger_Test sketch to bare minimum so it will be stupid easy to understand and modify. It should be able to apply 120 VAC input and a 300 ohm 91W resistive load (or maybe a 12 ohm 20W resistor, or a few in parallel) so that I can conduct a series of tests that should exercise the various I/O pins and basic functions of the charger. They are:

Code:
//---------------- pin-out constants ----------------
//========== analog pins
const byte pin_C=0; // output current pin
const byte pin_bV=1; // output / battery voltage pin
const byte pin_heatSinkT=2; // charger heatsink temp - for thermal derating 
const byte pin_12Vsense=3; // implementing undervoltage protection
const byte pin_temp2=4; // 4 - spare prewired as temp input
const byte pin_mV=5; // A5 for mains voltage sense
const byte pin_mC=7; // will only work in V12 control boards (June 2013). needed only for full digital PFC control
//========== digital pins
// 0/1 reserved for serial comms with display etc
const byte pin_pwrCtrlButton=2; // this is wired to the button (used for menu step)
const byte pin_pwrCtrl2Button=3; // this is wired to the button2 (used for menu select)
const byte pin_inrelay=4; // precharges input caps - normally pin 4, in some units pin 6 running fan relay
const byte pin_outrelay=5; // protects from reverse polarity on traction battery, precharges output resistors
const byte pin_PWMpulldown=6; 
const byte pin_J1772=7; // J1772 pilot input. 1k is hardwired on V14+ pcbs so J1772 will power on on connect
const byte pin_fan=8; // fan control - this is pin4 in all kits shipped before Mar '2912
const byte pin_PWM=9; // main PWM pin
// max current reference voltage (using PWM) -  was 6 in the V13 pcb (kits shipped before March 2012)
// now moved to pin 10 so that we can use higher PWM frequency 20kHz PWM
const byte pin_maxC=10; 
// 110/220vac relay control - for non-PFC units only
// If PFC is connected, relay would never close so can be removed
// also can be left unused / unconnected if separate 110V / 220V inputs are used 
const byte pin_110relay=11; // in kits shipped before Mar 2012, this is pin 5
const byte pin_EOC=12; // end-of-charge output (see pinout diagram) - pulled low when charge is complete
// end-of-charge input from BMS. Pull low / disconnect from positive TTL signal to activate
//     (normallly will be realized via connecting NC BMS loop between this pin and EOC pin (or +5V)
const byte pin_BMS=13; 
//---------------- END PINOUTS -----------------------
=============================================
Only a few of these are actually needed. Analog inputs:

pin_C will read output current as sensed by the Hall Effect sensor

pin_bv will read output (battery) voltage by the A7520 isolated sensor

pin_heatSinkT may or may not be implemented

pin_12Vsense may or may not be implemented

pin_mV has already been discussed above

pin_mC will only work in V12 control boards (June 2013) for PFC

=============================================
Digital pins:

pin_pwrCtrlButton input for menu step button (active high)

pin_pwrCtrl2Button input for menu select button (active high)

pin_PWMpulldown output for PWM shut-down (active high)

pin_J1772 input for J1772 pilot input.

pin_PWM output for main PWM

pin_maxC output may be a PWM level to the (+) input of the comparator U7

pin_EOC output active low (end of charge)

pin_BMS input from BMS

=============================================

The 120 VAC input should provide an analog signal on pin_mv. The pin_PWM can be turned on to charge the output capacitors through toroid inductor L2 which should provide an output voltage that can be read on pin_bv. With a 300 ohm load on the output, about 0.5 amps might be detected by the Hall sensor.

The PWM pin might be set to 10% or whatever value and this should provide a current into the 12 ohm load (or multiples thereof) to get several amps.
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #15
I was unable to get any output from the charger with the PWM set as follows:

Code:
setPwmFrequency(9, 8);  // 31250/8=3906, Timer1 pins 9 & 10, 31250 Hz, divisors 1, 8, 64, 256, 1024
   while(1)
    {
    analogWrite(pin_PWM, 12); // 12/255 approx 5%
    analogWrite(pin_maxC, 128); // 128/255 approx 50%
    digitalWrite(pin_PWMpulldown, LOW); // enable PWM
I removed the driver board from the power board (just the four quick-connects), and I tried to measure the gate voltage. I got nothing. Then I tried to measure the outputs of the DC-DC converter, and I think I heard a pop, and then smelled the component getting hot. It was "toast". Here is what I was working with - spaghetti!



This is the driver board:



Fully removed, bottom side, showing excess flux and poor soldering. But it is difficult to solder (and harder to unsolder) because of the wide traces and general lack of thermal spokes:



I removed the blown DC-DC converter, which required breaking it and removing pins. I could not clear the ground pin holes. Also, I noticed that the A3120 was loose in its socket, and found that it was not an IC socket, but two female header strips. As you can see, not designed for IC pins:



I used a small drill to clear the holes, and also defluxed with alcohol and cleaned the board with detergent, hot water, and hot air:



I added 15 V zeners across the output of the DC-DC converter. It was putting out 37 VDC and the A3120 has a maximum rating of 35V:



I hooked the scope on the gate pins and here is the waveform:

 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #16 (Edited)
Here is a simulation of what I should expect with the 5% PWM duty cycle for the charger, into a 300 ohm load, with 120 VAC on the input (150 VDC):



Here it is at 50%, with a 24 VDC battery as load. It is operating as a true buck converter, drawing about 41 amps and charging with 80 amps. The inductor is running in continuous mode, from 49 amps to 120 amps peak:



For 350 VAC input, a duty cycle of 12.5% provides about 27 amps charge.



It seems like it could be difficult to implement an adequate control loop with only reading battery voltage and battery current, especially when the signals are heavily filtered. The current rises to its target value in only about 5 mSec, and the analog filtering seems OK with a TC of about 10 uSec, but it seems that the charger firmware reads the current and takes a rolling average in a loop that does lots of other things, so I feel that it could be several hundred milliseconds between readings under some circumstances, and by that time all hell can break loose! But I have not yet really gotten into the software, and what I have seen fills me with dread...
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #17 (Edited)
Time for a quick look at software (firmware), particularly the display functions, which seem to take an inordinately long time. Valery has implemented his own uLCD_144_SPE library which sends bytes to the display via the serial port and looks for an ACK in return, or else times out after about 500 mSec. Here is the EMW library:

Code:
//==================================== SCREEN FUNCTION LIBRARY ========================
//-------------- define all function members ----------    
uLCD_144_SPE::uLCD_144_SPE(int baud) {
  Serial.flush();
 
  delay(3000);
 
  Serial.begin(baud);
   // clr screen here - do NOT call function as we need to get an Ack here 
  Serial.print((char)0xFF);
  Serial.print((char)0xD7);
  isAlive_=waitAck();
}
// process color data
byte uLCD_144_SPE::getMSB(byte red, byte green, byte blue) {
  return red*8 + green/8;
}
byte uLCD_144_SPE::getLSB(byte red, byte green, byte blue) {
  return (green & 0x7)*32 + blue;
}
int uLCD_144_SPE::waitAck() {
  int x=0;  
  int z=0;
  do {
    x=Serial.read();
    delay(5);
    z++;
  } while(x!=0x06 && z<100); // wait for screen acknowledgement or 100 cycles
 
  if(x==0x06) return 1; // LCD is there
  // LCD not there
  return 0;
}
int uLCD_144_SPE::isAlive() {
  return isAlive_;
}
void uLCD_144_SPE::clrScreen() {
  Serial.print((char)0xFF);
  Serial.print((char)0xD7);
  waitAck();
}  
void uLCD_144_SPE::setYspacing(int pixels) {
  Serial.print((char)0xFF);
  Serial.print((char)0x79);
  Serial.print((char)0x00);
  Serial.print((char)pixels);
  waitAck();
}
 
void uLCD_144_SPE::setOpacity(int opacity) {
  // 0 = transparent, 1 = opaque
  Serial.print((char)0xFF);
  Serial.print((char)0x77);
  Serial.print((char)0x00);
  Serial.print((char)opacity);
  waitAck();
}
void uLCD_144_SPE::moveCursor(int col, int row) {
  Serial.print((char)0xFF);
  Serial.print((char)0xE4);
  Serial.print((char)0x00);
  Serial.print((char)row);
  Serial.print((char)0x00);
  Serial.print((char)col);
 
  waitAck();
}
void uLCD_144_SPE::setFGcolor(byte red, byte green, byte blue) {
  Serial.print((char)0xFF);
  Serial.print((char)0x7F);
  Serial.print((char)getMSB(red, green, blue));
  Serial.print((char)getLSB(red, green, blue));
 
  waitAck();
}
void uLCD_144_SPE::setFont(int font) {
  Serial.print((char)0xFF);
  Serial.print((char)0x7D);
  Serial.print((char)0x00);
  Serial.print((char)0x00);
 
  waitAck();
}
void uLCD_144_SPE::printStr(int col, int row, int font, byte red, byte green, byte blue, const char *str) {
  moveCursor(col, row);
  setFont(0);
  setFGcolor(red, green, blue);
  setYspacing(2);
 
  Serial.print((char)0x00);
  Serial.print((char)0x06);
  Serial.print(str);
  Serial.print((char)0);
  waitAck();
}
void uLCD_144_SPE::printStr(int col, int row, int font, byte red, byte green, byte blue, const prog_char *str, int type) { // has to have a different sig from the above function
  moveCursor(col, row);
  setFont(0);
  setFGcolor(red, green, blue);
  setYspacing(2);
 
  Serial.print((char)0x00);
  Serial.print((char)0x06);
  Serial.print(str);
  Serial.print((char)0);
  waitAck();
}
void uLCD_144_SPE::wrapStr(const char *s, char *sto, int lineSize, const char *prefix) {
    const char *head = s;
    int pos, lastSpace;
    pos = lastSpace = 0;
    while(head[pos]!=0) {
        int isLf = (head[pos]=='\n');
        if (isLf || pos==lineSize) {
            if (isLf || lastSpace == 0) { lastSpace = pos; } // just cut it
            if (prefix!=NULL) { sprintf(sto, "%s%s", sto, prefix); }
            while(*head!=0 && lastSpace-- > 0) { sprintf(sto, "%s%c", sto, *head++); }
            sprintf(sto, "%s\n", sto);
            if (isLf) { head++; } // jump the line feed
            while (*head!=0 && *head==' ') { head++; } // clear the leading space
            lastSpace = pos = 0;
        } else {
            if (head[pos]==' ') { lastSpace = pos; }
            pos++;
        }
    }
    printf("%s\n", head);
}
There may be a problem in the waitAck function (among others). For one thing, it continues to read the serial port expecting an ACK, and does not look for a NAK, and assumes the display is not present if the ACK is not received. This return value is used only during initialization, where the CLRSCR bytes are sent and the ACK sets the global isAlive_ variable.

I had to search for the details of the display command set, and found one document here:
http://old.4dsystems.com.au/downloads/Semiconductors/GOLDELOX-SGC/Docs/GOLDELOX-SGC-COMMANDS-SIS-rev6.pdf

The start-up sequence for the display should include a wait period of about 1 second, during which time garbage might be transmitted and should be ignored (buffer flush). Then an autobaud command should be sent, and then an ACK should be received, after which normal communication may proceed. I think the EMW sequence is incorrect - see above. It sends 0xFF and 0xD7, which I cannot find as a valid command. [edit] This is the OLD command set. See below.

Also, I don't know how long it takes between sending a command and receiving the ACK or NAK, but it may be prudent to wait 5 mSec before reading the serial port. It probably does no good to continue repetitive Serial.read() calls if the COM buffer has already been read.

The idea of turning off the power to the display to enable programming may not be the best option. The powered-down display may place a load on the TX and RX lines, and when the display is powered up after programming, there seems to be nothing in the firmware to detect this and initialize it. Much better may be to disconnect or disable the TX and RX lines and also implement a RESET on the Arduino when the display is powered up.

Of course I am not an Arduino expert so I may be wrong. I welcome comments!

[edit] It appears that the other library uLCD_144 library has the commands as shown in the Rev6 document I linked above. Here is a more recent document showing the revised command set:

https://www.parallax.com/sites/default/files/downloads/28081-Goldelox-Spe-Command-set-v1.3.pdf

I also found a command library for the Arduino that may work better than Valery's:

https://github.com/4dsystems/Goldelox-Serial-Arduino-Library
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #18 (Edited)
Another tiny but significant step. I replaced the driver board in the charger and applied a very low current limited voltage to the mains input via the 50 VA PT, probably about 40 VAC. I stepped the PWM from 0 to 12 (out of 255) and put an ammeter on the output. I was able to get up to about 3 amps although it was unsteady because of the wimpy supply. Here is the revised test code loop:

Code:
  int x = 0, inum, PWMval=0;
  float fpnum = 0.0;
  char *s = "                ";
  //******************************** TEST ******************************************
  printConstStr(0, 0, 2, 0x1f, 0x3f, 0x00, MSG_PSTECH);
  setPwmFrequency(9, 8);  // 31250/8=3906, Timer1 pins 9 & 10, 31250 Hz, divisors 1, 8, 64, 256, 1024
   while(1)
    {
    if(PWMval < 12)
      PWMval++;
    else
      PWMval = 0;
    analogWrite(pin_PWM, PWMval); // 51/255 approx 20%
    analogWrite(pin_maxC, 128); // 128/255 approx 50%
    digitalWrite(pin_PWMpulldown, LOW); // enable PWM
    inum = analogRead(pin_mV); //Read Mains voltage
    s = itoa(inum, s, 10);
    myLCD->printStr(0, 2, 2, 0, 0, 0x1f, s);
    inum = analogRead(pin_bV);  //Read battery voltage
    s = itoa(inum, s, 10);
    myLCD->printStr(0, 4, 2, 0, 0, 0x1f, s);
    inum = analogRead(pin_C);  //Read current
    s = itoa(inum, s, 10);
    myLCD->printStr(0, 6, 2, 0, 0, 0x1f, s);
    s = itoa(PWMval, s, 10);
    myLCD->printStr(0, 8, 2, 0, 0, 0x1f, s);
    x++;
    delay(2000);
    }
I took a short video of the test. Not much to see, but it is working and if you look closely you can even see the current reading change on line 6 along with the PWM value on line 8. The reading is not well formatted so 0,1,2 will appear as 02,12,22.

http://enginuitysystems.com/files/EMW/EMW_Charger_Test_2072.AVI
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #19 (Edited)
It took a while, and some serious head scratching, but I was able to get a demo for the display library to compile and run on the charger. So when I redo the software, it can have some nice graphics and decent size text:







The demo is contained in the Goldelox serial command package that is available on the 4D Systems website. Link is in a previous post above.

Figured I might as well show my logo while I'm at it:



Also added a progress bar. Should look nice to show SOC of the battery:

http://enginuitysystems.com/files/EMW/uLCD_144_SPE_Test_2078.AVI
 

·
Registered
Joined
·
3,141 Posts
Discussion Starter #20
At this point I'd like to walk through some of the EMW software. I will use V12 as that is what I was able to compile and load on the charger I am working on, which has a V12 control board and a V13 driver. They appear to be paired as shown here:


It may help that I have annotated the board layout as well as the schematics, and they will be necessary to understand the software. Here is the control PCB:


And the driver:



Actually in this post I will just point out a few items of the hardware design that I think need to be understood and modified to proceed with the software analysis and rewrite.

On the control board, the use of the comparator and the various transistors to change logic levels seems awkward and prone to failure, but it seems to work so I won't do much with it. I don't like the idea that the gate for the output PWM is turned ON via the 5 VDC supply and 330 ohm resistor R44, and is turned OFF by the activation of the shutdown signal to S6 (which is not labeled and may not be populated on many boards), and the output of the comparator U9.

Another deficiency may be the implementation of the pushbuttons with pull-down resistors of 10k and no capacitors to reduce contact bounce. Something like 10 nF capacitors can be easily added, and I think I'll do that.

A reset pushbutton may be very helpful to start up after programming and re-powering the display. It may also be useful to disconnect the TX and RX lines for programming, rather than removing power to the display. But that is minor and need not be fixed.

The driver board seems to be where much work is needed. As mentioned above, the DC-DC converters can put out more than their rated 15 VDC, which could stress the A3120 IGBT drivers. There should also be a bidirectional TVS diode across the gates, and possibly also a small capacitor to soften the drive signal and reduce high voltage transients and ringing. But it may be better to put some of these components on the power board directly on the IGBT gates.

The use of the optocoupler PC817 for mains voltage measurement has been discussed before, and really should be replaced with an A7520 or other linear isolated voltage measurement means.

There are various issues with the PFC circuit, also discussed previously, and in particular the short piece of copper wire used as a current shunt for Isen is totally inadequate. But the circuit seems to work in spite of that design flaw, so perhaps it can be ignored for now.
 
1 - 20 of 118 Posts
Top