diy solar

diy solar

Will blasts Chargery

That is an interesting approach.

Cutting AC out will not stop whatever parasitic 'idle' drain the AIO has so the battery would continue to be drained (all be it slower). If the inverter has a low power sleep mode this can be dramatically reduced but It seems like another level of defense is needed. If the user is there and the lights suddenly goes out, they can go check and take corrective action before it is a problem (manual intervention can be the next level of defense). However, if the system is in a place that is not constantly used/monitored by the user it could drain and damage the battery.
Foe an AIO (all in one) unit cutting the battery off 100% creates in my opinion a larger problem for a remote system as once its shut down for LVD there would be no cumming back until user can do a manual reset.
 
Foe an AIO (all in one) unit cutting the battery off 100% creates in my opinion a larger problem for a remote system as once its shut down for LVD there would be no cumming back until user can do a manual reset.
Yup.... That is why the tease from @Steve_S about "Bidirectional SSR" is so interesting. If it is something that can turn one direction off and leave the other direction on (and visa-versa) it would be a very interesting solution.
 
@Steve_S
Your comment about the bi-directional SSR reminded of something.

One of the things that has baffled me about the chargery, is that it seems to always require two different relays/SSRs. One for charge and one for discharge. (Is that correct?). For many cases this is good. In fact, the separate signals makes me interested in the chargery for designs I would not otherwise use it for. However, there are cases, such as an all in one, where it looks like you have to have two relays where one would be fine. Is that on the list of possible updates?

Actualy, we (Jason & I) went over several ideas including some posted through the threads and other comments and he has an idea plan for a new bit of electronics like an opti-coupler / combiner that can work in conjunction with the delay board as well. From what I know, I can say, it will likely be an additional mini-board like the Delay Board. Essentially being able to control One Relay but still get the functionality. That is still percolating but will likely come about fairly quickly I think.

Sorry, but I am not at liberty to disclose too much because it's all a WIP and what actually comes out at the end of the dev & test process may be different. I do have to say again, I am pretty excited at what Jason shared for the plans & goals of the next batch of projects.

I also want to give a semi-Heads Up on the Bi-Di SSR's. These are serious pieces of kit... NOTHING like the 500A / 1000A SSRS developed by LieChuanTec ones noted above. The pricing will reflect that too of course I was fortunate enough to get a photo's of one of the test ones and all I can say is WOW. Let's just say that IF the package will say 500A it will more than likely handle 500A without breaking a sweat.
 
To ensure I am following, is the use case for a Bi-Di SSR to isolate the battery pack via a "Di" directional LVD event, and enable normal "Bi-Di" for charge/discharge?

Thanks in advance for clarifiying...
 
A simple solution for people wanting to simulate common port would be to put the contacts of a small N/O relay from one of the outputs in series with the other output .... to drive the coil of the main relay.... if that makes sense the way I worded it.
 
My preference is to avoid relays and SSRs all together. Moving forward I will be trying to use direct control of charge and discharge devices if I can.

Unfortunately, in mobile systems that typically have a lot of diverse charge and discharge devices, it can get difficult to control them all. Mobile systems might end up being situation of putting direct control on devices that make sense (Particularly the Inverter) and then have a couple of SSRs/Relays for the smaller load/charge current from everything else.

Too bad the industry has not gotten together to adopt a common, simple signalling method for this. Imagine a system where any BMS could pull down a normally high signal to say "Stop Charging" and all charge devices hooked to it stop. A second signal could be used to say stop 'discharging. A 'stop discharge' signal would probably be harder to get all of your DC loads to cooperate on, but if all of your inverters and chargers could use the signals an SSR or relay could be used for the rest of the loads.
 
Actualy, we (Jason & I) went over several ideas including some posted through the threads and other comments and he has an idea plan for a new bit of electronics like an opti-coupler / combiner that can work in conjunction with the delay board as well. From what I know, I can say, it will likely be an additional mini-board like the Delay Board. Essentially being able to control One Relay but still get the functionality. That is still percolating but will likely come about fairly quickly I think.

Sorry, but I am not at liberty to disclose too much because it's all a WIP and what actually comes out at the end of the dev & test process may be different. I do have to say again, I am pretty excited at what Jason shared for the plans & goals of the next batch of projects.

I also want to give a semi-Heads Up on the Bi-Di SSR's. These are serious pieces of kit... NOTHING like the 500A / 1000A SSRS developed by LieChuanTec ones noted above. The pricing will reflect that too of course I was fortunate enough to get a photo's of one of the test ones and all I can say is WOW. Let's just say that IF the package will say 500A it will more than likely handle 500A without breaking a sweat.
Damn Steve!!! You are a worse tease than some of the woman I have dated!!! :ROFLMAO:
 
Really and ALL WITHOUT A BIKINI ! You wouldn't wanna see that ! Ewwww....

BTW: I read the comments and there is something that everyone seems to scoot right by....
Seems like everyone thinks of ONE Battery Pack. But One Pack makes not a Bank of Packs. So if ONE decides it is Full Charge or Too Low and disconnects the other packs may not be in that state. So if you have more than one pack and subsequently more than one BMS sending signals WHO is Arbitrating that ? If all packs say Disconnect due to LVD ok, but what if it's only one or two packs ?

