New Battery Monitor For Systems using A Classic & utilising MNGP

[nigel]

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

[TomW]

Ive started the thread, Illl also take 10 units please

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

[Westbranch]

When will they roll off the line?

[Vic]

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!

[boB]

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

[crunnells]

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.

[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.

Okay !  Hurryan fast !

[Photowhit]

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...

[Vic]

 ...   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

[TomW]

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.  Kidding about outsourcing 

Thanks from a satisfied customer who wishes you made inverters when I bought mine.

Tom

[crunnells]

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.  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.

[dgd]

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   

dgd

[boB]

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.

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   

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

[dgd]

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

[dgd]

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   

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