A Forum run by Enthusiasts of MidNite Solar

The Open Source software/hardware corner => The Black Box project => Topic started by: dgd on February 13, 2015, 07:33:53 PM

Title: Blackbox design
Post by: dgd on February 13, 2015, 07:33:53 PM
I managed to borrow a BBB for a week and that allowed me to get familiar with its capabilities. Returned now so just waiting on one from Element14.
I have also been thinking about a black box design using the BBB.
Basically what I am looking at is a web server, reasonably graphical not too dissimilar from the MyMidnite data screen and using the BBB for this. Web server software and lots of info on designing it for BBB is freely available.

However it is the data acquisition part that is different. I have noted the obvious frustration with the poor ethernet connection reliability of the Classic. Its being improved and boB sounds confident the 2+year quest to nail down the unreliability is coming to an end.

I have now managed to implement  modbus RTU, serial modbus via rs232, on various Arduino systems. One of these is using a minimal Arduino NANO to extract Classic data and store it is timestamped order on a micro SD card, 8Gb. This seems to work well and I have set it to take data every minute. One days data at this time resolution is stored then older data is reworked to 10 minute intervals for longer term storage. 
On viewing the data stored it may be possible to improve storage efficiency by not storing complete data if it has not changed since last reading, instead just storing a flag denoting same as previous reading. This would probably save a lot at inactive middle of night times.

The BBB supports I2C communications as does the Arduino. This is how they would communicate data, the BBB would only request stored data as needed when a client web request occurs. I can see this would allow several NANOs to talk to the BBB, one dedicated NANO for each Classic for data acquistion leaving the BBB to do the web management and serving of data.

The Blackbox would consist of the BBB and one or more Arduino NANO each name connected via rs232 to a CLassic and the ethernet on BBB being the network interface.

So far I have the NANO part all working and I have tested the i2C comms to the BBB and it works too.

Any suggestions or thoughts on this please reply  :P

dgd
Title: Re: Blackbox design
Post by: ClassicCrazy on February 14, 2015, 02:29:26 AM
I wish I knew enough to help on this project but I have below beginner linux skills.  But as a public service I will decipher your BBB  for anyone who does not know what that means - Beagle Bone Black
http://www.adafruit.com/products/1996
Title: Re: Blackbox design
Post by: zoneblue on February 14, 2015, 10:47:10 PM
I think youll find an ardunio will struggle resource wise, ram, eprom etc to do what you want it to do. Ardunino will run ethernet/wifi, just, at a pinch, but forget trying to do much with it. But there soulcd be merit in running an arduino in combination with a linux board, if you blow the nano up its only a couple bucks!

Moving up to BBB, or the new rPi2, or one of cubies, will make things easier, however best read my various scratchings on teh subject to understand the resource issues there. SD card life is a key one.  The current codeline reads each second, and creates 1 minute series from that as well as daily summaries. Still lots to do though.



Title: Re: Blackbox design
Post by: dgd on February 15, 2015, 02:13:06 AM
Interesting.

I have reborrowed the BBB and having played with it plus reading a fraction of the owner comments it seems that its main redeeming factor is that it costs $45. A great low cost learning tool but I struggle to see why it is preferable to an i5 or i7 computer with several gigs of memory and a proper reliable storgae media (eg SSD).
When I look at the Arduino design it certainly seems fully adequate at being a simple web server for a Classic. After all from a 'useful' data viewpoint are we not just talking about a couple of voltage and current readings, all up maybe a dozen useful data.
Without  a proper OS it would be limited as a more sophisticated web server, but as a data collection and storage device it is an excellent choice I am working on the micro SD card storage part, nearly finished, and also an input web page to setup the various parameters needed by a lite, that is, replacing the MNLP.

I liked the I2C interface to the BBB, but maybe it is more suited to post processing Classic data into those nice graphs you have made rather than doing the data aquisition (once a second did you say?)

Then again if boB fixes the Classic ethernet reliability then all my efforts with modbus RTU will be  somewhat redundant.

