Help with older Solax X1 G4 firmware (IE07 BatVoltFault)?

fox123

New member
Joined
Aug 13, 2023
Messages
7
Hi Everyone.

Thanks in advance for your help.

Short Version: Does anyone have earlier firmware for Solax X1/G4? šŸ™ Also see attached new BMS CAN recording with interesting new frames from the Triple batteries. šŸŽ

Long Version:
I am trying to integrate a new Solax X1 G4 with a HV traction battery (320-390v) using my own DIY gateway for BMS CAN communication.

I already have software that emulates the Solax Can protocol and this works perfectly on other older inverters of the same model and also on FOX ESS models too. My HV battery also works great already so no issues there.

However the G4 inverter I am setting up now is only a few weeks old and has much newer firmware (Firmware: ARM 2.03 | DSP 2.07) which seems to have changed the can protocol in some subtle way as I am now getting the dreaded IE07 BattVoltFault error about 12seconds into the "checking" phase persistently.

In lead acid mode with my HV battery it works fine so no issues with wiring etc. When in this mode (having passed the checking phase) the fault is more or less instant when switching on the BMS CAN.

I have plugged the same inverter into another known working Solax Triple battery setup (1 master 1 slave) and it works fine. I have recorded the can communication (attache) and adjusted the voltage/SoC for my HV batt and played back but still same fault.

Probably a red herring but the only weird thing is that the inverter reports a voltage as being 6v lower than the actual of the HV pack (measured by pack BMS and multimeter). Not sure why that would be. I have tried sending real voltage and voltage inverters is reading (minus 6v) on BMS CAN frames but same issue - battvoltfault.

Based on some comments on this thread about the 1877 frame I have also tried multiple version of this to make the inverter think that its connected t multiple different battery brands but same issue. I was thinking perhaps Solax are hardcoding some voltage limits for each battery type and thats why I had the fault but doesnt seem to make any difference.

So basically I think that Solax have made some subtle change to the protocol on firmware ARM 2.03 and DSP 2.07 (possibly trying to block use of 3rd party batteries)

ATTACHED: Please find attached recorded Can frames from 2023 Solax X1 G4 with 2 triple batteries. Solax certainly added several new frames 187A/B/C/D.

BatBrand TP007
BatteryM and S version 2.00
BMS Code
BAT-M 1.02
BAT-S1 2.06 50
BAT-S2 2.06 50
BAT-S3 2.04 50
BAT-S4 2.04 50

REQUEST: I was wondering if someone has an earlier version of the inverter firmware that I could flash to see if I can get this to work. I would ask Solax but I doubt they will let me downgrade like this and not even sure which previous versions to ask for?

Any help much appreciated as several days/evenings sunk into this one now.
 

Attachments

  • Solax X1 G4 with Triple Batt from startup to shutdown.zip
    10 KB · Views: 41
Last edited:
Hey Chris,
I'm wondering what are the 0x1878-0x187E meaning. I never saw their encoding.

Also, I suggest you try the generic packet

82825476,00001877,true,Rx,0,8,00,00,20,20,5B,00,02,01,
=>
82825476,00001877,true,Rx,0,8,00,00,00,00,83,00,00,00,

It solved the weird voltage stuff on my side (the inverter was therefore accepting, 1 to 8 H48050 modules.
Hope it helps.
Topaz
 
Hi Topaz - good to hear from you and that you are still active on this. :)

I did try the above 1877 frames (with 83 in byte 4) this weekend based on your code in github but this did not work either. Will try again tonight and send you a log of my setup.

Do you happen to know what ARM/DSP firmware your Solax is running where you got this to work?

The new 187A-E frames are from the Triple batteries and mostly exchanging serial numbers. Here is an updated dbc file where I decoded some of them and tweaked some of the other frames.
 

Attachments

  • Solax X1 BMS v3.zip
    1.2 KB · Views: 20
Ok great, I'll have a look at those numbers. However, I'm running latest version of firmware (arm 1.32 / dsp 1.33). And so far my voltage fits.

Also, I'm wondering, could you narrow down the voltage span for your BMS, just to try, declare something which is closer to packs of 48v LFP packs.
From my computation with my LFP packs:
- max voltage shall be nbPacks * 54 V
- min voltage shall be nbPacks * 43.5 V

