Tema: Raspberry e híbrido tipo axpert

Iniciado por Pidjey

Quizás por serial no lo hace. Así todo me parece raro que haga eso. Debería actualizar el valor sin hacer nada.

Me parece curioso esto de voltronic. Tienen un hardware decente respecto a complejidad de circuitos i tal pero luego la programacion parece hecha por un niño de 10 años.

Decente? Menudo rosario de averías hay ya entre los miembros del foro...

Iniciado por Gabriel 2018

Decente? Menudo rosario de averías hay ya entre los miembros del foro...

Pones un taller de reparaciones y te forras. Es lo que tiene ser pobre... que no te puedes permitir un "BMW". Ahora que pasa lo que pasa que se te rompe el "BMW" y la reparacion es acorde...

Iniciado por Gabriel 2018

Decente? Menudo rosario de averías hay ya entre los miembros del foro...

Decente no es lo mismo que buena. Decente es que funciona por lo menos una semana.

- - - - - - - - - - - - - - - - - - -

Lo de que la programación sea de un niño de diez años años, usen componentes falsificados i normalmente los nuevos modelos son un batiburrillo de lo que tienen me da que pensar.

Iniciado por Gabriel 2018

Decente? Menudo rosario de averías hay ya entre los miembros del foro...

Que conste que la avería que tuvo el_cobarde fue debido a que él creía que tenian protección IP54, cuando en realidad la debe tener IP20 o algo parecido.

Bromas aparte, tampoco sabemos estadísticas sobre la cantidad de incidencias sobre el número total de unidades que hay en funcionamiento entre los miembros del foro.

Iniciado por Sulfato

la avería que tuvo el_cobarde fue debido a que él creía que tenian protección IP54, cuando en realidad la debe tener IP20 o algo parecido

Muy cierto. La avería no era culpa del híbrido, era la puerta abierta cuando llovía. El agua y la electrónica no son amigas ...

Iniciado por Sulfato

tampoco sabemos estadísticas sobre la cantidad de incidencias sobre el número total de unidades que hay en funcionamiento entre los miembros del foro

Eso pienso yo también. Mi impresión es, que los equipos de "marca renombrada" se averían más o menos igual que los de Voltronic ...

Estais desviando el tema del hilo.... La barra del bar de SolarWeb esta en otro subforo.

Si los comandos por rs232 no rearman el algoritmo os dejo como se activa el bug del regulador de flotacion prematura para ponerle solucion. Los "canguros" lo han solucionado via firmware por programacion inversa desde un firmware original (desensamblador ftw).

El parametro 2 es crucial.... y por cierto si lo cambias tambien rearma el algoritmo cerrando y abriendo campos solares.

La duracion de la etapa de absorcion y paso a flotacion se calcula asi:

1.- El voltaje tiene que estar por encima del parametro 26 (Vabs) menos medio voltio
2.- La Icola tiene que estar por debajo de la quinta parte del parametro 2 menos un amperio
3.- Tiempo de cualificacion de simultaneidad de las dos anteriores: 30 segundos. Despues lo subieron a 10 minutos con firmwares recientes para paliar el bug de flotacion prematura: Chapuza al cuadrado.
Para ser mas exactos la Icola tiene que estar por debajo del maximo de dos valores: el que he dicho y 5A menos 1 amperio.

Aplicad este algoritmo a un dia movidito de nubes: flotacion prematura si o si.

Para verificar que el bug existe podeis hacer la siguiente prueba cargando desde red la bateria.
Poned el parametro 2 al maximo que de el hibrido. Poned el parametro 11 (maximos amperios desde red para cargar bateria) al minimo que os deje el hibrido. Con un firmware antiguo pasara a flotacion en 30 segundos. Con un firmware mas nuevo pasara a flotacion en 10 minutos.

Ejemplos con valores practicos:

Param 2: 140A
Param 26: 58V
Param 27: 54V
Param 11: 10A
Param 16: CUT