dgd
Title: Re: Blackbox design
Post by: mtdoc on February 15, 2015, 02:21:48 PM
I think the advantage of using the BBB or similar lies in the much lower power consumption. Obviously one faces a choice, depending on needs, requiring a balance between processing power, memory/storage and power consumption. Of course price is a factor as well.

For me the utility of an arduino or similar low cost/low power MCU is as an intermediary data collection/serial interface between my Classics and a more powerfull computer where I can integrate and display data from both Midnites equipment and my Outback equipment.

Which more powerful computer I use - BBB, rPi, other small ARM based solution, Atom based netbook, or full laptop depends on how i choose to balance those factors.
Title: Re: Blackbox design
Post by: TomW on February 15, 2015, 06:26:52 PM
Was hoping to participate in the BBB end of this effort.

Problem is I just sent back my second failed Element14 BBB. Both failed with same boot error about accessing pin 21 on device. Seller or internet could offer no info on what it is hardware or software, me or the BBB  but I am not going for a third unit.

Still got a couple rPi's tho.

Too bad, the BBB were nice machines  while they worked here.

Not sure how long before I get any permits and stuff for a system at the new place but Spring at the earliest.  That means nothing to monitor until then.  ;D

Will be watching the progress, however!

Appreciate you guys sharing this stuff.

Tom

Title: Re: Blackbox design
Post by: zoneblue on February 15, 2015, 09:06:13 PM
Well the cubieboard i originally bought to try out has been running 24/7 for going on two years now. I rebooted it maybe twice, and replaced the (cheaper) sd card once (with a better one). There are now 4 differenct cubieboards to choose from , see ebay, amazon, or various places. The only thing is They come with android by default, so you need to download and burn a "Cubian" debian OS image, but thats pretty easy, xplained here: http://zoneblue.org/cms/page.php?view=cubieboard-and-debian