Try fitting these limits for a test. It might work.
 
Also, I've noticed that you don't send the adoption request :
>solax 0x100a000 e
However, I doubt it's useful, as it turns out this ID is not matched in the firmware.
 
I've read you log in details, and spotted something odd. And that I already experienced:

Code:
....
72716509,00001871,true,Rx,0,8,01,00,01,00,00,00,00,00,
73716508,00001871,true,Rx,0,8,01,00,01,00,00,00,00,00,
74719509,00001871,true,Rx,0,8,01,00,01,00,00,00,00,00,
75719509,00001871,true,Rx,0,8,01,00,01,00,00,00,00,00,
76719508,00001871,true,Rx,0,8,01,00,01,00,00,00,00,00,
77035514,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,
                              ^     ^     ^     ^
                              maxV  minV  maxC  maxD
                             262.8V 180.0V 14A   35A
77035556,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77036477,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77036495,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77036518,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77037476,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77037494,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,

77037513,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77038476,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
                                          ^
                                          Kind
Here I would override with    00 00 00 00 83 00 00 00

77038494,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
I discard that message

77038512,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
                              ^     ^        ^ 
                              Temp  nbPacks  Contactor enabled
Here you declare 4 packs, therefore, you min/max voltage values (for LFP) shall be
maxV = 216V
minV = 174V
I would also suggest to set the byte 5 to 0x01.

77038531,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
I discard that message, the BMS takes actions on its own depending on temps

77039476,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,
                              ^     ^     ^     ^
                              curV  curA  SoC   CapacityWh
Nothing problematic spotted, the curV is in range declared with 0x1872 earlier

77039495,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,
77039513,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77040476,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77040494,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77040513,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77040531,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77041476,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,
77041494,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77041512,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
77042483,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
77042501,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
77042519,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
77042537,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,

77043476,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,
77043495,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77043513,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77044476,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77044494,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77044512,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77044538,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,
77045476,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77045494,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
77045512,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
77046476,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
77046495,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
77046513,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,

77047476,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,
77047494,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77047512,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77047531,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77048476,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77048494,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77048512,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,
77049485,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77049503,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
77049522,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
77049540,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
77050476,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
77050494,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,
77050513,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,

77051476,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77051494,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77051519,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77051538,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77052476,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77052495,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,
77052513,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77053476,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
77053494,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
77053513,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
77054476,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
77054494,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,

77054512,00001872,true,Rx,0,8,44,0A,08,07,8C,00,5E,01,
77054531,0000187E,true,Rx,0,8,00,2D,00,00,00,5F,00,00,
77055476,0000187D,true,Rx,0,8,8B,01,00,00,8B,01,00,00,
77055495,0000187C,true,Rx,0,8,00,00,00,00,00,00,00,00,
77055513,0000187B,true,Rx,0,8,00,00,00,00,00,00,00,00,
77056484,0000187A,true,Rx,0,8,01,40,00,00,00,00,00,00,
77056503,00001879,true,Rx,0,8,01,FF,02,00,03,06,00,06,
77056521,00001878,true,Rx,0,8,07,0A,00,00,F0,0D,0C,00,
77056540,00001877,true,Rx,0,8,00,00,20,20,5B,00,00,00,
77057488,00001876,true,Rx,0,8,01,00,05,0D,00,00,01,0D,
77057512,00001875,true,Rx,0,8,D8,00,04,00,00,00,21,00,
77057530,00001874,true,Rx,0,8,C2,00,B6,00,21,00,21,00,
77058476,00001873,true,Rx,0,8,57,09,00,00,5F,00,41,04,

From here, the Solax refuses the battery. It sends a suppoed disconnect request 0x05 (and later issues other supposed shutdown request 0x02).

Therefore, the problems lies in the previous packets send since the last 0x1871 received message

77119510,00001871,true,Rx,0,8,05,00,01,00,00,00,00,00,

The inverter sending 0x05/0x02 when incorrect state is detected is quite a symptom.
I hope you'll find the problem.
Topaz
 
Hi Topaz.

Thanks for the detailed analysis.

Sorry if I was not clear but that attachment is actually from a proper working setup (Solax X1 G4 with same newer firmware and 2 X triple batteries 11.5kwh total). I just thought it would be useful for the community to see what can data from newer setup looks like. You are right it's interesting not to see the announce frame. The contactor does report closed a little later.

