A CLASSIC PRODUCT ADDITION?
My intent here is not to step on any toes, but to be honest, forthright and constructive.
Background
My belief is that many of your Classic users may have similar problems that I have.
My system is 3200watts of PV going to a Renogy Rover 60 (MNMPPT60DIY equivalent ? ). I have 4ea 215AH 48v FLA battery banks. My "load management" is accomplished thru multiple op amps, comparators, 555 timers and relays. I have to constantly readjust things because temperature compensated set points and other variables are unavailable. I would love to do end amps(WBjr) and PWM.
I could upgrade to a Classic 150 for approx $900 self installed. I sure it would improve my reliability and charge current capacity. I presently do not totally use the PV and charge capacity of the Renogy. I have little room or location for additional paneling (also an additional expense).
One Classic would not allow me to do both end amps and PWM. The present solution would be to purchase a second Classic to accomplish this. The additional charge current would be un-used as I have no wind or hydro (another expense).
I would also like to independently monitor each of the battery banks for SOC and float current trends (battery health). I would also like to do float current adjustment of absorb time (enough but not too much).
I realize the some Classic users are employing rasberry-pi and other mini computers to accomplish what the Classic will not. This is all well and good but beyond the scope of many user's abilities.
The real world suggests that a redesign of the Classic is less than desirable. It is not broke, it just has limitations.
I would suggest a new Midnite product to attach to the modbus (unique address). It would include the following:
1) An upgraded ADC to monitor and combine up to 4 independent bank shunts with better resolution than WBjr. The increased resolution would assist in LIPO4 charging, float current discrimination and tighter setpoint and width settings. Hopefully real time current data could be supplied over modbus and free up the Classic's aux2 port.
2) A "small" mcu to process ABSORB and FlOAT commands and LOAD engage/disengage commands for # additional AUX ports. I say small because these commands take place over minutes not milliseconds. It could be called upon to generate PWM signals.
3) Minimally it would have modbus connect-ability and USB for firmware upgrades.
Open question would be where to get power for the unit.
I am sure that peeps might want to suggest other load management parameters than I have suggested. Those should be customizable thru MNGP. Having reviewed the Classics registry I believe that all necessary parameters are available and can be written too.
I hope this post has not endangered my most recent promotion to Full Member.
Open for input
Barry
Having worked for Midnite close to over 12 years now I think I can safely say the Classic line is getting close to EOL (End Of Life), I still have CL150 serial #829 on the shelf. Let's face it, it uses older design parts (Transistors aka FETs) and the Classic runs REALLY, REALLY Hot and it does not take much abuse to short out the FETs. The case is part of the heat-sink for the FETs. In my power room with no A/C I have 4 Classic 200's and it gets over 95 degrees in the summer, I know better than to put my hand on one.
Rumor time, there may be a Classic 2.0 in the design phase right now, it would make better sense to think about this stuff being done to it before the final design. (The project has a code name but I can't remember it since the engineer working on it also designed the KID I just call it "The BIG KID", unofficially of course)
Right now the Hawkes Bay 90 is the best replacement for a Classic, it uses newer technology like Silicon Carbide transistors which are more powerful and run way, way cooler. The HB90 also is a HV controller which means no more combiner box, most times all PV modules can run in one string or maybe two and more power from less losses. It also uses a better MNGP called the MNGP2 and uses CANBUS for all the communication needs. I know it costs more than a Classic but it is bigger, better and cooler. The only thing is it is 48V only. I heard rumors of maybe a 24V version some day but I'm not sure, it would need to drop down in current to keep the same terminals.
The cost is around $1250 retail:
https://www.currentconnected.com/product/midnite-solar-mnhawkes-bay-90/
Am I correct in saying that the Hawksbay also requires a higher PV input voltage? (re-config/add solar panels)
Can it perform any of the above load controls I have described above?
Does it also have the same restriction that WBjr uses one of the AUX ports?
IMHO not a clearly advantageous upgrade especially for a 12 or 24 or 36 volt user.
Could be an "capability expander" I have describe above could also be of use to a Hawksbay installation.
Quote from: Barry Fields on May 10, 2024, 02:29:03 PMAm I correct in saying that the Hawksbay also requires a higher PV input voltage? (re-config/add solar panels)
Can it perform any of the above load controls I have described above?
Does it also have the same restriction that WBjr uses one of the AUX ports?
IMHO not a clearly advantageous upgrade especially for a 12 or 24 or 36 volt user.
Could be an "capability expander" I have describe above could also be of use to a Hawksbay installation.
Hawkes Bay does need 185v lowest possible pv input and 48v battery .
I believe the PWM is available on both of it's aux at same time , and don't believe the whizbang ties up either or the aux .
Larry
Again something I do not know:
Can the existing Classic 150 be "firmwared" to do Canbus instead of modbus?
Quote from: Barry Fields on May 10, 2024, 07:14:54 PMAgain something I do not know:
Can the existing Classic 150 be "firmwared" to do Canbus instead of modbus?
I don't think the Classic has the communications hardware needed to do canbus. It is different than what the Classic modbus does via IP or over the jacks to the MNGP.
Larry
The Classic doesn't have a CAN peripheral so it wouldn't be able to do it.
It also doesn't have the CAN BUS driver chip.
Since Barry likes education I will try and explain MODBUS and CANBUS.
MODBUS uses a client-server topology. The client "asks" for data and the server, well, "serves up" the data. Let's say REQUEST & REPLY. The Classic uses 16 bit registers, think of a register as a box that holds data. 8 bits forms a "byte" so the Classic MODBUS register is 2 bytes long. Some Classic data won't "fit" in 2 bytes so we combine two registers and use 4 bytes but we need to read each register and combine them for our data. Classic lifetime KWh register comes to mind, it's 4 bytes or 32 bits. The cool thing about reading MODBUS we can select an address (MODBUS registers all have an address used to access them) and pick how many to read so for a 32 bit piece of data we can read 2 registers in one swoop, then process them into our data.
If still interested I'll explain CANBUS next...
I do indeed like edumacation. Please continue.
Just so I am clear, would the second Classic or the proposed new box be the client?
Quote from: Barry Fields on May 11, 2024, 12:32:50 PMI do indeed like edumacation. Please continue.
Just so I am clear, would the second Classic or the proposed new box be the client?
The Classic with MNGP has both a client and a server for instance.
The MNGP I guess you would say is the Client. It asks the Classic for information but can also write new values to the Classic. So the Classic would be a server in that case, I guess.
Now the Classic can also be a client and ask other modbus devices for information and change their register values so it can also be a client. That would be like when it is doing Follow-Me.
The Classic does not spit anything out over its modbus ports unless asked, except for some Follow-Me data exchanges.
Is the communication between MNGP and Classic also modbus?
Quote from: Barry Fields on May 11, 2024, 04:25:50 PMIs the communication between MNGP and Classic also modbus?
Yep.
In fact, you can plug the MNGP into the top RJ11 jack OR the middle jack. The middle jack only uses 4 out of 6 connections so the middle jack will not light up the 2 bottom LEDs on the MNGP
I will not sing it but, anything MNGP can do the new box could do better. ;D
Question?
First we need to name this potential new product. I would suggest BBMT (Barry's Better Mouse Trap). ;D
Presently the Classic has a voltage discrimination of .1 volts. TRUE?
Could it be best to include a better ADC in the NEW BBMT for more precise trigger voltages?
Can the Classic "handle" more precise set points and width voltages or should that task be better handled by the BBMT?
Humbly yours
Barry
in addition to the above questions,
Do the hawksbay and barcelona also use modbus to communicate?
Quote from: Barry Fields on May 15, 2024, 07:35:58 PMin addition to the above questions,
Do the hawksbay and barcelona also use modbus to communicate?
No, they use Canbus
Do they use something different than MNGP or just a different version of MGNP?
MNGP2 which is CAN
Completely different than the MNGP
Quote from: boB on May 16, 2024, 12:38:01 PMMNGP2 which is CAN
Completely different than the MNGP
Sooo It would make sense if we wish to use BBMT on classic 150 or Hawksbay, it should have both modbus and Can capabilities.
Quote from: Barry Fields on May 16, 2024, 12:56:19 PMQuote from: boB on May 16, 2024, 12:38:01 PMMNGP2 which is CAN
Completely different than the MNGP
Sooo It would make sense if we wish to use BBMT on classic 150 or Hawksbay, it should have both modbus and Can capabilities.
BBMT ?
Quote from: boB on May 16, 2024, 04:07:42 PMBBMT ?
from a few posts back
First we need to name this potential new product. I would suggest BBMT (Barry's Better Mouse Trap). ;D
Is my security clearance high enough to ask what MCU is used in the Hawkesbay and Barcelona ( I presume they are the same)?
More stuff I do not know:
In the Classic is the battery voltage stored in a registry as a 10bit value?
Could a more accurate 12 bit value be stored and processed?
In general if you wanted an MCU to be able to communicate with either modbus or canbus, can that be done with one bridge and one r485 connector or would you need two?
Quote from: Barry Fields on May 20, 2024, 02:37:21 PMIs my security clearance high enough to ask what MCU is used in the Hawkesbay and Barcelona ( I presume they are the same)?
They are ARM Cortex-M3 parts from NXP.
boB
Quote from: Barry Fields on May 21, 2024, 12:22:34 PMMore stuff I do not know:
In the Classic is the battery voltage stored in a registry as a 10bit value?
Could a more accurate 12 bit value be stored and processed?
In general if you wanted an MCU to be able to communicate with either modbus or canbus, can that be done with one bridge and one r485 connector or would you need two?
Most values are stored as 16 bit words.
Not sure of the A/D word size. Either 10 or 12 bits.
boB
Quote from: boB on May 21, 2024, 03:51:56 PMThey are ARM Cortex-M3 parts from NXP.
Am I correct in that mcu is limited to 8adc channels (4 differential)?
In which case maybe STM32F030 might be better suited with "The 12-bit analog to digital converter has up to 16 external and two internal (temperature sensor, voltage reference measurement) channels and performs conversions in single-shot or scan modes. In scan mode, automatic conversion is performed on a selected group of
analog inputs.
That would allow for 4bank monitoring (uses 8 channels) plus Remote Battery Sensing (1 input).
Quote from: Barry Fields on May 21, 2024, 12:22:34 PMIn general if you wanted an MCU to be able to communicate with either modbus or canbus, can that be done with one bridge and one r485 connector or would you need two?
I am still learning.
It is best that I drag this all together in an illustrative format. Most all the proposals have been discussed in detail in a myriad of posts over the last year or so.
I am indeed open to answer any questions?
I want to express my thanks to many of you for your patience and cooperation.
I have a friend who uses PLC to do things like you have drawn up. It can read modbus and sensors and has built in relays and logic , etc.
I don't know PLC's but have messed around with Node Red a little bit which can do all by running on a Raspberry Pi or PC . There is no end to the coms , inputs , outputs, of any type with Node Red. But I am no expert in that - just know the basics .
Larry
Pause for reflection:
Is there anything I have suggested that:
1) "could not work"?
2) That would require any modification to existing MidNite charge controllers except maybe a firmware upgrade?
3) That would not add to or improve the capabilities of MidNite charge controllers?
Any positive or negative feedback would be appreciated.
Barry
Quote from: Barry Fields on May 22, 2024, 12:38:11 PMPause for reflection:
Is there anything I have suggested that:
1) "could not work"?
2) That would require any modification to existing MidNite charge controllers except maybe a firmware upgrade?
3) That would not add to or improve the capabilities of MidNite charge controllers?
Any positive or negative feedback would be appreciated.
Barry
Barry, let's see your idea of a phone app and how it would show data
That's what people want
Quote from: boB on May 22, 2024, 04:05:25 PMBarry, let's see your idea of a phone app and how it would show data
Can a person connect to the Classic or Hawkes with a android cellphone? I think yes.
Any data in the BBMT should be available over the modbus/canbus thru the Classic/Hawkes.
I have updated the BBMT block diagram.
The purple wire to the classic AUX2 WBjr port could transmit both Bank voltage and current (alternately).
You would no longer need a Power cycle on that line.
This would not load up the MODBUS with "fast data".
The BBMT could generate the PWM signal.
This would provide:
12bit accuracy of PWM calculations (lithium)
Off loading PWM calculations to BBMT freeing up Charge Controller CPU time.
Remote battery buss sensing 12bit to the charge controller.
Allow the Charge Controller to occasionally check Controller to Battery buss excess voltage drop.
Just trying to get a grip on rough timing issues.
Do the Classic or Hawkesbay continually respond to WBjr uart input or do they have to request it? If so how often?
How long would it take for a STM32F030 to check 9 ADC inputs (4 bank currents and bank voltage), add the 4 bank currents together, store that data in historical memory and output that data over uart?
What is a reasonable update time for SOC calculations in the Classic and Hawkesbay?
The MCU in the Classic max is 72 MHZ. The STM32F030 max is 48mhz. Is that a significant issue?
Quote from: Barry Fields on May 26, 2024, 11:26:13 AMJust trying to get a grip on rough timing issues.
Do the Classic or Hawkesbay continually respond to WBjr uart input or do they have to request it? If so how often?
How long would it take for a STM32F030 to check 9 ADC inputs (4 bank currents and bank voltage), add the 4 bank currents together, store that data in historical memory and output that data over uart?
What is a reasonable update time for SOC calculations in the Classic and Hawkesbay?
You could take a look at the code Graham wrote to see how he does it .
I was trying to find the timings in there but I am not good enough with code.
https://github.com/ClassicDIY/ClassicMQTT/blob/master/code/Python/support/classic_modbusdecoder.py
Larry
The Classic updates SOC 10 times per second. That is internally though. The SOC is most likely pulled from the Classic much less frequently, like once or twice per second max.
Internally the SOC is measured in amp-seconds or amp-milliseconds.
For what you want to do, 48 MHz is probably just fine. I tend to go with faster clock speeds these days.
boB
Quote from: Barry Fields on May 26, 2024, 11:26:13 AMDo the Classic or Hawkesbay continually respond to WBjr uart input or do they have to request it? If so how often?
I asking about the BATTvolts and BATTcurrent. How often and how long does it take?
Quote from: Barry Fields on May 26, 2024, 05:03:37 PMQuote from: Barry Fields on May 26, 2024, 11:26:13 AMDo the Classic or Hawkesbay continually respond to WBjr uart input or do they have to request it? If so how often?
I asking about the BATTvolts and BATTcurrent. How often and how long does it take?
The WB Jr. is queried by the Classic or HB or Barcelona as often as it wants but maximum of 16 Hz I think.
Right now it is being sampled 10 times per second. You only do things as fast as they are required otherwise it takes extra processor resources.
Quote from: boB on May 27, 2024, 01:32:11 AMThe WB Jr. is queried by the Classic or HB or Barcelona as often as it wants but maximum of 16 Hz I think.
Right now it is being sampled 10 times per second. You only do things as fast as they are required otherwise it takes extra processor resources.
I was under the impression that the WBjr ran async with no request required.
Attached is a block with what I think I know.
Let us remember my goal here:
For the Classic line
Eliminate the need to redesign the Classic line. It's not broke!
Improve the current resolution (SOC calc & Float current)
Add remote battery sense w/improved resolution (lifepo4 charging & setpoint/range discrimination)
for all MidNite charge controllers
Add improved Charge Regimen (Float current confirmed Absorb time)
Add parallel battery bank monitoring (battery bank health, Float current tracking, Current contribution/bank)
Add sequential load management based on PWM
Additional sense inputs (? batt box temp, ambient temp, h2o sense...?)
The BBMT would give a functional upgrade path without unneeded additional MPPT and Charging abilities (major cost portion of an additional charge controller)
Even more stuff I do not know:
I understand the MPPT calculations need to be performed rapidly. I think I hear you saying that SOC and charging voltages are sampled @ 10/second. Battery voltages and currents move much slower than PV stuff.
If the Battery parameters were sampled @ 7 or 5 /second, would it reduce the accuracy enough to worry about? (it would free up MCU time)
just asking
When the Classic stores and accesses EEPROM data, am I correct that is done thru DMA and not MODBUS?
Concerning the previous question, if the sample rate was 8/sec, then adding the last 8 samples and shifting the last 3 LSBs would give you the last 1second avg (approx).
I notice you have the WB Jr AND your BBMT on the same line, Aux 2.
Aux 2 when being used for WB Jr is the only thing that will run.
You can see the data on the Aux 2 line being sent from the Classic and the WB Jr.'s response with an o-scope.
boB
Quote from: boB on June 17, 2024, 12:09:08 PMI notice you have the WB Jr AND your BBMT on the same line, Aux 2.
Me thinks you missed the big "OR" between WBjr and BBMT.
point being,
The BBMT could send 12bit Battery current and voltage to the classic over MODBUS. (classic has 10bit accuracy)
The BBMT's Battery voltage would be remote sense (not available on the Classic)
The BBMT's EPROM could store individual Bank currents and float currents on Hourly & Daily basis. It could also compute weekly averages for 104 weeks to enable year over year comparisons.
But the WB Jr. is 16 bit accuracy. +/- 15 bits actually.
Modbus is a nice way of doing that communications.
You know, remote sense is nice when there is a lot of drop across that battery to CC cable but it isn't always necessary because as the battery gets full, the current goes way down during the absorb time. That is, unless there are large loads on the battery at that time in which case you would not have been able to put out much bulk current before the voltage had risen to Absorb.
I would argue that a tenth or two of voltage inaccuracy isn't a big problem, even for most lithium.
Quote from: boB on June 17, 2024, 11:04:03 PMBut the WB Jr. is 16 bit accuracy. +/- 15 bits actually.
Then the BBMT would need a better MCU ADC. Before I suggest a stm32H, do the Hawks Bay and Barcelona use a MCU with those capabilities (4bank differential current inputs + a couple extras for BattV)? I love standardization.
Quote from: boB on June 17, 2024, 11:04:03 PMYou know, remote sense is nice when there is a lot of drop across that battery to CC cable but it isn't always necessary because as the battery gets full, the current goes way down during the absorb time. That is, unless there are large loads on the battery at that time in which case you would not have been able to put out much bulk current before the voltage had risen to Absorb.
I would argue that a tenth or two of voltage inaccuracy isn't a big problem, even for most lithium.
I agree but when that differential approaches .5v and above it would interfere with absorb times and actual float voltage. Once it gets to 1v and above it should trigger some sort of warning of connection issues.
Quote from: boB on June 17, 2024, 11:04:03 PMBut the WB Jr. is 16 bit accuracy. +/- 15 bits actually.
Then the BBMT would need a better MCU ADC. Before I suggest a stm32H, do the Hawks Bay and Barcelona use a MCU with those capabilities (4bank differential current inputs + a couple extras for BattV)? I love standardization.
Can I ask what MCU is used in the Hawkes bay and Barcelona?
Quote from: Barry Fields on June 20, 2024, 07:00:37 PMQuoteBut the WB Jr. is 16 bit accuracy. +/- 15 bits actually.
Then the BBMT would need a better MCU ADC. Before I suggest a stm32H, do the Hawks Bay and Barcelona use a MCU with those capabilities (4bank differential current inputs + a couple extras for BattV)? I love standardization.
Can I ask what MCU is used in the Hawkes bay and Barcelona?
Just a NAG NAG NAG looking for answers.
I would also like to see a new classic refresh.
Something with higher voltages, to my knowledge the classics are still the best controllers for Wind power.
With newer residential turbines coming out that can put out voltages in the 700v range, having a classic 600 would be nice for these turbines.
Just as an example turbine, the Istabreeze Heli 4.0 on grid turbine can hit voltages over 700 in good wind gusts.
Thanks