Black Box Interface wish list

[TomW]

I figured this deserves a thread of its own.

What would you like to see in a "Black Box" as brought up in the Local App on a Samsung Tablet thread:

http://midnitesolar.com/smf_forum/index.php?topic=1070.0

Lets hash out what folks would like to see this device do.

How could it be useful to you?

What devices other than the Classic should it be able to interface with?

Just toss it out there and we will see what sticks to the wall.

Thoughts, ideas, whatever.

Tom

[Westbranch]

Cheap, naturally

Low power requirement. 5, 9  or 12 v dc

USB connection to a rPi/PC/Netbook, etc

Linux, MS,  Mac Op system

stand alone, programmable for polling time interval 1 min to 1 hr

~ 750 days storage of all data min.

Open Source

more later...

[TomW]

westbranch;

Power wise, the standard for low power devices seems to be 5 volts USB type power supplies so
that seems the way to go.

Ethernet, USB connectivity. Covers storage (USB stick) and communication (USB serial & ethernet)

Stand alone, certainly.

Programming flexibility. Absolutely. Already exists with a Pi.

Platform independent web browser based user interface for sure.

Pretty sure we are on the same page so far.

Tom

[dgd]

I sort of like the idea of a box that gathers data from one or more classics , maybe clipper, battery monitor and perhaps other useful devices such current and voltage detectors at various places, detects open breakers and fuzes ( I don't know how this would be done ) and coordinates it all into a general system report web pages.
I am already biased towards the RPi buts its lack of modbus support is disturbing..

Dgd

[TomW]

I sort of like the idea of a box that gathers data from one or more classics , maybe clipper, battery monitor and perhaps other useful devices such current and voltage detectors at various places, detects open breakers and fuzes ( I don't know how this would be done ) and coordinates it all into a general system report web pages.
I am already biased towards the RPi buts its lack of modbus support is disturbing..

Dgd

A CAI Webcontrol could gather info on things like switch or breaker states by reading across the switch / breaker looking for voltage (open switch =voltage on leads). It can do Analog to Digital conversion to sense voltages, measure shunts with some circuitry I know already exists. It has a proprietary system on it including a web based programming and monitoring system programmed in PLC. Not sure if or how it could be reprogrammed for this project? In concert with a Pi it could extend the capabilities of a Pi but would likely double the hardware costs.  The Webcontrol can send emails on fault conditions like open breakers, high or low voltage and combinations of data Could always have optional components to extend functionality of the basic system, of course.


I have other ideas but its about my bedtime for tonight.

Tom

[mtdoc]

A CAI Webcontrol could gather info on things like switch or breaker states by reading across the switch / breaker looking for voltage (open switch =voltage on leads). It can do Analog to Digital conversion to sense voltages, measure shunts with some circuitry I know already exists. It has a proprietary system on it including a web based programming and monitoring system programmed in PLC. Not sure if or how it could be reprogrammed for this project? In concert with a Pi it could extend the capabilities of a Pi but would likely double the hardware costs.  The Webcontrol can send emails on fault conditions like open breakers, high or low voltage and combinations of data Could always have optional components to extend functionality of the basic system, of course.


I have other ideas but its about my bedtime for tonight.

Tom

Tom,

Cool ideas! 

I'm currently working on a system to more accurately monitor my AC and DC currents, battery voltage, temp, etc.  The accuracy and resolution limitations on the Outback equipment (Inverter and  FNDC) is frustrating.  I've thought about a device that could then use this info to implement some control (loads, end absorb, etc) as well as log data to a user friendly interface. 

I'm looking at the possibility of an Arduino, rPi combo.... we'll see...

I'm just now experimenting with different current sensors (CTs and Hall effect) as well as using my existing 50 mv/ 500 amp shunt. One issue to keep in mind is that the ADC resolution  (typically 8 bit or less) in many existing low cost DAQ devices (eg Arduino) is not adequate for measuring the tiny- millivolt range voltages across shunts.  I'm experimenting with a 24 bit ADC IC now.

Just a heads up if looking at a CAI Webcontrol  type device for shunt voltage measurements - it will need 16 bit ADC or better I think...

[TomW]

One issue to keep in mind is that the ADC resolution  (typically 8 bit or less) in many existing low cost DAQ devices (eg Arduino) is not adequate for measuring the tiny- millivolt range voltages across shunts.

Just a heads up if looking at a CAI Webcontrol  type device for shunt voltage measurements - it will need 16 bit ADC or better I think...

There is a circuit that can be built on a breakout board for the Webcontrol that uses an op amp to boost shunt voltages to the proper levels for the built in ADC. I have not done it myself but rumor is that it works.

Waiting for some hardware to get this moving forward. It should be interesting.

I looked at the Aurdino but by chance ended up with a Pi so that is what I have to mess with now.

Tom

[mtdoc]

There is a circuit that can be built on a breakout board for the Webcontrol that uses an op amp to boost shunt voltages to the proper levels for the built in ADC. I have not done it myself but rumor is that it works.

Waiting for some hardware to get this moving forward. It should be interesting.

I looked at the Aurdino but by chance ended up with a Pi so that is what I have to mess with now.

Tom

More options! 

As I'm learning, the Arduino and rPi are more complementary than alternatives.  I'm just getting up to speed on both so I'm not sure how it will all pan out.   I can use the Arduino (or bare Atmel chip) as an I/O,  ADC interface between sensors and computer. (sounds like the CAI device could do likewise - as could a Gertboard).   The question is what computer.  I can use Labview on a mac or windows pc with Arduino to program a nice logging and control user interface but ultimately using the rPi as the computer would be a much lower cost, lower power (and cooler!) alternative.  Dunno much about Python though....

[dgd]

The sensors connecting to this box have been my interest for the last few months.  These are mostly current sensors  as I want to get some accurate readings of amps produced and consumed by the different devices.

The 500amp shunt in the MNDC looks like it needs at least a 14bit AtoD device to give 0.1amp resolution over a -400A to +400A range of readings. Such devices are readily available and quite low cost. Available on Arduino interface cards. And there often is instructions,coding examples to drive then, sometimes via an RPi.

I see it as only a short step to then use data from this shunt, clocked and stored, to create an accurate but basic battery monitor. In  conjunction with charge stage control inputs to the Classic, preferably via AUX input, there would be everything needed to deal with LiFeYPO4 batteries.

The previous threads on the accuracy of volt and amps as displayed by the Classic have raised the need for some good measurements external to the Classic. Again current in and out 150 amp shunts to measure 0 to 100 amps. 11 bit A to D here would suffice. I have also thought about amps readings for each PV string (I have 4)
..more later..

dgd

[dgd]

Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic?  Did boB get any more commands set up to
provide more config or reporting capability?

dgd

[TomW]

Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic?  Did boB get any more commands set up to
provide more config or reporting capability?

dgd

dgd;

I have been logging from it for a long while and quite successfully. I have updated the Classic and MNGP with it. I have not bugged boB for more serial port options because they were pretty busy with the Local App upgrades.

Now that I have an associate involved I expect to push boB for more technical information. I have been down with a rotator cuff injury since December and just don't get much done beyond what is absolutely necessary to get by. That is coming along nicely and full recovery is imminent so I will get back to more work on the Pi soon.

So minimal progress.

OK, boB, time to bug you for documentation on the serial capabilities and commands, I guess.

Tom

[boB]

Tom,
How far did you get with the Rpi using the USB serial port connection to the Classic?  Did boB get any more commands set up to
provide more config or reporting capability?

dgd

dgd;

I have been logging from it for a long while and quite successfully. I have updated the Classic and MNGP with it. I have not bugged boB for more serial port options because they were pretty busy with the Local App upgrades.

Now that I have an associate involved I expect to push boB for more technical information. I have been down with a rotator cuff injury since December and just don't get much done beyond what is absolutely necessary to get by. That is coming along nicely and full recovery is imminent so I will get back to more work on the Pi soon.

So minimal progress.

OK, boB, time to bug you for documentation on the serial capabilities and commands, I guess.

Tom

I will look but I think you are going to be disappointed.   There ain't much there right now.

I am going to add stuff like reading the EEprom etc.

Yeah, that's about all that's there right now.  No unix shell or cool stuff like that...

That would be pretty neat though...  How about Classic DOS ?

boB

[TomW]

Well, folks, Ross has been hammering on pieces of this project and has had some good progress happening.

He has built an application to poll the Classic over ethernet. It compiled out of the box on my Raspbian Pi and my Ubuntu 11.10 laptop. It uses no proprietary software or external libraries.

It can poll a list of registers and has primitives included for values that must be massaged for presentation.

Sample raw output:

Code Select Expand



./newmodbus 192.168.2.129 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10 4120\>8

ID �<< this will be the name you assigned the Classic but has a bug that displays it incorrectly.
4115 = 26.3
4116 = 86.4
4117 = 16.4
4118 = 0.7
4119 = 434 (0x1B2)
4121 = 5.1
4122 = 104.9
4125 = 2.7
4132 = 21.1
4133 = 47.7
4134 = 51.0
4120 = 4


it returns the processed register data lightning fast and blows away the USB dump method on accuracy and speed.

You can see where he has gone with a webpage for the Classic data here:

http://ranges.albury.net.au/midnight/classic.shtml

Hover over the values to see historic data graphed.

Just some progress on the project. Getting the data via TCP/IP was the first step.

If anyone is interested in messing with it I can pass on the binary for either ARM or  i686 / i386 Linux. Just Pm me your email and I will send it along. The code is not ready for passing on yet but probably will be when he sorts out some issues.

Tom

[RossW]

Well, folks, Ross has been hammering on pieces of this project and has had some good progress happening.

He has built an application to poll the Classic over ethernet. It compiled out of the box on my Raspbian Pi and my Ubuntu 11.10 laptop. It uses no proprietary software or external libraries.

It can poll a list of registers and has primitives included for values that must be massaged for presentation.

Sample raw output:

Code Select Expand



./newmodbus 192.168.2.129 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10 4120\>8

ID �<< this will be the name you assigned the Classic but has a bug that displays it incorrectly.
4115 = 26.3
4116 = 86.4
4117 = 16.4
4118 = 0.7
4119 = 434 (0x1B2)
4121 = 5.1
4122 = 104.9
4125 = 2.7
4132 = 21.1
4133 = 47.7
4134 = 51.0
4120 = 4


it returns the processed register data lightning fast and blows away the USB dump method on accuracy and speed.

Should have checked your mail first, Tom   Sent you the fixed code 20hrs and 3 mins ago

Code Select Expand


% ./classicmodbus `cat classic.addr` 4115-4118/10 4119 4121-4122/10 4125/10 4132-4134/10             
ID Solar2
4115 = 49.4
4116 = 90.4
4117 = 24.0
4118 = 0.8
4119 = 1192.0
4121 = 13.4
4122 = 127.0
4125 = 1.7
4132 = 23.5
4133 = 45.5
4134 = 47.8


And setting the device name is a snap:

Code Select Expand


% ./classicmodbus `cat classic.addr` 4210='CLASSIC'                                     
ID Solar2
% ./classicmodbus `cat classic.addr` 4210-4213     
ID CLASSIC
4210 = 19523 (0x4C43)
4211 = 21313 (0x5341)
4212 = 18771 (0x4953)
4213 = 67 (0x43)


And it's reasonably quick:

Code Select Expand


% time ./classicmodbus `cat classic.addr` 4210-4213
ID CLASSIC
4210 = 19523 (0x4C43)
4211 = 21313 (0x5341)
4212 = 18771 (0x4953)
4213 = 67 (0x43)

real 0m0.018s
user 0m0.000s
sys 0m0.001s


Please make no mistake - this isn't intended to be a replacement for the localapp, it's a low-level, command-line tool to get data out of the classic for logging, monitoring and alarms. It's lightweight, portable and fast and flexible. Intended to be used in scripts or with some sort of wrapper. Well, that's the plan - who knows what it'll morph into as people like Tom get their claws into it. "Feature-creep" already happened with writing, so anything's possible.

[TomW]

Ross;

I must have missed that email?

Tom