The ARM microcomputer board is the heart of the blackbox project. Whether or what form an additional microcontroller is added in, is another matter. But ARM boards have the right combination of resources and power consumption to handle primary storage and communication.
It would be good if we could accumulate what we know about each board in one place. The TBB wiki is the obvious place, but here will also do. Anyone what wants edit rights to the wiki let me know.
I will start by moving my Cubieboard1 install writeup to the wiki. I guess ordering a black and cubie2, will be the next step, and one or two of these cheap hackable android set top boxes. They have the advantage of having a case and wifi built in.
While atom silvermont has now been released i expect it will be a while before we see Bay trail (http://en.wikipedia.org/wiki/Silvermont#Embedded.2Fautomotive_processors_.28Bay_Trail-I.29) miniitx or smaller boards. Maybe next year, but they should be awsome too.
Below link has a very comprehensive matrix of ARM boards
No sense in replicating the data collection ...
We just need to determine the characteristics that are important for BB core platform
Albeit No details on GPIO (except a yes or no) .... So if we want to capture
Greater detail on GPIO we will need to look further...
http://socialcompare.com/en/comparison/arm-boards
Comparison of RPi vs cubieboard
http://blog.bulte.net/01-09-2013/cubie-board-quick-look-raspberry-pi-comparison.html
When you look at the benchmark graphs - easy to see where RPi has performance deficiencies
In areas that are important for BBP
(Not detracting of course from RPi capabilities on graphics for multimedia etc ... But these are not relevant for BBP)
Summary : IMHO cubieboard much better suited than RPi for the BBP core
Comparison of rpi vs beaglebone (not black) vs arduino
http://makezine.com/2013/04/15/arduino-uno-vs-beaglebone-vs-raspberry-pi/
In particular the summaries near bottom of article help put into perspective the relevant
Benefits and likely positioning of arduino vs beaglebone for different tasks
Note the beaglebone is not the black version, however we can generalize the beaglebone
Comments as relevant for most of the ARM type platforms (cubieboard, beaglebone black etc)
As compared to arduino
Summary: IMHO continues to support my thinking on the role of ardunio as a sensor module for BBP,
Particulary for a low cost "remote" and "distributed sensor" module
(See my separate thread on core vs sensing modules)
Quote from: zoneblue on October 18, 2013, 05:47:30 PM
The ARM microcomputer board is the heart of the blackbox project. Whether or what form an additional microcontroller is added in, is another matter. But ARM boards have the right combination of resources and power consumption to handle primary storage and communication.
Yes I see thats the way the BBP is going as far as hardware platform is concerned
I'm not sure the current ARM systems such as rPi, Beagle, cubie etc should really be the 'heart' of the BBP system. APart from the ultra low power aspect I think the resources, or lack of them, is a major restriction on doing any decent data processing.
I would be happy to use something more 'normal', eg a PC running Linux, the 24hour power needed can be significanty minimised so that power consumption becomes a non issue. Then web server, web pages, libs, C compilers, rtc, serial and ethernet comms all become so much easier to apply and manage. Working memory and storage restrictions dont apply.
Anyway, I speak only from experience of using the rPi and I wouldn't seriously give it any significant data processing to do
Or what about the BBP functionality being defined, core and desirable, then the processor options looked at to see what can be implemented on each? Is that where Gregy is heading?
dgd
Beaglebone black. ("Black") IO
http://circuitco.com/support/index.php?title=Cape_Expansion_Headers
65 digital GPIO. (3.3V) each can generate an interrupt
8 PWM and 4 timers
7 ADC. (1.8V)
4 serial UARTs (official site say "4.5" )
2 SPI ports
2 I2C ports
Accessible via 2x46 Pin expansion headers
Black has "capes" (analogous to "shields") that plug into the headers to provide expansion support
Summary : very impressive IO capability on board ...
IMHO More than enough for "local" sensing for BBP
black has the greatest "onboard" IO support (as compared to cubieboard and RPi)
DGD
Agree with your thoughts
My assumption ( but I have zero Linux knowledge) was that it can largely operate independant
Of the underlying platform (probably a gross over simplification)
And hence BPP could "scale" onto different platforms - albeit at present ARM based ?
It's clear that as each new iteration of ARM boards emerges .. The capability and performance goes up.
But certainly RPi will be under powered c/w black and cubie
but will they be enough? As number sensors increases, and as we go beyond ..
capture/log/graph .. I leave this to you Linux and programming experts (I have no clue)
I already have a HA PC (win os) that will need to run (in discretionary mode)
.. already looking at DC Power supply options To run a ruggedized lower power motherboard version
So your point has merit ...
Q; is how easy (or hard) is it to "port" it to a different Linux platform?
As to your question about where am I heading
My thinking was to define a structure that segregated functionality - that could be matched against
The respective h/w demands
Eg use arduino for the distributed sensor nodes (where low cost and low PWR are amongst critical factors)
Vs the "core" platform h/w... That has different requirements (non volatile storeage, memory, network connectivity
Processing power etc)
Im no big arm fan. For one its such a cowboy environment that debian installer isnt able to support most of these devices out of the box.
But as far as efficency goes the power consumption to cpu speed is currently unbeatable. BB pages render as quick on a 1.25W cubieboard as they do on a 20W atom.
20W, 24/7, is about as much as a fridge, so unless that thing has other core uses, NAS, backup whatever, then its not the right tool for the job. As i said i do have high hopes for the next generation of atoms, intel has finally figured out that the world has gone mobile and so i fully expect better x86 options to emerge first quarter 2014. Intel claims 3-5 times more efficient.
But i agree, the point is to make the thing portable, able to be run on ARM A8 'or better'.
However there'd be a few catchs to that if we start relying on i2c or gpio, which arent standard gear on traditional motherboards.
Meantime in terms of software development, i am currently playing a bit of a cat and mouse game, optimising, developing, optimising to make best use of finite cpu cycles. Theres plenty left to optimise so im not too worryed about it.
Power consumption is key.
I was planning a dissertation on "interfaces for BBP" in my other thread
I was working up to it ... By demonstrating the large number different interfaces across
The various sensors categories (and I just posted another!)
So i can see that zoneblue has recognized the "dilemma"
And quite correctly that some ARM. Boards have much greater GPIO than others and
Certainly mainstream intel type boards usually don't have these as native.
More and more this is pushing my thinking about separating the BBP core functions from sensors,
And limit the use of onboard GPIO on the BBP core platform
So BBP can more easily transport across different ARM and intel platforms
Which takes you to a daughter board of some kind that talks to the sensor satelite units, either near or far. Right?
Arduino plus ethernet, plus zbee, plus rtc plus ???? Or a custom board containing same????
Webcontrol wont work for that as its bus challenged, right?
Yep exactly
if you see my post on AC power energy sensing (reply #10)
http://midniteforum.com/index.php?topic=1439.msg11911#msg11911
At least one of those "daughter boards" would be the emonBASE for the Openenergymonitor
Device - with its using RFM12 wireless to get data from emonTX module,
Which effectively makes it a wireless gateway that can listen for other nodes,
In this case it's a Ethernet gateway - so no requirement of using any GPIO on the BBP core .. The ultimate daughter board .. Eg it's all interfaced thru sw over Ethernet
And as the emonBASE is based on nanodeRF - which in turn can also communicate with other sensing
Nodes wirelessly .. Then this should be able to be a generic wireless gateway for when wireless sense modules are required ... I'm still getting my head around this ... Hence why as yet I haven't posted the wireless modules and BBP interfaces dissertations in my BBP senses modules thread
... But like most of the other posts ... It's probably going to be large..ish
Sorry about all the reading ... But it's a collection of info that I'm using at least for nothing else to collect my own thoughts
Webcontrol uses Ethernet interface
So it works great as part of an Ethernet connected sensor node, but if you need more than 3ADC,
Then it's "IO challenged ". (But It does have good digital IO)
I assume thats what you meant by "bus challenged"?
Quote from: Gregy on October 20, 2013, 06:32:35 PM
Webcontrol uses Ethernet interface
So it works great as part of an Ethernet connected sensor node, but if you need more than 3ADC,
Then it's "IO challenged ". (But It does have good digital IO)
You're being a bit harsh on the WC.
1. It has 3 x 0-10V ADC
2. It ALSO has a 0-5V ADC (normally used for a humidity sensor)
3. It ALSO supports up to 8 DS18B20 sensors
4. It ALSO supports up to 8 TTL digital inputs
4a. (One of those can be used as a counter or a frequency input up to about 2MHz)
5. With the addition of a single chip add another 4 channels http://tinyurl.com/lgfu9zn (http://tinyurl.com/lgfu9zn)
Or, wait for the WC32 which support 16 TTL in, 8 ADC and 16 DS18B20.
No harshness intended
It was "only" the 3ADC case I was referring.. (And I did mention "Good digital IO")
But you raise great points
Q can the 0-5ADC be generally accessed? I may have incorrectly interpreted as "reserved for humidity"
Q: the tiny chip adds what type of additional 4ch?
What is your experience with the DS18B20 sensors on CAI?
If I understand correct, they have to be run in non parasitic mode ?
I had read that there may be other constraints introduced when running a larger number?
Slows down the sensing ? Or something along those lines?
Quote from: Gregy on October 20, 2013, 07:42:53 PM
But you raise great points
Q can the 0-5ADC be generally accessed? I may have incorrectly interpreted as "reserved for humidity"
Q: the tiny chip adds what type of additional 4ch?
The link provided was to the 20mA input device. They also make an identical unit (just doesn't have the shunt resistors) that measures 0-5V on each channel. I have a couple of those myself and it works quite well.
Quote
What is your experience with the DS18B20 sensors on CAI?
Extensive. I ship (temperature) dataloggers all over the place that use them. http://logging.net.au (http://logging.net.au)
I also make them into a fully remote/mobile setting:
(http://house.albury.net.au/19oct2011/100_5167.JPG)
These generally include a 3G cellular modem:
(http://house.albury.net.au/19oct2011/100_5171.JPG)
Quote
If I understand correct, they have to be run in non parasitic mode ?
I had read that there may be other constraints introduced when running a larger number?
Slows down the sensing ? Or something along those lines?
There is a maximum bus length, which depends on topology, cable characteristics and number of sensors. I have heaps of these things running 8 x 3m sensors in "star" topology (which is admittedly not optimum).
I believe they bitbash the onewire protocol on the WC8 boards, but use a dedicated onewire controller on the new WC32.
The longest lead I ran so far was 7 x 3m + 1 x 20m (ie, 41 metres of cable), and it was perfectly reliable. I did add a 4K7 pullup on the far end of the 20m cable though, which helped.
Hang on, architecture summary clalification time:
If we assume that the BB is colocated in the "gear room" for maximum direct connections. Its ONLY link to other gear is ethernet. If you wanna hook one or more wifi bridges to the ethernet, fine, no problem.
For links to RE devices direct connect IF they have ethernet.
What im calling the communications board is ethernet connected to the arm board, all it does is talk to as many sensor units as you have, either near or far, either wired or wireless. Greg covers options for this well above. I wasnt meaning ethernet for the sensor links, various wireless serial, very low power consumption, ideal.
For RE gear bereft of ethernet, what then? Some sort of small modular serial/usb/bluetooth to ethernet adapter board? Modbus direct rs485?
My comment about webcontroll being bus challenged is that 1 wire is it, not gona work for communications, right? Its forte is sensors, and only those in ethernet cable reach of BB.
In case none of this makes sense, heres a picture. Whats the alternative to ethernet for the main coms bus?
Ross - thanks for the details - that's great news and puts to rest my concerns over the Ds18d20s ..
And of course 1wire suffers those distance/topology constraints natively regardless.
of course now It just means I'm even more anxious for the newer model - as a combo of the
Current WC and the newer will fit very well in my "other" automation (home) project (along with its "IO shield" fingers crossed)
Hey. Nice pics and great units - I will have a look at your site to learn more of your commercial products
ZB
i knew this moment was coming at us fast - hence my attempts to put some structure around the " sensing module" discussion
and draw out the myriad of "bus options" for us to confront
Your diagram helps capture the generic structure well ...
herewith my attempt at some definitions
"RE" = a device that forms part of renewable energy system
- that can provide external access to its status and data on its operation either directly of via an adaptor
(eg PV Charge controller, battery charger, inverter, generator)
"adapter"= device for protocol conversion and interfacing to open or proprietary RE device
"Local sensor board" = ethernet connected hw interface that provides GPIO/special interfaces for connection of various sensors
(note this could also be a remote sensor board ... by extending the ethernet to outside)
hmmm need to think about calling this "local"
should it be renamed "ethernet sensor board" ... and put a block in each of both local and remote (BBP will not know or even care if
its local or remote, nor how its connected)
IMHO
1) ethernet
as shown is one of the options - no question - it covers various readily available modules we have been discussing
examples (using my proposed modified naming in diagram)
"ethernet Sensor board" = Webcontrol
"comms board"= emonBASE (because it has wireless capability for remotes, and also potential to add other sensing nodes)
2) comms board ... more to come
oh just realised
should the generic diagram constrain adapter be connected only via ethernet - or direct also?
example
RE= midnite CC
(uses modbus over RTU TCP - so it fits your current diagram) - ok
but will there be cases where BBP might need to interface direct via serial or similar adaptor?
perhaps for present best to limit it to only via an ethernet interface?
.. up to you
Well i dont know. How many devices (that we care about) do not have ethernet? Outback pre mate 3 is probably the main RE device that comes to mind. The possible downside is having to support usb/serial/usb-to-serial converters of various brands, direct to various unknown arm boards. Hence my idea of an adapter board, that would reduce the variables. But this is all just thinking out loud, its not something i have enough ecperience to say teriibly cateogrically either way.
I think we ought to make a short list of "supported hardware" or lets say priority hardware at some point. Controllers, midnite, outback, schieder, morninstar. 2 and 3 require addons, the latter i think is serial only.
Sunny island, Conext, Outback, top three inverters. All three have their own ecosystem, and accessorys, that may duplicate or overlap BB functionality. However the point of BBP is to integrate everything.
Then theres the sundry items, like serial enabled battery monitors etc. Probably the path of least resistance is an unpowered usb hub off of the arm board, and usb-serial converter to rs232 only RE devices.
yep
exactly why i threw it to you :)
... because it becomes a nightmare as to how many and how to support
I agree - limit it at present to the most popular ... and constrain to ethernet access
(so keep your diagram as drawn for the adapter )
.. any thoughts on my other comments on the diagram and definitions?
just to link the two parallel discussions
have a look at the last couple of posts in my sensor thread
http://midniteforum.com/index.php?topic=1439.msg11950#msg11950
http://midniteforum.com/index.php?topic=1439.msg11951#msg11951
Im converging on a proposal for your consideration - that at least one candidate for the "comms board"= emonBASE
It provides a ethernet "gateway" for
- emonTX (4 x AC power flow measurements)
- remote wireless nodes inc (so far):
emonTH (humidity and temperature)
low pwr sensor and Tx node (TBC) https://shop.wickeddevice.com/product/assembled-low-power-sensor-and-transmitter-node
Jeenodes?
Im still time constrained this week, should ease next week. In the weekend i want to combine your hardware research posts into a single wiki page, and hopefully in the process get to digest it.
Your comments on architure sound fair enough to me.
Something that occured to me is that the role of ethernet has more factors than ive listed so far:
- bear in mind im a coder, ethernet is what i know == bias.
- past 4/5 ports we max out all common wifi bridge hardware such as the venerable linksys setup like ross uses. Thats a pretty common setup. 4/5 port hubs ditto. As drawn you would need a 5 port wifi bridge plus a 5 port switch. Or an 8 port switch. These two devices will use more power than the rest of the hardware combined, maybe even twice as much. There are a couple of low power wifi routers on the market, but the adafruit wifi shield uses 1.5W active, so thats probably a baseline.
- with the exception of the client legs, none of the sensor stuff needs anywhere near 100Mb/s bandwidth, so the power use is wasted, as is isolation and other benefits, given that all that gear is running in the same facility and of the same earth bus.
So could a combination of ethernet and something else (i2c, or spi, modbus even) work? Limit ethernet for ethernet support RE gear, the arm board and the eth link to clients. Thats 3-5 ports. Incorperate into the coms board one of the serial protocols listed above to communicate with the other baords ???
ZB
ive been updating the module structure (post #1 in my sensing module thread)
so if you feel its useful - you can use it as a basis for the wiki to bring structure to
BBP both hw and sw modules for sensing ? (note it needs the commenting scraped away)
i will make an attempt and try to post it or Pm it to to you as a formatted text file - for you to
adapt as you see fit for wiki
Alas the weekend got absorbed rearranging our DC disconnect for the deltec and various (spring) garden projects.
But i did get round to tidying up our blackbox gear, from what was a untidy tangle of wires in teh corner of my desk, to what is now a sort of slightly tidier bread board type setup.
Watt meter confirms that the ethernet switch is the biggest power user by far.
Cubie with 1 ethernet, 1.2W (no ethernet plugged, 0.7W)
Switch with 3 ethernet 2.2W. (no ethernet plugged 0.6W)
Inclusive of the pair of dc converters(5V,9V), high 90s eff. 3W total so far, and two spare ethernet ports, webcontrol mounted at bottom for testing, space for arduino/whatever coms link to outdoor sensor box bottom right.
Cubie had 80 days up on it when it was uncerimoniously unpowered to rewire it.