I have tried replaying these back in raw form and even tweaking the voltage and SoC to match my higher voltage traction battery (320-380ish V). Because I am using a complete pack I have no way to reduce the voltage to specific bounds so would need to emulate a real setup with similar voltage. Maybe 7 triple packs?

From what I have seen the 1871/05 frame is a request for the BMS to send serial numbers and other id information on 1881/2 frames after the initial handshake.

I managed to get solax to send me the earlier firmware today (really surprising) which is same as you have so will try a few more times with the 83 "kind" on the 1877 frame and send a log of my attempt before I downgrade.

It must be something stupid I am missing but feels like I have tried everything logical so part of me hopes it is the newer firmware.

Thanks again for your help really appreciated.
 
Hello fox123,

I have the same project as yours : to use a CZero (Miev clone) battery on a Solax X1 G4 Inverter. I have the same software version as you (2.03 ad 2.07).

I encountered the same error as you, but I'm not sure that it was during the countdown. For the moment, I'm using the battery on a voltage between 290 and 310V and declaring these min/max values. The solution in my case is to declare 6 slave batteries. And I don't have IE7 error anymore.

If I were you, I would try to reduce the voltage range to the minimal value, and declare the good number of batteries (7). You should not encounter the ie7 error. Then you can try to increase the voltage range.

The good question after that is : is it possible to use the full votage range of a diy battery with the solax inverter (220V to 328V in my case) ?
 
Last edited:
Both of you, don't hesitate to share your CAN communication logs. I'm willing to debug that. I spent too much time in front of the x1g4 to just drop that new contraption :)
 
Hello both.

Thank you so much for your help and suggestions.

I tried it quickly this evening with 83 battery kind and no of packs 7 and to my absolute amazement it just worked!!! :)

After hours and days if hitting the same error this is such a relief and never thought.i was see the words "Normal" on the LCD.

I will do some comprehensive testing now on the influence of the limits, other battery kinds, dropping frsmes and whether the no of packs can be changed dynamically for when the battery voltage falls between a threshold of no of packs voltages. Will also shared logs.

Thanks and will report back soon.
 
I'm very happy for you because I spent 3 full days to get ride of the ie7 default. On my side, I declared a 0x52 battery type. I didn't explore the different battery types to see if the voltage ranges are different.

If you go faster than me, do not hesitate to share your findings, it will probably save me time.

@topaz : I don't have logs to share for the moment
 
Haha I'm embarrassed to say I've probably spent the same if not longer but so happy I am past that.

Annoyingly I tried 0, 1, 2, 4, 6, 8 on the number of packs randomly but never 7!

Will share more soon on my findings and thanks again.
 
Oh that's good news!
After my few errands within their firmware, I've been understanding that some sanity (really?) computations are made with given CAN values. I'm glad all that reverse helped you.
As a rule of thumb, you can compute the number of packs depending on the current battery voltage to completely fool the algorithm. I'll task myself to extract the exact conditions on my free time.
Also @solaxCzero, if you have a bit of data of your battery pack, I may be helping forging frames (also if you have no logs but some intel on what you're exchanging on the CAN, I may be of help)
BR
 
FTR expected battery kind in 0x1877[4] are:
- [0x51;0x63]
- [0x81;0x8B]
It seems like their are numerous dreadful rules related to the battery kind (in addition to number of packs and voltage bounds)
Have fun :)
 
Sometimes it happens that we are unlucky... ;o)
Thank you Topaz for you help. For the moment, I do a little pause in my ESP32 development and take advantage of my last days of vacation to dig a hole behind the house to bury my battery.
 
Some interesting findings based on dynamically changing some of the CAN values for testing:

- The Inverter does obey the Contactor flag from the BMS (1875 byte 2) and if this is not 1 it will sit in waiting and not go into "Checking" phase and if inverter already active it will go back to "waiting" if you send 0 instead of 1 and internal contactors click (presumably open). So this could be a good initial alarm control to have less wear on the battery contactors.

- The battery kind can be changed during normal operation and this will cause a BattVoltFault - presumably due to different voltage ranges.

- Seems each battery kind has a different hardcoded voltage range as with 7 as number of packs only works with 0x83 (TP201)