El hibrido pasara a flotacion cuando el voltaje sea mayor de 58 -0,5= 57,5V y la Icola este por debajo del maximo de (140/5, 5) -1, o sea max (28,5)-1 = 27A ; ambas condiciones simultaneamente durante el tiempo de cualificacion 30 segundos o 10 min dependiendo de la antiguedad del firmware.

Si lo haceis con red solo y poneis 10A en param 11 quiere decir que vais a pasar a flotacion en 30 segundos o 10 min si o si. 10A es menor que 27A.

Formas de solucionar esto sin tocar firmware ni nada: Poner un parametro 2 acorde con los amperios que va a entregar tu campo solar. Asi bajas la Icola para pasar a flotacion y estara mas tiempo en absorcion.

En el ejemplo con valores practicos lo podeis ver poniendo valores como:

Param 2: 40A
Param 26: 58V
Param 27: 54V
Param 11: 20A
Param 16: CUT

Asi pasara a flotacion cuando el voltaje sea mayor de 58 -0,5= 57,5V y la Icola este por debajo del maximo de (40/5, 5) -1, o sea max (8,5)-1 = 7A ; ambas condiciones simultaneamente durante el tiempo de cualificacion 30 segundos o 10 min dependiendo de la antiguedad del firmware.
Puede que se pegue un par de horas hasta pasar a flotacion segun lo descargada que este la bateria.

La introducion del parametro 32 (tiempo de absorcion). Si esta Aut ocurre todo lo de arriba, es similar a no tenerlo. Pero si es un numero automaticamente la Icola tiene que ser menor de 2A, lo cual es imposible de conseguir y se pone en marcha el contador decreciente de ese numero hasta llegar a cero segundos que finaliza la absorcion pase lo que pase en ese tiempo de descuento: cagada al cubo si hay nubes haciendo de las suyas.

Vaya algoritmo!!! Made in Voltronic. No es que sea malo.... es pesimo.

Iniciado por nikitto

Usando teclado + pantalla ocurre lo que bien dices. Yo mismo lo he probado en varias ocasiones. Bien que se oye como un 'clack' de algo que rearma. Ahora bien, deberíamos probar in situ los cambios usando el puerto de comunicaciones. Por lógica debería dar igual, un método que otro.
Lo suyo, como digo, ponerse delante del híbrido y mandar el comando. A ver si se oye el 'clack'.

Pues en el mio NO corta campo solar al cambiar los parametros Vflot /Vabs..... ni por comandos SW, ni a través de la botonera del equipo.... al menos en la fase bulk que es en la que esta ahora el sistema....

Lo he probado a la vez que guardaba los datos en BD y media la intensidad del campo solar con una pinza .. y no he detectado corte del campo solar

Probare cuando llegue a la fase de absorción ...(si llega hoy que es mal día)

Iniciado por Tejota

La duracion de la etapa de absorcion y paso a flotacion se calcula asi:
1.- El voltaje tiene que estar por encima del parametro 26 (Vabs) menos medio voltio
2.- La Icola tiene que estar por debajo de la quinta parte del parametro 2 menos un amperio
3.- Tiempo de cualificacion de simultaneidad de las dos anteriores: 30 segundos (FW antiguo) rsp. 10 minutos (FW nuevos)

Ojo, Tejota! Yo creo que este algoritmo fuciona bien - y que el fallo de no hacer la absorción debe ser otro ...

Ejemplo: Parámetro 2 = 60A; Parámetro 26 (Vabs) = 58.0V; SoC inicial = 70%
- Cálculos: 60A / 5 = 12A; 12A -1A = 11A; 58.0V - 0.5V = 57.5V
- Condiciones para pasar a flotación: I < 11A (Icola) y al mismo tiempo V > 57.5V, durante 30seg rsp. 10min
- En bulk empezaría con Vbat=49V y la I subiría hasta 60A; Vbat subiría poco a poco
- Al llegar a 58.0V empieza la etapa CV ("absorción") a 58.0V y reduciéndose la I poco a poco, hasta llegar a 11A ---> flotación
(hay que entender, que la etapa CV, definida por el regulador, no es exactamente lo mismo que la absorción, definida por la batería)
- Si vienen nubes y reducen la I a menos de 11A, la V caería por debajo de 57.5V y el híbrido no pasaría a flotación
- Si se reduce la I a menos de 11A por cualquier otra razón, pasaría lo mismo
- La única opción de que I<11A y V>57.5V al mismo tiempo, es que la absorción ha acabado correctamente (SoC = ~98%)

