Robin I assumed with a one wire connection to the classic and a retail price of $59 (not including shunt) at that price it obviously
utilises the MN graphics panel display.
Ive started the thread, Illl also take 10 units please ;D
Quote from: nigel on December 09, 2012, 10:28:44 AM
Ive started the thread, Illl also take 10 units please ;D
Robin;
Stick me on that list, too. I only want a couple as I am just an end user not a vendor like Nigel seems to be. If they can be ganged up anyway. One for the power room one for the house.
So I guess my "feature request" is simple attachment of multiple monitors without additional devices like a Hub on OB gear even if they need to be daisy chained. a wired range of 100 meters or so be good, too, if you can't sort out doing it wireless.
I don't want much do I.
Tom
When will they roll off the line?
Nigel, thanks for starting this Thread,
Yes!! Count me in for a few of the MN BMs, already have the Shunts installed ... hope that such a BM would have the ability to end Absorption via measured battery charge current at, or soon after introduction.
If there was additional control capability added later, so much the better -- with things like unusual charge and EQ profiles. Perhaps the Boost Charge where the Vabs is higher for a period than the main Vabs, recharge only every N days if measured SOC above a value set, etc.
Thanks, Vic, always wanting MORE!
Quote from: Vic on December 12, 2012, 04:08:29 PM
Nigel, thanks for starting this Thread,
Yes!! Count me in for a few of the MN BMs, already have the Shunts installed ... hope that such a BM would have the ability to end Absorption via measured battery charge current at, or soon after soon after introduction.
This will be the first thing that it will do.
boB
Any news or ETA or anything like that? I like the idea of using the MNGP display, and giving it an ethernet port to connect it to the network.
That, and hurry up with those inverters! I'm gonna have MN everything in my setup eventually.
Quote from: crunnells on January 28, 2013, 06:28:01 PM
Any news or ETA or anything like that? I like the idea of using the MNGP display, and giving it an ethernet port to connect it to the network.
That, and hurry up with those inverters! I'm gonna have MN everything in my setup eventually.
Okay ! Hurryan fast !
Quote from: boB on December 12, 2012, 04:21:25 PM
Quote from: Vic on December 12, 2012, 04:08:29 PM
Nigel, thanks for starting this Thread,
Yes!! Count me in for a few of the MN BMs, already have the Shunts installed ... hope that such a BM would have the ability to end Absorption via measured battery charge current at, or soon after soon after introduction.
This will be the first thing that it will do.
boB
Awesome! I'm in for one, I'm wondering how confused the classic's will be when I'm running a couple A/Cs during the summer. Is the classic setup for this type of input? or will we need the new Midnite "Modern" charge controller, with flip up display and Bluetooth?
I'm fine with out the use of MNGP so long as I can use the network to program things...
... And, boB,
Forget, this may have been touched on before,
Will the MN batt I sensing device also allow measuring the actual battery voltage -- ala Kelvin -- and allow Classics to use this during Abs and EQ ?
That would be even cooler. Vic
boB, Robin, Ryan, et al;
I find it very refreshing to see a manufacturer with such a commitment to dialog with and useful responses to users. Very good all around, I figure. Better products and happy customers.
Now all you guys need to do is stop taking weekends and nights off and get to work implementing these ideas. ;) Or start outsourcing to China / India. :o Kidding about outsourcing ::)
Thanks from a satisfied customer who wishes you made inverters when I bought mine.
Tom
Quote from: TomW on January 30, 2013, 04:15:34 PM
boB, Robin, Ryan, et al;
I find it very refreshing to see a manufacturer with such a commitment to dialog with and useful responses to users. Very good all around, I figure. Better products and happy customers.
Now all you guys need to do is stop taking weekends and nights off and get to work implementing these ideas. ;) Or start outsourcing to China / India. :o Kidding about outsourcing ::)
Thanks from a satisfied customer who wishes you made inverters when I bought mine.
Tom
Couldn't have said it better myself.
Do I understand correctly that this battery monitor will be able to control a Classic's battery charging process? (or several Classics?)
I'm thinking that the BM cotrols absorb for a LiFePO4 battery.
And dare I suggest that if the BM is ethernet conneted, has a modern cpu/ram and flash storage that it does not get crippled with that
archaic MODBUS rubbish as its main method of extracting logged data OR specifying working parameters. Please use your software interface design engineer to implement a nice simple robust API 8)
dgd
Quote from: dgd on January 31, 2013, 12:47:38 AM
Do I understand correctly that this battery monitor will be able to control a Classic's battery charging process? (or several Classics?)
I'm thinking that the BM cotrols absorb for a LiFePO4 battery.
From what I have seen with LiFePO4 BMS', there is no absorb cycle. They just want you to turn off when the voltage reaches
a certain set point. MidNite will not be making a BMS, at least not at the moment. Could do it I suppose but just look
at the trouble Boeing is in even with a BMS.
Quote from: dgd on January 31, 2013, 12:47:38 AM
And dare I suggest that if the BM is ethernet conneted, has a modern cpu/ram and flash storage that it does not get crippled with that
archaic MODBUS rubbish as its main method of extracting logged data OR specifying working parameters. Please use your software interface design engineer to implement a nice simple robust API 8)
dgd
Our basic system won't be changing from modbus any time soon. There might be some additional protocols though.
Modbus is just becoming a standard for RE/AE systems and a lot of customers either want it or don't care one way
or the other. BTW, are you referring to generic RS-232/RS-485 modbus or modbus over TCP/IP ?
The one thing I don't care for about modbus is that the file transfer portion have limited packet size.
There will be a way, fairly soon, to recall the Classic logs from the USB which will not be modbus if that helps.
What comm protocols do you like and/or write code for ?
boB
Quote from: boB on January 31, 2013, 01:49:21 AM
From what I have seen with LiFePO4 BMS', there is no absorb cycle. They just want you to turn off when the voltage reaches
a certain set point. MidNite will not be making a BMS, at least not at the moment. Could do it I suppose but just look
at the trouble Boeing is in even with a BMS.
see from the pdf doc below the 500Ah cells charging info..
Note section re: battery Monitor
So BM that knows Battery usage can watch ABSORB time for one or more Classics (or use FOLLOW ME on Classics)
Note there is no BMS provided with, or AFAIK available for, these cells
dgd
Quote from: boB on January 31, 2013, 01:49:21 AM
Quote from: dgd on January 31, 2013, 12:47:38 AM
And dare I suggest that if the BM is ethernet conneted, has a modern cpu/ram and flash storage that it does not get crippled with that
archaic MODBUS rubbish as its main method of extracting logged data OR specifying working parameters. Please use your software interface design engineer to implement a nice simple robust API 8)
dgd
Our basic system won't be changing from modbus any time soon. There might be some additional protocols though.
Modbus is just becoming a standard for RE/AE systems and a lot of customers either want it or don't care one way
or the other. BTW, are you referring to generic RS-232/RS-485 modbus or modbus over TCP/IP ?
The one thing I don't carye for about modbus is that the file transfer portion have limited packet size.
There will be a way, fairly soon, to recall the Classic logs from the USB which will not be modbus if that helps.
What comm protocols do you like and/or write code for ?
boB
Where to start? I can't see
any necessary reason to have the Classic communicating via 30+year old protocol that was designed for use PLC devices of 1970s vintage. Limited data structures support (eg no array, stack, record, file types..), good for the few registers/accumulators those PLCs had, master/slave configuation with serial comms performance suited to 110baud serial links. Polling registers continually to test for data changes/updates, no active register notification, ie no interrupt driven data change reporting,... ad nau.seam. :'(
Ok modbus over ethernet offered some improvements but you can't do much about its archaic design, awful polling interface, repetitive small data element retrieval to d/l any decent volume of data, cpu cycle waste at both master and slave ends, one-to-one active connection only (perhaps this explains why only one local app on one computer can connect to a Classic - ie Modbus screws Ethernet), ad naus...
So what should the comms protocol be?
I would tend to go for a top-down design of user interface rather the bottom-up approach starting with a register level comms protocol.
Top for me would have been a built-in web server in the Classic. So accessing the Classic with a web browser would display a status page that went
on to various setup and reporting pages, grapichs displays etc. Same for design of new BM. Its not exactly rocket science to do this, when I look at the web interface in my Cisco/Netlink WET54G box
This, IMHO, would be a much more satisfying experience for Classic owners/users than dealing with modbus dependant applications.
I won't mention the MN Local App, oops I did.. ???
dgd
Quote from: dgd on February 01, 2013, 12:45:17 AM
Where to start? I can't see any necessary reason to have the Classic communicating via 30+year old protocol that was designed for use PLC devices of 1970s vintage. Limited data structures support (eg no array, stack, record, file types..), good for the few registers/accumulators those PLCs had, master/slave configuation with serial comms performance suited to 110baud serial links. Polling registers continually to test for data changes/updates, no active register notification, ie no interrupt driven data change reporting,... ad nau.seam. :'(
Ok modbus over ethernet offered some improvements but you can't do much about its archaic design, awful polling interface, repetitive small data element retrieval to d/l any decent volume of data, cpu cycle waste at both master and slave ends, one-to-one active connection only (perhaps this explains why only one local app on one computer can connect to a Classic - ie Modbus screws Ethernet), ad naus...
So what should the comms protocol be?
I would tend to go for a top-down design of user interface rather the bottom-up approach starting with a register level comms protocol.
Top for me would have been a built-in web server in the Classic. So accessing the Classic with a web browser would display a status page that went
on to various setup and reporting pages, grapichs displays etc. Same for design of new BM. Its not exactly rocket science to do this, when I look at the web interface in my Cisco/Netlink WET54G box
This, IMHO, would be a much more satisfying experience for Classic owners/users than dealing with modbus dependant applications.
I won't mention the MN Local App, oops I did.. ???
dgd
The Classic isn't 110 baud, it's 19.2K on the RS232 ports. Heck, RS232 is way older than modbus and
it is still used today.
It is also not only a polled system... You can read and write from/to the Classic over the bus.
The network, as it sits now, can handle 2 simultaneous ethernet connections at once. One for
My Midnite where it calls into a server and the other which can be something like the local app
or any modbus over TCP/IP connection to the Classic. The Classic modbus network can be
both a client or a server which is non-standard. So, in that regard, the Classic actually could
tell the other end when something changed. The RS-232 modbus software also goes
beyond standard modbus by forwarding packets out the opposite port when the address is
not destined for the Classics' set address. We can add other communications protocols
for different situations if we need to. So we are not designed into a corner if we
need to switch direction when say, networking Classics for other reasons like paralleling.
Modbus work great for the 99% of what we are doing.
If the Classic were just a web server, it would be harder to control the Classic. The modbus
protocol was also picked several years ago now so a lot of work has already gone into it.
The main reason for picking modbus was that we wanted some kind of standard RS-232
protocol to transfer data. I originally had my own protocol which was similar to modbus
but that would not have conformed to any standard as far as address bytes, commands,
data, CRC checksum at the end and the minimum 3.5 character silence in between packets.
So, modbus made perfect sense. It works as well I think as anything we could come up
with by ourselves and a lot of customers already understand this format and are communicating
with Classics with their own software. How can we beat that ? And, 19.2 K baud is still
19.2 K baud with the simple overhead of bytes that would be there no matter what
protocol or format we chose. Even if there were some slightly better way of organizing
the way bytes are read and written, why would we want to spend the mass amount of
time to change direction ? Midnite would be out of business if we tried to do that.
Ain't gonna let that happen anytime soon, I hope. We can make changes as needed
for special needs.
Having said that, it looks like the Classic may very well have a web interface built
into its network capabilities as well as being able to SMTP an email to the user to
their email address of certain chosen status and/or error information.
Top down user interface changes will not happen for the same reason we won't
change willy-nilly from modbus. We will however make improvements to the U.I.
Now, if this were just a hobby, this might all be different, but it isn't. It's a lot of
hard work and many man years of time involved in getting to where we are today
and it's not done yet as you can see.
Newer functionality would be available by updating the firmware of existing Classics
as we get round tuits.
boB
dgd;
Good and valid points!
It sure seems everything has a web interface these days. That makes it cross platform (very good), user friendly, extensible and flexible. All good.
I am not in the loop on why things are the way they are.
History shows that the better method does not always prevail.
Beta Max was technically superior (IMHO) to VHS but you don't see many Beta Max units in use today as a "ferinstance".
I just despise modbus because there seems to be a lack of options for some hardware like Arm. I could not find a port of modpoll for my Raspberry Pi or my Linksys NSLU2. Exactly the kind of low power devices that should be interfaced with an RE system for control and monitoring.
I won't even go on about Adobe Air.
Sadly, you can't please everyone and you have to cater to the widest swath of users which is not the lean and mean bleeding edge hardware with a limited user base.
No answers, just more whining.
Your router web interface analogy is a great example of what is possible in that regard, especially dynamic content and configuration management. Could probably easily access the existing modbus system internally, too, similar to the Local App? Once you have that ability you can control the system from remote via cgi scripts much like I do with the CAI Webcontrol boards I have scattered around the ranch here. Gather data, send commands, monitor alarms and status, the list goes on and on all from a web browser on any platform anywhere on this interweb thingy. If you desired.
Just from here.
3 AM and I am rambling up way too early.
Tom
@boB
Thanks for your reply.
I can actually appreciate where you are coming from and your investment in time and expertise getting modbus to where it now does what you want.
My point is that modbus is not useful for classic users. It's just too primitive and needs a lot of effort from users to understand and write program's to make use of it. I think it's unlikely more than a few classic owners/users want to or are capable of this primitive interface programming.
The world standard user interface tool is a web browser, every man, woman, child and their dog has access to one. Just about every 'intelligent' device offers a web interface.
So I think this is the user interface the Classic should be providing.
If the hardware has the resources then I would suggest :
Local App development ceases, make the current release the final production version.
Obtain web serving software for the classic and get it installed
Commence developing in HTML code the web pages the classic will offer, eg status, reporting, setup etc..
All IMHO of course..
Dgd
Quote from: TomW on February 01, 2013, 04:05:42 AM
..
Your router web interface analogy is a great example of what is possible in that regard, especially dynamic content and configuration management. Could probably easily access the existing modbus system internally, too, similar to the local app...
..
Tom
If there was a web interface in the Classic (or BM) then the HTML code for the web page would simply map a data structure, such as an array or record, over the physical memory, ram or flash or whatever, and access data values by reading the data structure. There would be no need to use a serial link protocol to extract data. 8)
Dgd
Quote from: dgd on February 01, 2013, 08:27:06 AM
@boB
Thanks for your reply.
I can actually appreciate where you are coming from and your investment in time and expertise getting modbus to where it now does what you want.
My point is that modbus is not useful for classic users. It's just too primitive and needs a lot of effort from users to understand and write program's to make use of it. I think it's unlikely more than a few classic owners/users want to or are capable of this primitive interface programming.
The world standard user interface tool is a web browser, every man, woman, child and their dog has access to one. Just about every 'intelligent' device offers a web interface.
So I think this is the user interface the Classic should be providing.
If the hardware has the resources then I would suggest :
Local App development ceases, make the current release the final production version.
Obtain web serving software for the classic and get it installed
Commence developing in HTML code the web pages the classic will offer, eg status, reporting, setup etc..
All IMHO of course..
Dgd
We are already working on a web interface. But the web interface will not and can not replace the modbus control protocol.
It will supplement modbus though.
I must disagree that customers cannot program modbus interfaces. They are doing it all the time and it's working great
for them. If they can program at all, then modbus is a "mature" protocol. If they can't interface using modbus, then
they should go back to computer school or hire a programmer.... IF they can find one ! It's very hard these days to
find good programmers for embedded systems.
boB
I do want to point out that I believe Air is on its way out of our supported things to use ::)
Andrew and crew are working round the clock to make a web interface that resides on the product and I suspect this will be a reality in the Classic in the not so distant future. As far as Code or HTML that is above my head but I will pass this thread on to Andrew and let him respond.
We are very happy to listen to all ideas, Actually that's sorta why we are using ModBus it was asked that it become the standard in the renewable industry and many manufacturers are supporting that. SunSpec alliance is working to bring us all to the same ModBus registers etc.
Anyhow keep the ideas coming and we will take them all into consideration as our goal is to make robust and affordable products that please as many people as possible.
Ryan
I was going to say that also the web interface was supposed to be there back in 2012 but is not. Same thing with sound. I am kind of cranky tonight, but need to mention there were a lot of cool features and possibilities that Midnight created for us and now are teasing us hoping to have with no end in sight.:)
Laszlo
I think you are referring to My Midnite the web based monitoring? As far as I know we never had any plans to instal a web interface into the Classic until about 3 months ago?
My MidNite is starting to take shape and should be ready for Beta testers any time now.
Ryan
Quote from: boB on February 01, 2013, 03:15:23 PM
We are already working on a web interface. But the web interface will not and can not replace the modbus control protocol.
It will supplement modbus though.
I must disagree that customers cannot program modbus interfaces. They are doing it all the time and it's working great
for them. If they can program at all, then modbus is a "mature" protocol. If they can't interface using modbus, then
they should go back to computer school or hire a programmer.... IF they can find one ! It's very hard these days to
find good programmers for embedded systems.
boB
Ok its good news that a built in web server is on the way for the Classic. I just hope that sufficient priority is given to it's developnebt as we don't want another software system in the 'almost ready' category for the forseeable future (ie years!)
With such an interface its only a simple step away to include FTP file uploading (and downloading). I'm thinking here of firmware updates, No more
seriial port uploads for firmware updates. A web page with FTP upload over ethernet - directly from the MN website :)
And of course a Telenet login connection with the command line interface already discussed several months ago - for those that desire to write their own display programs.
Then no place left for or need for a local app, my midnite or data extraction using modbus protocols
Don't really need the MNGP anymore, everything it does the web interface does, the LITE is all we need... ;D
dgd
Quote from: boB on January 31, 2013, 01:49:21 AM
From what I have seen with LiFePO4 BMS', there is no absorb cycle. They just want you to turn off when the voltage reaches
a certain set point. MidNite will not be making a BMS, at least not at the moment. Could do it I suppose but just look
at the trouble Boeing is in even with a BMS.
boB
boB,
You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday :D
dgd
The newest firmware has 2 new Aux functions. One is an Logic high state that tells the classic to go to resting the other is a Logic low state that tells the classic to go to resting. The voltage window is up to 12 volts I believe but boB will chime in here to correct me if I am wrong
Ryan
Quote from: dgd on February 03, 2013, 06:11:54 AM
Quote from: boB on January 31, 2013, 01:49:21 AM
From what I have seen with LiFePO4 BMS', there is no absorb cycle. They just want you to turn off when the voltage reaches
a certain set point. MidNite will not be making a BMS, at least not at the moment. Could do it I suppose but just look
at the trouble Boeing is in even with a BMS.
boB
boB,
You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday :D
dgd
Yes, am planning another Aux 2 input logic function to force the Classic to Float.
The logic level high voltage is about 6 volts.
boB
Quote from: dgd on February 03, 2013, 06:11:54 AM
Quote from: boB on January 31, 2013, 01:49:21 AM
From what I have seen with LiFePO4 BMS', there is no absorb cycle. They just want you to turn off when the voltage reaches
a certain set point. MidNite will not be making a BMS, at least not at the moment. Could do it I suppose but just look
at the trouble Boeing is in even with a BMS.
boB
boB,
You mentioned elsewhere the AUX input that will turn off output from the Classic. This being how a BMS controls battery charging.
My LiFePO4 cells need an absorb time that depends on battery Ah discharge time as provided by a BM.
This would need an input, preferably an AUX funtion, that stops ABSORB and commences FLOAT.
Does such a function already exist? (not documented) or if not are you planning to include one? - any time soon, like yesterday :D
dgd
dgd;
I would really like to learn more about your set-up.
I am *very* interested in using LiFePO4 batteries, as I've yet to
actually buy my battery bank. I looked through some of your
posts, but I can't find an inclusive description of your setup.
If you could point me to one, I'd really appreciate it.
--
Quote from: cpm on February 04, 2013, 10:32:48 AM
dgd;
I would really like to learn more about your set-up.
I am *very* interested in using LiFePO4 batteries, as I've yet to
actually buy my battery bank. I looked through some of your
posts, but I can't find an inclusive description of your setup.
If you could point me to one, I'd really appreciate it.
--
hi cpm,
Im in the process of changing my 1100Ah 24v batteries - 6 by 4 volt Century Yaesu flooded lead acid to 4 by 12volt 500Ah LiFeYPO4 batteries as a 24v 1000Ah bank which I can later reconfigure to 48v at 500Ah.
The LiFeYPO4s are arriving March 10 so in meantime I'm trying to get everything I need to install them.
I posted the batt details a few messages back.
The reason I chose these types was they do not need a BMS. Apparently because cell balancing is not needed when the cell AH rating is large and multiple cell strings are not used. Another 480Ah 12v battery I looked at had multiple 80Ah cells and charge balancing was essential. The required BMS inflated the price :(
These Lithium cells use an ABSORB then FLOAT charge regimen with ABSORB time calculated by a battery monitor depending on how many Ah has been removed from the battery by loads. Voltage is no indicator of SOC as its constant to about 80% discharge.
boB has already made an AUX input available that will work with a BMS. I hope he gets time to add one that forces FLOAT.
Better still if MN had a battery monitor arriving soon. In meantime I'm looking at using a Pi to monitor.
Sorry I have not posted pics of my setup. I did get a shock when I saw those from plongson and Ryan, they both show how a 'power wall' should be.
Its encouraged me to tidy up my wall mess and recable into trunking. Pics soon
dgd
I've been thinking about battery monitors...
When Midnite battery monitor estimates SOC, will it derate battery capacity based on battery temperature? If so, how will it know the temperature... will the Classic tell it?
When the monitor counts amphours will it be able to compensate for Peukert effect? (display raw amphours vs. compensated amphours, and calculate SOC by either method)
Will the monitor make its own determination of 100% SOC, or will it assume the Classic's transition to float indicates 100% SOC?
Will the Classic be able to change modes or activate AUX relays based upon the SOC?
--vtMaps
Is this the MNBCM currently listed on the site or is this product still in development? From the NAWS forum, I recall boB talking about a new battery monitor in the works that could tell the Classic what the current flow into the battery actually was. I came over here looking for a status update and this thread seems to be talking about the same product boB was over there. I'm trying to sort out whether it's come to market yet or not.
Quote from: vtmaps on March 26, 2013, 07:20:51 AM
I've been thinking about battery monitors...
When Midnite battery monitor estimates SOC, will it derate battery capacity based on battery temperature? If so, how will it know the temperature... will the Classic tell it?
Good idea ! The actual capacity depends on what the capacity is at 25 degrees C of course so
you have to know that or create a discharge curve to find out. You'd also have to be able to
enter a temperature derating constant and I'm not sure if that is actually constant or linear.
The Classic(s) know the battery temperature if at least one is installed.
Quote from: vtmaps on March 26, 2013, 07:20:51 AM
When the monitor counts amphours will it be able to compensate for Peukert effect? (display raw amphours vs. compensated amphours, and calculate SOC by either method)
We'll see. That isn't too hard to do. If the coefficient is correct, it should help the accuracy of the SOC.
Problem with these kind of inferences is that as the battery ages, the coefficients and efficiencies change
so it's really hard to know exactly what the correct factors are at any time. These may possibly be
learned and re-learned periodically.
Quote from: vtmaps on March 26, 2013, 07:20:51 AM
Will the monitor make its own determination of 100% SOC, or will it assume the Classic's transition to float indicates 100% SOC?
It would be mixed in with the Classic's charging. Since you know the Absorb voltage and battery temperature, etc,
a lot is known about the system which can help to better calculate the SOC. There may be some learning of
the battery characteristics involved as well.
Quote from: vtmaps on March 26, 2013, 07:20:51 AM
Will the Classic be able to change modes or activate AUX relays based upon the SOC?
--vtMaps
Aux output based on an adjustable SOC ? You bet !
Quote from: williaty on April 05, 2013, 10:52:42 PM
Is this the MNBCM currently listed on the site or is this product still in development? From the NAWS forum, I recall boB talking about a new battery monitor in the works that could tell the Classic what the current flow into the battery actually was. I came over here looking for a status update and this thread seems to be talking about the same product boB was over there. I'm trying to sort out whether it's come to market yet or not.
Yes, this is that monitor. No, it isn't available yet.
Probably still 3 months or so out. Give or take a bit.
It will also not be an SOC meter at first.
boB
Quote from: boB on April 06, 2013, 04:08:09 AMYes, this is that monitor. No, it isn't available yet.
Probably still 3 months or so out. Give or take a bit.
It will also not be an SOC meter at first.
Is the ability to aid the Classic in terminating Absorb via Ending Amps part of the release-day functionality?
Yes it should be.
Ryan
Quote from: boB on April 06, 2013, 04:08:09 AM
Quote from: williaty on April 05, 2013, 10:52:42 PM
Is this the MNBCM currently listed on the site or is this product still in development? From the NAWS forum, I recall boB talking about a new battery monitor in the works that could tell the Classic what the current flow into the battery actually was. I came over here looking for a status update and this thread seems to be talking about the same product boB was over there. I'm trying to sort out whether it's come to market yet or not.
Yes, this is that monitor. No, it isn't available yet.
Probably still 3 months or so out. Give or take a bit.
It will also not be an SOC meter at first.
boB
This is exciting. I have the mouse arrow hovering over the check out button on a Classic 150 Lite because I hear you would be including battery shunt monitoring. I hope you will allow the option of real time monitoring of loads in the local app and the my midnite site.
- Jeff
Should I get a Deltec 500 amp (or 100 amp) shunt now and include it in my new install anticipating this ability in my lite 150 that arrives tomorrow?
Quote from: unyalli on April 11, 2013, 04:32:32 PM
Should I get a Deltec 500 amp (or 100 amp) shunt now and include it in my new install anticipating this ability in my lite 150 that arrives tomorrow?
It's never a bad idea to include a shunt into your system anyway, and the cost is pretty trivial.
FYI, the Classic won't have included battery monitoring; what they're talking about is a separate unit that will interface with the Classic (and a shunt) but you won't be able to do battery monitoring with just the Classic. You'll need both.
Any progress on this thing?
Been hotter here in the past two weeks -- hotter than "normal" for more days in a row, and NOT cooling off much at night.
Having this Absorption terminator based on charge current would allow us to reduce our battery temps by 10 degrees F or more.
The batteries were frying, so have elinimated the Absorption Stage, and set Vabs to Vflt +0.1V. This will work OK for a while. Am hoping that there will be a few cooler days soon, when we can fully recharge the battery banks.
We run A/C in both power rooms, and use EA as absorb terminator. We must set the A/Cs to a temperature high enough to allow it to always cycle at the typical time that absorb ends (otherwise, the CC current to run the A/C means that EA value is never reached) But, earlier this week, we guessed wrong, the A/C did not cycle off, and the Absorb stage was temrinated by Max time -- not good. Batts got up to at least 85 F. With this Whiz-Bang device, I could set the A/C's thermostat in the 60s F, and help keep the batts much cooler, and all of the electronics would be much happier, too.
Just a ping ... We sure could use this charge terminator. Have shunts installed, just begging for something to do. Know you MN folks are very busy, and many of your customers are begging for other things, but I just needed to beg a bit for this.
(Note: A/C= Air Conditioner. AC= Alternating Current to me) Thanks, Vic
Quote from: Vic on July 05, 2013, 04:25:53 PM
We sure could use this charge terminator. Have shunts installed, just begging for something to do.
Hi Vic,
I suspect (but I hope I am wrong) that you will have to replace your shunts. The picture I have seen of the WhizBang Jr looks like it includes an integral shunt.
The picture was posted by Robin over at the NAWS forum:
http://www.wind-sun.com/ForumVB/showthread.php?p=153695#post153695
--vtMaps
Hi, vt,
Thanks, did see that some time ago, but it looked like a standard 50 mv shunt, that the whizzie thingie was attached to.
Will go back to look. I have never used an e-panel, but believe that some of them include the Shunt, and others may well have a position for standard shunts. Might seem a bit wasteful to include a shunt, when a reasonable number of systems have them not ...
The shunts in limited use here are in Xantrex DC Conduit boxes -- DCCB-Ls -- which Robin probably designed while he was at X. The MN folks know better than others weather a shunt should be included.
If the Whizz included a shunt, would not be a big deal, could replace the ones that exist, or perhaps put the MN guts on the existing shunt. I had thought that the shunt might be a more expensive part than all of the rest of the WhizBang Lite, such that the shunt might be an option. Dunno. And the shunt question has been asked in this Thread and not yet answered.
Enjoy the Summer, Thanks, Vic
Hi Vic, have been looking at pics of the Epanels the last few days and a lot (all?) of them seem to have a shunt installed, might be wrong about all, but seemed a lot of them.
Quote from: Westbranch on July 05, 2013, 08:36:05 PM
Hi Vic, have been looking at pics of the Epanels the last few days and a lot (all?) of them seem to have a shunt installed, might be wrong about all, but seemed a lot of them.
West;
Both of mine do (OB Stretched). And I seem to recall it listed in the spec sheet. Every picture I have seen of the guts show a shunt installed.
Just FYI.
Tom
Hi Wb ( Eirc/k?) and TomW,
Thanks for the added detail. Had looked at only a couple of different e-panels, and thought that each had a Shunt installed, but had been some time ago, so thanks for data.
And guess that these Shunts might be 500 Amp Full-Scale? Expect that this device could have a scale factor adjustment.
The Shunts in use in systems here are 500 A jobs.
OK, Thanks again. It IS cooler here today, and am not starting to recharge the banks that have been slacking for a while. Vic
Quote from: Vic on July 05, 2013, 10:29:56 PM
And guess that these Shunts might be 500 Amp Full-Scale? Expect that this device could have a scale factor adjustment.
From the pic it looks like it is mounted on a standard 500A/50mV shunt. I suspect the device is a very high resolution volt meter which is measuring the voltage drop across the shunt and with a high bit AD chip to give some good resolution in digital form. The question I have is where will that digital output data go to be displayed? - Will it plug into the CC for display on the MNGP or to a separate display?
Can't wait to get my hands on one. I've bought some components to make my own Arduino based monitor but haven't gotten around to building it yet. Most likely, I'll finally get to it just in time to have it outdone by the Whizbang Junior! :'( :o ;D
Hi doc,
Well, believe that the comm is at least partially via Modbus. There is a Modbus command in the Classic FW that is "Force Float", and some others that appear to be for an extended Bat Mon function.
This does not mean that there is not some other interface box for this device. And, of course, there could be an additional interface box later for the full Bat Mon.
Would expect that the MNGP would be the way parameters are set and displayed, at least initially.
Would expect that the App would also be able to set and display parameters, if for no other reason than Cl Lites.
However, as well as guessing works, it often does not work well in my hands.
Time will tell. As a retired Hardware/Firmware guy, know that I COULD do an external microcontroller. BUT, also know that this IS a project, and there are far too many of those around here. Have more PVs in stock here that need to see the light of day ... should be out there now figgerin' just how to do that.
Good weekend, Vic
Quote from: unyalli on June 12, 2013, 09:11:24 AM
Any progress on this thing?
Now that the info is out on the Kid and the Brat what about the MNBM? Are we going to see this guy soon?
Quote from: Resthome on July 25, 2013, 01:41:53 AM
Quote from: unyalli on June 12, 2013, 09:11:24 AM
Any progress on this thing?
Now that the info is out on the Kid and the Brat what about the MNBM? Are we going to see this guy soon?
Man ! I sure hope so !
Still working on it. Making progress.
boB
Quote from: boB on July 25, 2013, 04:37:17 PM
Quote from: Resthome on July 25, 2013, 01:41:53 AM
Quote from: unyalli on June 12, 2013, 09:11:24 AM
Any progress on this thing?
Now that the info is out on the Kid and the Brat what about the MNBM? Are we going to see this guy soon?
Man ! I sure hope so !
Still working on it. Making progress.
boB
Thanks boB. We know you have a lot of irons in the fire.
Quote from: Resthome on July 27, 2013, 01:18:03 PM
Thanks boB. We know you have a lot of irons in the fire.
Yes ! And they're ALL HOT !
Quote from: boB on July 27, 2013, 10:53:20 PM
Quote from: Resthome on July 27, 2013, 01:18:03 PM
Thanks boB. We know you have a lot of irons in the fire.
Yes ! And they're ALL HOT !
Most useful tip I can give you: make sure you grab them by the right end!
Battery monitor would make the classic perfect, the only info cannot get at the moment is net battery amp hours & state of charge, very important info to have with a remote monitored PV setup :)