- Adjusting the number of packs during normal operation (from 7>6 for example) causes a BattVoltFault so seems this is being monitored constantly and not just on BMS initialisation (checking phase)

For a pack with actual voltage of 337v (21% soc) and using different Battery Kinds (1877, Byte 4)

Previously known Kinds:
- 0x50 (Blank) 6 works works - 7 does not ("About" menu has no info)
- 0x51 (BAK) 6 works
- 0x52 (REPT) 6 packs works - 5 + 7 do not
- 0x53 (SINOWATT) 6 works
- 0x54 (GOT) 3+4 works, 2, 5>10 do not work
- 0x55 (TP001) 6 works, 2>5, 7>8 do not
- 0x81 (TP200) 6 works 4/5 and 7>9 do not
- 0x82 (TP201) 6 works 4/5 and 7-9 do not
- 0x83 (TP202), 7 packs works fine and even changing it to 8 works despite being out of range (should be min 348.5v) but going lower to 6 causes battvoltfault. So it seems to prefer higher voltages than lower ones.

New Kinds Tested:
- 0x00 NA - 6 works, 0/5/7 does not
- 0x5B (TP007) 6 works 4>5 and 7>9 do not (4 was the no of packs I recorded in logs from real setup with 2 x triple batteries which reported voltage min/max of 180>262v and actual voltage of 238v at 97% SoC)

Other battery Kind ranges I checked just to see if they showed in the about menu - didnt try no of packs (sorry numbers below in Dec not HEX):
0-10 N/A
85-93: TP001>TP009
94>99: TP010 > TP015
100>128 - NA
129 - REP-T58-P1
130>139: TP201>TP210
140>160 NA

- It doesn't seem to matter too much what voltage min/max you send on frame 1872 - if the real voltage or even voltage sent on 1873 is outside of these ranges it does not impact operation worryingly. Clearly the limits on battery kind are overriding this.

- With battery at actual voltage at 342v inverter senses this at 336v (6v lower I dont know why). Min/Max set to 300v/399v:
- if I send <150v it goes back to waiting (not battvoltfault)
- if I send 151v/245v works fine
- If you send no voltage on frame 1872 then it just stays in "Waiting" mode

- Like others said before you dont seem to need the announce 0100a001 frame or even respond to the 1871 frame the inverter sends every 1000ms. I am sending all frames every 900ms at a non-synced interval and it plays fine.

- I did a little bit more investigation on the 187A-F frames which all seem to be about exchanging serial numbers and firmware version numbers of the slave batteries. I have updated what I know and severa other fixes/changes in the attached .dbc file.

Hopefully others will find this useful...
 

Attachments

  • Solax X1 BMS v3.zip
    1.4 KB · Views: 27
Your tests are wonderful, you did a thoroughly complete job on battery kind testing!

- I have the same issue with inverter sensing a lower voltage, maybe this is related to internal DC bus and sensing after diodes.

- About the equation battery kind / voltage, the relation sounds to be only a rane multiplication by the battery pack count in series.

- About the dynamic enumeration of the battery, yes, their firmware evaluate everything everytime. However, you could send 1873-187F only once. The sole message required to update is the actual soc/voltage/current within frame 1872. Also 1875 could be interesting to keep track of the contactor state. everything else could be sent only once.

- Thanks for the dbc update, I'm ashamed that I don't quite have a single doc collecting everything I learnt from the inverter reversing.

Cheers,
 
Hello to all Solax users.

I have a question for those who have a Solax inverter with two strings. Have you checked the production of each string?

On my Solax X1 G4 7500W, I notice that one of the strings produces less than the other, particularly when the sunlight is not very strong.

I swapped the strings on the inverter inputs and the problem remains the same, so I don't think the problem is with the panels.

The following graph displays the production of string 1 in green and the production of string 2 in red. Ideally, the two curves should overlap.

I am considering contacting Solax to ask their opinion, but before doing so, I would like to know if I am the only one with this problem...

Best regards
 

Attachments

  • Capture dā€™eĢcran 2024-03-03 aĢ€ 19.06.28.png
    Capture dā€™eĢcran 2024-03-03 aĢ€ 19.06.28.png
    236.7 KB · Views: 7
Back
Top