En tu ejemplo, Tejota, en el que cargas desde red con I=10A constantes, empezarías en bulk, a 49V. A medida que se carga la batería, sube el SoC y tambien la tensión de batería. Al llegar Vbat a 57.5V, el híbrido pasaría a flotación
Es cierto, que no ha habido etapa CV a 58V, pero sí ha habido absorción en CC, a 10A constantes, y la batería se ha cargada prácticamente igual (hasta el SoC 98%, aproximadamente), que si hubiese habido una etapa CV a 58V

Conclusión: El algoritmo de carga que has descrito es bueno! El fallo de los Axpert tiene que ser otro! La condición V>57.5V e I<11A al mismo tiempo se puede cumplir únicamente, si la batería está cargada casi a tope, con el SoC casi 100%

El algoritmo descrito esta sacado con una inversa del firmware. Asi lo sacaron los "canguros" y asi lo han explicado en sus foros.

La correccion que han hecho ellos me parece cuando menos sorprendente. Copio y pego en imperial language:

Charge termination conditions
For those interested in the exact new charge terminating conditions, here they are. Others can skip this somewhat complex paragraph. The battery voltage must stay at or above a threshold, and the charge current must stay at or below another threshold, for at least 30 seconds. The voltage threshold is the bulk/absorb setting (parameter 26) minus 0.5 V. The current threshold is one ampere below the maximum of two values:
1) the sum of all the Maximum Charge Current settings (parameter 02) for all paralleled machines, divided by 5 (15 [Edit: 12 in version 72.70c and later] for LiFePO₄), and
2) the number of paralleled machines multiplied by 5 amps.
The official firmware is the same except that
(a) the voltage threshold is the float setting less half a volt,
(b) the total of maximum current settings is always divided by five, and
(c) the required time is 10 minutes (72.70 and later).
When the new absorb (CV) time setting (setting 32) is set to a number (not "Aut"), the current threshold becomes 2 A per paralleled machine, which is difficult to achieve. The effect is that when setting 32 is a number, the absorb stage will usually last for that many minutes.

Example 1: There are two paralleled machines. Maximum charge current (setting 2) is 60 A on each machine, and the Lithium iron Phosphate version of the patched firmware patch is in use. The current threshold is an amp less than the maximum of ((60+60)/15, 2*5) = max(8, 10) -1 = 9 A. So the current has to read at or below 9 amps. [Edit: For version 72.70c, it has to read below ((60+60)/12, 2*5) = max(10, 10) -1 = 10 A.]

Example 2: maximum charge current (setting 2) is 40 A, and the Lead Acid version of the patched firmware is in use. There is only one machine. The current threshold is an amp less than max(40/5, 1*5) = max(8, 5) - 1 = 7 amps. So the current reading has to be 7 A or less.

The patched firmware also fixes a new bug in the case where setting 32 is a number of minutes (not "Aut"). After reaching the absorb voltage setting for 10 seconds, the official firmware doesn't care if the battery voltage goes low again, say due to low solar input. It will still count this as absorb time. We now only increment the counter representing time in the absorb phase when the voltage criterion is met (battery voltage is greater than the CV setting less half a volt).

Patched firmware version 72.70b also fixes a new bug, whereby in official firmware version 72.70 is it now *too hard* to exit absorb stage and enter the float stage. This is because they increased the "qualification time" when the battery voltage has to be above a threshold and the battery current has to be below a threshold, from 30 seconds to ten minutes. This was perhaps a misguided attempt to fix the original charge bug, which you will recall is that it was *too easy* to go to float (and it did so much too early).

Iniciado por Tejota

El algoritmo descrito esta sacado con una inversa del firmware. Asi lo sacaron los "canguros" y asi lo han explicado en sus foros ...