Title: Re: Blackbox design
Post by: dgd on February 15, 2015, 09:33:22 PM
I have followed ZB's development of the black box concept and the use of a BBB in that project. The graphs he produces from collected data look very professional. The usefulness of them is not doubted as more than a few times they have been used to identify anomilies and possible or real problems with the Classic.
To collect sufficient and ongoing data that means the BBB is probably permanently running and connected to a Classic via tcp/ip, of course using up the only connection the Classic can provide.  :(
I also understand the desire for lowest power used by any permanently connected device.

I will hopefully soon own a new BBB. The get the Arduino data collectors I2C connected to it. An important aspect of this project, for me
is that the only permanently connected devices will be an extremely low power Arduino with micro SD, serial and ethernet on EACH Classic.
The BBB will only collect data from these when I want to post process it into graphs etc.
I'm not sure I would want to have a 24/7 BBB online as a web server as I dont see the need (for me) to web server out analysis graphs etc.
The simple snapshot, refreshed every 10 seconds, with the Arduino web server would be sufficient. Maybe a second page of a the days summary of data.

dgd
Title: Re: Blackbox design
Post by: zoneblue on February 16, 2015, 01:02:13 AM
Quote from: dgd on February 15, 2015, 09:33:22 PM
To collect sufficient and ongoing data that means the BBB is probably permanently running and connected to a Classic via tcp/ip, of course using up the only connection the Classic can provide.  :(

Well teh point of BB is to provide data to other users, hence you dont need another connection. Mymidnite is always free, so thats an option.  You also dont have to tie up the port if you do read, open close. And, well theres nothing to stop you connecting over serial, those arm boards have several UARTs on baord, plus a dedicated TTL port, plus usb. Take your pick. However note than rs232 is slower, and there wont be much if any time left over once you have read the full range of register range each second, to do much with it. If you can be more picky about which registers you want and just buffer the data, for processing later, itll work fine. Seems sensible if you are targeting lite uses with no mngp to compete with.

Another option is of course if the ethernet stack issues get resolved is to use  a connection that only opens breifly, allowing others in. Ive built a function into BB, that disables it, long enough to use the local app. However, i think a better route is to build config into BB, and avoid teh need for local app.

Quote
I also understand the desire for lowest power used by any permanently connected device.
I will hopefully soon own a new BBB. The get the Arduino data collectors I2C connected to it. An important aspect of this project, for me
is that the only permanently connected devices will be an extremely low power Arduino with micro SD, serial and ethernet on EACH Classic.

Id be interested in real world power figures for BBB. As for arduino, low on its own but did you measure it with ethernet sheild? Most/all ethernt ports use about half a watt for the isolation circuitry. Id also be interested in figures from your sheild. Personally i dont think 1.25W is that onerous for the BB, not when it gets you access from as many clients as you want anytime, realtime charting etc.

Quote
The BBB will only collect data from these when I want to post process it into graphs etc.
I'm not sure I would want to have a 24/7 BBB online as a web server as I dont see the need (for me) to web server out analysis graphs etc.

Wells there is a precendent for your proposed architecture. Typically these sort of solutions would use a hosted server in a datacenter to do the UI side of it. Gets you simple access from anywhere in the world, and the microcontroller just syncs hourly on a push basis.

Linux baords take ages to boot, and better left on. Thats their thing. Id youre going the home server route, youd might consider not using a dev board but something like a atom NUC, something more capable, and that can be used for other things.  Well hey, you can use it for weather station, home security/automation, skys the limit.
Title: Re: Blackbox design
Post by: zoneblue on February 16, 2015, 01:06:48 AM
On the dev board front there is a brand new rPi out, which brings it more into line with the sort of specs that BBB/cubie have offered for over 2 years. Still no sata though. Theres a Pi knock off called banana pi that has sata, and gigE. 
http://linuxgizmos.com/sbc-mimics-raspberry-pi-has-faster-cpu-adds-sata/

I had a quick look for cubieboard2 on ebay, USD 65 bucks delivered.
http://www.ebay.com/itm/Cubietech-Cubieboard-Allwinner-A20-SOC-MiniPC-Cubieboard2-extended-pin-interface-/321406619711?pt=LH_DefaultDomain_0&hash=item4ad553d03f

and aliexpress have a good deal going:
http://www.aliexpress.com/item/New-Arrival-PC-Cubieboard-A20-Dual-core-Development-Board-with-Power-Cable-SATA-Wire-USB-to/1634976465.html

USD 63 and change gets you the usual stuff plus a free case, and a free USB-serial adapter (those are useful extras worth about 20 bucks)

For those that noted my x86 preference, what became of atom silvermount, you ask... well, intel went its pricey consumer ddriven settop NUC route, which is a pity becasue they used to make some nice mini itx atom stuff.

However a couple of products caught my eye:

MinnowBoard Max
http://liliputing.com/2014/03/minnowboard-max-99-intel-atom-powered-single-board-computer.html
http://www.minnowboard.org/meet-minnowboard-max/

Seems to be a community driven intel cpu dev baord. Interesting. E38xx series CPU, 22nm bay trail embedded. thermal around  6W nominal. Looks interesting.

Intel did briefly make a bay trail NUC, but later upgraded it to haswell.
http://www.legitreviews.com/intel-nuc-dn2820fykh-bay-trail-system-review_135053

Asus Vivomini
http://www.asus.com/ASUS_VivoPC/VivoMini_UN62/

Another NUC, but on teh cheaper end. Haswell chip too.

If ARM agravates you then these sort of intel based products are options for little extra cash.

Title: Re: Blackbox design
Post by: mtdoc on February 16, 2015, 02:01:56 AM
Quote from: zoneblue on February 16, 2015, 01:06:48 AM
On the dev board front there is a brand new rPi out, which brings it more into line with the sort of specs that BBB/cubie have offered for over 2 years. Still no sata though. Theres a Pi knock off called banana pi that has sata, and gigE.  http://linuxgizmos.com/sbc-mimics-raspberry-pi-has-faster-cpu-adds-sata/
Don't forget the Odroid products (http://www.hardkernel.com/main/main.php)

Their C1 is only $35 and it has better specs that the rPi2 (though not the extensive user community.)

There's lots of options out there.
Title: Re: Blackbox design
Post by: dgd on February 16, 2015, 06:03:46 AM
The spec for that cubic 2 board was just nice for what I want, ESATA and I2C as well as decent dual core CPU and a gb of ddr3.
Bought one and won't bother with the BBB now  ;D

Dgd
Title: Re: Blackbox design
Post by: dgd on February 17, 2015, 09:50:22 PM
I looked through the info on the progress of the blackbox project and noticed a quite high sampling rate, using newmodbus, of the Classic registers. It appears that a one second rate is being used.  Why so many samples? would one per 5 seconds or even 10 seconds still not provide sufficient detail AND catch any important events?

dgd
Title: Re: Blackbox design
Post by: zoneblue on February 20, 2015, 06:23:20 PM
Good question. It is adjustable. What happened was this. When i was doing 60s samples using ross's original newmodbus, (open read, close) the classics network issues would drop about 5% of the samples, and then lockup after about 14 hours. With 3-5 minute samples i could laregly make that all go away. However at the time i was working with cron which has a one minute logical sample rate. In rewriting newmodbus to work as a daemon (open read and stay open), that gave me sub 60s ability. I asked andrew and he said 50ms was the lower limit, and so i just thought well 1s seems the obvious candidate. That would give us two things: a real time data, using ajax type UI functionality. When you turn a heavy load on , youll see the results more or less instantly. Not have to wait a minute. Secondly, the classic firmware, has some trouble tracking soc, due to the reset issue. I figured i was going to have to write my own SOC datapoint, and that would require fairly quick sample rate to get the accuracy.

Thats the short answer. 1s sample rate does increase power use, network traffic,storage requirements and other things. Local app uses 2s sample rates. Thats a possibility.

Currently what happens is the 1s data is put into a ram drive where it sits for 60s, when the last result is inserted into the database. My intention was to add averaging for that at some point. Then once a day the entire days 1s data is agressively compressed using bzip and written to sd card. (this is the entire register range which is useful for debugging purposes, or study of unusal load events.) I plan to further reduce the database writes by storing the 1s samples to flatfiles. They are static, with no need to be rewritten, hence much of the advantages of db storage are lost. Instead the db will be used for summarys and agregations.
Title: Re: Blackbox design
Post by: xsnrg on February 20, 2015, 06:34:16 PM
@zoneblue, have you considered using rrd for your data storage?  It's back-end data store has been very compressed and optimized over its long life, and it can inherently take care of the tasks of averaging datapoints, configured to do so based on true rolling average, average peak, etc.  You can also extract the data back out of it quickly if you ever need to.

[url]http://oss.oetiker.ch/rrdtool/[url]

Nice work on the project.

Jim
Title: Re: Blackbox design
Post by: dgd on February 20, 2015, 07:17:25 PM
I was looking at 5 readings per minute (1 per 12 seconds), averaging to one minute, storing  and I2C sending  from Arduino Nano to Cubie.
Ok, it might miss some fast changing events but for reporting/graphing purposes that would not be important

The ATmel 328 has 1K of eeprom and from the specs I see it has 100,000 writes life (the 32k flash for program storage, has 10,000 writes)
So working with a 32byte maximum, but probably smaller, record being stored, that eeprom space would accomodate 32 records, ie 32 minutes of data before starting to overwrite.
One write per 32 minutes would make a life of 100,000 * 32 minutes, 3,200,000/1440 days which is 6 years
Reducing the record size or increasing the one minute dt resolution would significantly increase that six years although replacing the NANO would be no great deal  :D

This would avoid that whole bothersome SD card thing and its potential problems.
I could envisage the data from the NANO being taken by the Cubie and stored on SSD media on its esata interface. That would take a load off the ethernet

dgd
Title: Re: Blackbox design
Post by: zoneblue on February 20, 2015, 11:56:44 PM
rrdtool is primarly a graphing tool. Thats all handled by the BB web app, and likely to go javascript graphing ultiamtely.

I considered a lot of things, in memory databases included. Much of the decision boils down to how many writes there are to sd. If you can get that down to a megabyte every 3 hours, the sd card should last. Much else and it wont.

Quote from: xsnrg on February 20, 2015, 06:34:16 PM
@zoneblue, have you considered using rrd for your data storage?  It's back-end data store has been very compressed and optimized over its long life, and it can inherently take care of the tasks of averaging datapoints, configured to do so based on true rolling average, average peak, etc.  You can also extract the data back out of it quickly if you ever need to.

[url]http://oss.oetiker.ch/rrdtool/[url]

Nice work on the project.

Jim
Title: Re: Blackbox design
Post by: RossW on February 21, 2015, 12:46:25 AM
Quote from: zoneblue on February 20, 2015, 11:56:44 PM
rrdtool is primarly a graphing tool.

Disagree, entirely!

The RRD in RRDtool stands for "Round-Robin-Database"
rrdtool is first and foremost a set of tools for the collection, summary and storage of data.
The entire rrdtool PACKAGE includes rrdgraph, which is a graphing engine that primarily uses data from various rrd databases, along with calculations if required, to produce graphs.

(I've been using it extensively for almost 15 years)
Title: Re: Blackbox design
Post by: zoneblue on February 21, 2015, 12:51:36 AM
Each to their own, ross!

Not sure how any of that helps, dealing with write sensitive media, and  needing to do a lot of processing and presentation, ie web app, that rddtool cant do? Go ahead, enlighten me!
Title: Re: Blackbox design
Post by: RossW on February 21, 2015, 01:37:49 AM
Quote from: zoneblue on February 21, 2015, 12:51:36 AM
Not sure how any of that helps, dealing with write sensitive media

I'm not saying it actually helps, I'm just saying that "RRDtool is a primarily a graphing tool" is manifestly wrong.

RRDtool (rrdgraph) can generate graphs ON THE FLY without any writes, so in that regard, it's not unhelpful.
I do agree however that anything that needs to be able to store data in a nonvolatile manner, with limited disk write life, is a challenge. The best I can suggest is some I2C or SPI battery-backed-RAM. With unlimited write cycles and very fast access times, it's the answer. With a supercap, it should survive weeks without power, maybe years. Yes, it's more bits and more expense, but just possibly the small additional initial cost is outweighed by the significant operational benefits?
Title: Re: Blackbox design
Post by: ClassicCrazy on February 21, 2015, 09:56:43 AM
I like the discussion because I never would have had a clue to all the design and programming that goes into makes hardware and software function. 

This and the other networking discussion going on is fascinating to see as an outsider to understand all the technical details involved.
Title: Re: Blackbox design
Post by: dgd on February 25, 2015, 05:42:02 PM
It seems I have been caught by the Chinese new year holidays as my Cubie has estimated delivery at end March to early April. Bummer  :(
So to keep things Blackbox interesting I bought an Arduino Mega2560 to play with, gave up then got an Arduino DUE. This is much more interesting as its based on the Atmel ARM Cortex M3 cpu.

I was trying to get one web page that displayed info and running data on two or more Classics but even with the Mega2560 4 h/w serial ports and an rs232 connection to each Classic the task proved near impossible. Running two or more parallel modbus processes (state machines) was just not going to work because the modbus RTU timing and retrying is very timing critical. Definitely in the bloody difficult category  :-\

Anyway this is not really what modbus libs were designed for. The topology is for multiple slave devices on one bus where each device ID is unique and a master's state machine can poll them as required.
The Classic only provides rs232 serial which is a point to point physical layer so proper multi system polling over rs232 appears (is) impossible.
So to progress with this use of serial communications I have installed several rs485 converters on Classics and have an rs485 arduino shield that I used on the Mega2560
RS485 is a serial connection which can connect multiple other RS485 devices to a shared physical cable (bus) - better descriptions on google

The RS485 for Classic is a bit more tedious to implement. I have used a small MAX232 pcb (that also has the needed max232 circuitry) to shift rs232 signals to TTL logic levels then connected another TTL to RS485 converter ( that uses a MAX485 and required circuitry).
These tiny converter circuit boards are from Ebay and cost a dollar or so each - and most importantly they do seem to work.

The next stage is now getting the modbus lib on the Arduino M3 to extract the data from several rs485 bussed Classics and present it in a not so simple web page.
I have noticed that even just the 16mhz Mega2560 cpu can do a simple web server page refresh rate of about once per 4 seconds, Getting pretty close to a real time display.
The first couple of tests using rs232 on the 84Mhz Cortex M3 get this to nearer every 2 to 2.5 seconds, I have not done the sums yet but maybe this is approaching the rs232 baud rate capabililty or past it already, or maybe not  :)
Perhaps if I replace the sketch usage of FLOAT types and do string/integer manipulation to display Classic data numbers not only would the annoying trailing real number zero after the decimal point be gone but the script might run even faster for a few millis faster page refresh rate  :P

dgd

Cheeky note for boB, next revision of Classic change one of those rs232 serial ports for RS485, betcha its dead easy to do  :)
Title: Re: Blackbox design
Post by: ClassicCrazy on February 26, 2015, 09:53:17 AM
A lot of this is over my head DGD but it is something I want to understand.
You connect the Arduino DUE to Classic serial  - same one that the firmware programming  uses ?

Is the reason you are using the RS485 because you want to talk with more than one Classic ?  Otherwise just RS232 port would be good enough for one Classic ?

The Arduino then runs the modbus program and asks for data , such as voltage register  and gets this every 2 seconds . When it gets it then the Arduino program will convert it to what we can read as voltage . Then what happens to the data ?  Displays on monitor attached to Arduino and or another program running on a Linux computer like Raspberry Pi or Beaglebone Black will make this available on web server as a graph  ?

Thanks,
Larry

Title: Re: Blackbox design
Post by: dgd on February 26, 2015, 03:49:01 PM
Larry,
The arduino connects to one of the rj12 sockets which you can see when the cover is removed from Classic. Usually the MNGP or MNLP plugs into top one and the other two get used for follow-me.

Rs485 because it's a bus type wiring so multiple classics could connect to blackbox.
It seems to be an industry standard with modbus communicating devices. The classic, however, went with simple 3wire rs232, I assume because it was only intended to connect an MNGP and any multi classic setup would use ethernet for data gathering.
(Being an ever optimist I was waiting for boB to reply saying that rs485 was already available by writing some undocumented configuration register(s) then one rj12 would become the 4 wire rs485 connector)

The arduino becomes a modbus master device and requests data from Classics slave.

The data can then be stored in some way, short term eeprom, SD card, USB drive etc.. Then possibly sent to a more suitable computer system for longer term storage, analysis and reporting/graphing.
Eg the excellent graphing/reporting from zoneblue

No monitor attached to arduino. It can present the data, almost in real time, via a web page. You just connect your web browser to the arduino and a snapshot page of data, refreshed every 5 seconds, appears. It's not a very sophisticated display, no graphics with analogue meters etc. but contains all the essential data to monitor a working Classic and battery bank if WBjr attached to classic.
For a single classic the arduino web server works nice, as detailed in that forum subject.

The web server that integrates data from several classics in a similar page is where I'm more interested. Almost done too so will hopefully get full description of hardware and program listed under arduino forum soon  8)

Dgd

Title: Re: Blackbox design
Post by: ClassicCrazy on February 27, 2015, 08:47:56 AM
   Okay - thanks for explanation. Hopefully in the future there will be some kind of  do it yourself port so all the communication and monitoring hackers can have at it without too much fuss. Seems like if there was a simple jumper or hardware modification to enable the port that might take care of security concerns - only those who made the mod would have access.