Now the one way I can see that resolved, is to use something like a Raspberry Pi that takes in all signals from the different BMS' and then directs what action should be taken. The hardware is available to do that with a Raspi or similar but it would need a bit of coding to accomplish it.

Case in point, I have 4 LFP Packs and I am using common Port / Common Bus topology.
 
A simple solution for people wanting to simulate common port would be to put the contacts of a small N/O relay from one of the outputs in series with the other output .... to drive the coil of the main relay.... if that makes sense the way I worded it.
Yup, I have considered that in the past as well. It effectively creates an "and" circut of the two signals. If you used SSRs for the two relays the load from them could be pretty small.

1588975496419.png
 
Yup, I have considered that in the past as well. It effectively creates an "and" circut of the two signals. If you used SSRs for the two relays the load from them could be pretty small.

View attachment 12827
I don't even think you would need the 2nd relay ...... just pass the one Chargery output thru the relay controlled by the other.
 
Really and ALL WITHOUT A BIKINI ! You wouldn't wanna see that ! Ewwww....

BTW: I read the comments and there is something that everyone seems to scoot right by....
Seems like everyone thinks of ONE Battery Pack. But One Pack makes not a Bank of Packs. So if ONE decides it is Full Charge or Too Low and disconnects the other packs may not be in that state. So if you have more than one pack and subsequently more than one BMS sending signals WHO is Arbitrating that ? If all packs say Disconnect due to LVD ok, but what if it's only one or two packs ?

Now the one way I can see that resolved, is to use something like a Raspberry Pi that takes in all signals from the different BMS' and then directs what action should be taken. The hardware is available to do that with a Raspi or similar but it would need a bit of coding to accomplish it.

Case in point, I have 4 LFP Packs and I am using common Port / Common Bus topology.
Good point. Particularly if you packs are not all similar in capacity. All of my builds are simpler than that.
 
Too bad the industry has not gotten together to adopt a common, simple signalling method for this. Imagine a system where any BMS could pull down a normally high signal to say "Stop Charging"
I thought Canbus would do that and when I read in the specs that the Skybox inverter could do Canbus I thought that was great because my BMS does Canbus.
Then when trying to implement it I realized it was not so simple. I would have had to have Outback and Orion collaborate and develope and common language or protocol. I am not sure I have the correct terms but apparently there is no common language so Stop Charging might be "stopcharge", "stopcharging", "stop_charging" or anything else that the two vendors might agree upon.

Someday the market might be big enough for some group to develop a standard for charge controller/Inverter to BMS communications.
 
Many Tier-1 product is capable of CANbus or ModBus for communications and interactions.

I am using ModBus via IP to interact with the Midnite Classic SCC and the Samlex EVO Inverter.
Before anyone asks. The Samlex ModBus protocol stack info is restricted and not public. I have it as a developer who signed NDA's to get the stuff, so I cannot share the Samlex Info nor the code for that. sorry folks.
I am using a Raspi 3B+ (gonna have to upgrade to a 4B= with 4GB) running Raspian, Node-Red with the ModBus, Grafana and InfluxDB. I will have to get around to coding an arbitrator / watchdog for the Chargery BMS'.
 
Many Tier-1 product is capable of CANbus or ModBus for communications and interactions.

I am using ModBus via IP to interact with the Midnite Classic SCC and the Samlex EVO Inverter.
Before anyone asks. The Samlex ModBus protocol stack info is restricted and not public. I have it as a developer who signed NDA's to get the stuff, so I cannot share the Samlex Info nor the code for that. sorry folks.
I am using a Raspi 3B+ (gonna have to upgrade to a 4B= with 4GB) running Raspian, Node-Red with the ModBus, Grafana and InfluxDB. I will have to get around to coding an arbitrator / watchdog for the Chargery BMS'.
You kinda prove @ampsters point. They all use different higher level protocols so to get them to talk you have to have some kind of translation intermediary.
 
When I worked in the control industry, we would put a sniffer on the competitions comm line and then build a driver into our equipment to simulate their stuff .... it was legit as long as you discovered their communications that way.
I REALLY used to hate those kind of integrations .... but they worked.
 
I thought Canbus would do that and when I read in the specs that the Skybox inverter could do Canbus I thought that was great because my BMS does Canbus.
Then when trying to implement it I realized it was not so simple. I would have had to have Outback and Orion collaborate and develope and common language or protocol. I am not sure I have the correct terms but apparently there is no common language so Stop Charging might be "stopcharge", "stopcharging", "stop_charging" or anything else that the two vendors might agree upon.

Someday the market might be big enough for some group to develop a standard for charge controller/Inverter to BMS communications.
Here is an interesting thing I found in the forum resource section: The RV industry is defining a standard for CAN bus in RVs. It is a start that could lead to some interoperability.... if they define it well enough and vendors actually use it.

https://diysolarforum.com/resources/rv-industry-association-rv-c-network-information.46/
 
Back
Top