Yo no digo que los australianos hayan hecho algo mal, pero sí digo que el algoritmo de carga que han extraido del Axpert (ese que has descrito en tu post #131 debería funcionar correctamente !
No quiero discutir las modificaciones de firmware que han hecho los australianos; creo que lo que interesa es el firmware original
Y digo, que el algoritmo de carga original, tal como lo has descrito, debería funcionar bien! Si el Axpert pasa de absorción a flotación antes de hora, o se salta la absorción completamente, debe ser por otra causa

No necesitamos a ningún australiano, para averiguar si el algoritmo de carga original funciona; basta un poco de lógica

Me gustaría conocer tu opinión, Tejota, acerca de lo que digo en mi post #133 sobre el algoritmo de carga original ...

Yo creo que se llama miedito a nubes y sol teniendo un bus de cristal...

He cortado el hibrido esta noche para ahorrar algo del autoconsumo

Esta es la gráfica:



La secuencia hasta que deja de responder:








Esta es la gráfica con los datos que da el Hibrido... pero...... si analizo la Ibat que captura el ADS1115 del shunt veo que hay un pico de -56A justo cuando empieza a bajar el Vbus.




Vaya forma de despedirse...


...Edito... Como me dejó preocupado el pico de Ibat.... he vuelto a arrancar el hibrido ...dejándolo unos dos minutos encendido (sin carga) y lo he apagado.... esta vez no he observado pico de Ibat.... es posible que fuera la conexión del congelador..pero ha sido justo en el mismo segundo que empezó a bajar Vbus lo que, de ser esa la causa, ya es casualidad

.... lo observare en otros días para ver si se repite

Iniciado por Mleon

si analizo la Ibat que captura el ADS1115 del shunt veo que hay un pico de -56A justo cuando empieza a bajar el Vbus

Ahora que dices esto, Mleon, recuerdo que yo, cuando conmuto del híbrido a la red, a veces veo un consumo temporal de ~2kW ...

Me explico: "Conmutar a red" simplemente significa quitar el consumo de la casa del inversor (fase y neutro) y conectarlo a la red
He visto estos ~2kW tanto con el Axpert de antes como con el Infini V de ahora. Dura unos segundos y no tengo ni idea de lo que es

2000W a 48V son ~40A - a ver si es lo mismo que reportas?

Iniciado por el_cobarde

Yo no digo que los australianos hayan hecho algo mal, pero sí digo que el algoritmo de carga que han extraido del Axpert (ese que has descrito en tu post #131 debería funcionar correctamente !
No quiero discutir las modificaciones de firmware que han hecho los australianos; creo que lo que interesa es el firmware original
Y digo, que el algoritmo de carga original, tal como lo has descrito, debería funcionar bien! Si el Axpert pasa de absorción a flotación antes de hora, o se salta la absorción completamente, debe ser por otra causa

No necesitamos a ningún australiano, para averiguar si el algoritmo de carga original funciona; basta un poco de lógica

Me gustaría conocer tu opinión, Tejota, acerca de lo que digo en mi post #133 sobre el algoritmo de carga original ...

O no me he explicado bien o no lo has entendido.... en el firmware original para pasar de absorcion a flotacion, la condicion de voltaje la da el parametro 27 en vez del 26. Los "canguros" son los que han metido en el salto el parametro 26 menos medio voltio para finalizar la absorcion en vez del parametro 27 menos medio voltio que viene en el firmware original. La carga la mayoria de las veces sera incompleta con el firmware original sobre todo si hay nubes o cargas medio fuertes en el hibrido que haga que el voltaje baje a Vabs e Icola durante bulk o a mitad de absorcion.

Queda claro ahora ??

Iniciado por Tejota

en el firmware original para pasar de absorcion a flotacion, la condicion de voltaje la da el parametro 27 en vez del 26 ... Queda claro ahora ??

Sí, ahora queda claro. Efectivamente, no había captado lo del parámetro 27 - y sigo sin encontrarlo en tu post #131

El parámetro #27 es la tensión de flotación, por ejemplo 54V. Es decir, la condición para pasar de absorción a flotación en el firmware original es Vbat > 53.5V y al mismo tiempo Ibat < 11A (valores del ejemplo en mi post #133). Lógicamente, esta condición no tiene sentido y no sirve; la condición correcta es Vbat > 57.5V y al mismo tiempo Ibat < 11A

O sea, la condición correcta no es "parámetro #27 - 0.5V", como lo dice el firmware original, sino "parámetro #26 - 0.5V", como lo dice el firmware modificado por los australianos y como lo dices tú en tus posts #131 y #139

Realmente me parece increible, que Voltronic no sea capaz de corregir este bug tan evidente ...

Iniciado por el_cobarde

Sí, ahora queda claro. Efectivamente, no había captado lo del parámetro 27 - y sigo sin encontrarlo en tu post #131

El parámetro #27 es la tensión de flotación, por ejemplo 54V. Es decir, la condición para pasar de absorción a flotación en el firmware original es Vbat > 53.5V y al mismo tiempo Ibat < 11A (valores del ejemplo en mi post #133). Lógicamente, esta condición no tiene sentido y no sirve; la condición correcta es Vbat > 57.5V y al mismo tiempo Ibat < 11A

O sea, la condición correcta no es "parámetro #27 - 0.5V", como lo dice el firmware original, sino "parámetro #26 - 0.5V", como lo dice el firmware modificado por los australianos y como lo dices tú en tus posts #131 y #139

Realmente me parece increible, que Voltronic no sea capaz de corregir este bug tan evidente ...

Es que Voltronic no lo considera un bug. Nunca lo ha considerado como tal. Admite que puede haber situaciones de flotacion prematura debido a condicionantes externos pero en una carga normal sin influencias externas como nubes, cargas por encima de produccion solar el algoritmo es correcto. Y asi lo es. Los problemas de flotacion prematura en modelos Voltronic originales viene por:

1.- Mala configuracion del parametro 2. Yo aqui recomendaria siempre poner lo maximo que te de la produccion solar. Nunca poner lo maximo que permita el hibrido (solar mas red).

2.- Nubes durante la fase bulk y absorcion y/o cargas potentes en AC durante la fase bulk y absorcion que engañan al hibrido para que se den las condiciones de finalizacion de la absorcion.


La introduccion de parametro 32 (tiempo de absorcion) en algunos modelos es para paliar de alguna
manera la flotacion prematura ante factores externos. Pero si te fijas el parametro 32 es un simple contador de tiempo que una vez alcanzada la Vabs va descontando hasta llegar a cero pase lo que pase durante ese periodo..... y eso tampoco es asi ya que los factores externos van a seguir estando en ese periodo de absorcion. Lo que pasa que se mitiga un poco mas respecto a flotacion inmediata.

Aqui los canguros tambien modificaron el contador del parametro 32 haciendo que si se perdia la Vabs durante algunos minutos se reiniciaba el contador.

Iniciado por Tejota

Es que Voltronic no lo considera un bug. Nunca lo ha considerado como tal

Negarse a que eso es un bug, carece de lógica ...
Es cierto, que alargar el tiempo en el que deben coexistir las dos condiciones (de 30seg a 10min), mejora algo la situación; pero lo correcto sería usar la condición "Vabs - 0.5V", en vez de "Vflot - 0.5V"

Iniciado por Tejota

La introduccion de parametro 32 (tiempo de absorcion) ...

Lo del parámetro #32 y como lo mejoraron los australianos lo he entendido
También entiendo, que con un valor no exageradamente grande en el parámetro #2 se alivia un poco el problema


Conclusión: La flotación prematura de los Axpert se explica bien, con la condición "tonta" de {Vflot - 0.5V}

"Casualmente" los canguros disponen de un firwmare modificado que solventa estos bugs para los PF1 de 64V modelos MPPSolar PIP5048MS , Axpert 5K-48 MKS o EASUN ISolar SM5KW con firmware U1 72.20 como original.

PIP5048MS patched firmware 72.20a - Page 94 - AEVA Forums

Iniciado por Tejota

... los canguros disponen de un firwmare modificado que solventa estos bugs para los PF1 de 64V modelos MPPSolar PIP5048MS ...

Veo que este último logro de los cracks en el foro australiano es muy reciente; el post data de 31/08/2018 ...

Una grafica que muestra la diferencia de como regula el FM80 (en azul) a como regula el Hibrido (en rojo) .. estaba enchufada una olla electrica (pulsos intermitentes de consumo)



Lo peor de la respuesta del hibrido, mas que la lentitud, es que sube por encima del valor de Vabs fijado

Iniciado por Mleon

Una grafica que muestra la diferencia de como regula el FM80 (en azul) a como regula el Hibrido (en rojo) ...

Muy informativo, Mleon; gracias. Supongo que con decir "azul" y "rojo" te refieres al color de tus marcas manuales, no a las curvas. Las curvas en azul y rojo parecen ser tensión (de qué?), y la curva amarilla intensidad. Lo aclaras, por favor?

Tienes mucha razón: El Outback regula con mucha más precisión. Aunque creo que eso es de poca relevancia, en la práctica

La curva amarilla es Iplaca
La roja Ibat
La azul es Vbat

Para mi, como he comentado, lo peor es que en la regulacion del hibrido se supera la Vabs consignada

En este ejm la Vabs estaba en 28,8v y en la regulacion del hibrido sube hasta 29,2v y es posible que subiera mas pero tengo un Arduino con un rele SSR vigilando que no pase de ese valor

Sabiendo por ejm que el Vbus a 29v de bateria esta peligrosamente cerca del limite de los condensadores, me hubiera quedado mas tranquilo si no viera esas subidas de tension

Pues esas variaciones son mas que normales.
No te preocupes que los electroliticos de alta no les va a pasar nada. Mas me preocupan los electroliticos del bus de baja. Esos si que son peligrosos y aqui los "expertos" no dicen nada. Igual es que no los tienen "fichados".

El regulador del hibrido es lento pq las ordenes de ejecucion se duplican, es decir, pasan por dos procesadores:

1.- El del propio hibrido DSP U1.
2.- El del regulador solar SCC U2.

U2 no hace nada si U1 no se lo manda.

En un regulador sin inversion como es el FM80 solo tiene un procesador que se encarga de todo y por tanto es mas rapido.

Hombre no creo que sea por eso ya que hoy en dia los microcontroladores hasta el mas basico es de 48 MHz i los DSP no suelen bajar de 100 o 200 MHz. Estamos hablando de control de milisegundos. De todas formas deberia ser todo lo contrario. Cuando hay 2 procesadores uno suele ser dedicado al MPPT i el otro al control general por lo que deberia ser mucho mas rapido que con uno solo haciendo el mppt, regulacion de la bateria..... En el mppt que estoy construyendo yo uso 2 sin duda porque es mucho mas rapido. Mas que nada porque el mcu principal manda al del regulador regular a determinada tension. El mcu principal sigue trabajando mientras que el del regulador esta solo regulando.

Creo que el problema del hibrido esta mas en cuestiones de ahhorro economico en hardware que hacen el control mas lento.

- - - - - - - - - - - - - - - - - - -

A ojo el problema esta en el bajo costo de los mosfets, drivers, condensadores de entrada que obligan a una frequencuencia de control baja para evitar muchas perdidas.

Iniciado por Pidjey

Hombre no creo que sea por eso ya que hoy en dia los microcontroladores hasta el mas basico es de 48 MHz i los DSP no suelen bajar de 100 o 200 MHz. Estamos hablando de control de milisegundos. De todas formas deberia ser todo lo contrario. Cuando hay 2 procesadores uno suele ser dedicado al MPPT i el otro al control general por lo que deberia ser mucho mas rapido que con uno solo haciendo el mppt, regulacion de la bateria..... En el mppt que estoy construyendo yo uso 2 sin duda porque es mucho mas rapido. Mas que nada porque el mcu principal manda al del regulador regular a determinada tension. El mcu principal sigue trabajando mientras que el del regulador esta solo regulando.

Creo que el problema del hibrido esta mas en cuestiones de ahhorro economico en hardware que hacen el control mas lento.

O falta un buen PID, no PIDjey?