Power Cord User Interface Design.

Using the power cord as a user interface, UI, from the MIT Tangible Media Group, is interesting in many ways:

• Transparent design ala Norman.
• Energy monitoring and such (why not also put in a current monitor?).
• Microcontrollers and embedded systems. Related to IoT

Have always been in favor of cables... Like 802.3af Power over Ethernet, Standard USB power.

Ethernet as an Internal Bus for Internet of Things, IoT, Embedded Devices.

Ethernet and TCPIP are already regularly used as internal buses in large NAS systems. What about taking this model to embedded devices for IoT?

Backplane = Ethernet hub/switch - ala D-link GO-SW-5E (5VDC powered - roughly $15)  (or even a Mikrotik 750 router)

CPU with direct Ethernet = SoC ARM or x86 based compute and database engine - Intel based (Galileo, Minnowboard), Beagle Bone, 86duino, Raspberry Pi...

Bus controllers = Lantronix xPico classic.

The last part is the key piece. It can even in some cases be the CPU too. Platform specification for IoT often gets into nitty gritty I/O capabilities. This sometimes diverges into onboard or outboard coprocessors like TI Sitara's PRU, serially connected Atmel or PIC microcontrollers, special function chips like advanced application specific UARTs or communications units (think oddities like ARCNET, HomePNA, unusual RF, etc.)... and sometimes even to FPGAs. Usually these pathways take one to very specific/special specifications.

Ethernet is a natural actually - having:

• Isolation.
• Variable bandwidth.
• Wide "driver" support.
• TCPIP support - for web GUI and standard protocols/frameworks like XML, REST and layerable security and filtering.
• Various forms of pre-existing transparent, web configurable, "driver-less", pass-through devices.

Ethernet was formerly too expensive. Look at the price of xPico. And Ethernet suffers from being thought of as a LAN bus (distances of 1-100M). Instead think of it like CAN, I2C or SPI.
 
Bus power? One can go:

• Power over Ethernet 802.3af on the high end.
• Passive Power over Ethernet (with 3V-12V over short distances).
• 5V - USB being the current best flavor of 5VDC - Common EPS.

Alternatively, think of the xPico as a replacement for a PLX PCI9030 or a PLX PEX8112
or various forms of "bridge as IP cores" to be fabbed on demand. Without the fabbing, minimums, BGA assembly, and so forth.

New Devices – Just Give us the Pins and APIs

Recently blogged about the renaissance of the DIY electronics pathway.

http://albertputnam.blogspot.com/2013/12/renaissance-of-diy-electronics-store.html

Now one can find modules for almost any function - at near instant mail order and even at a local retail outlet.

That speaks to a message that needs to get to the developers of new chips and modules for connectivity and core or ancillary functions. The release of such modules often involves a CPK (programmers kit) to the chip or module API – fair enough. The supplier company often releases a development kit - which has a reference design board, their module, a power supply and various cables, and a DVD or CD with the CPK (or more lately a slip of paper or QR barcode code with a website link to a CPK download *grin*)

The new paradigms of modules at retail screams out to stop building/providing hardware development kit boards - with UARTs and LEDs and converters and drivers power connectors and all such do dads, plus saying nothing of CAD and revisions for a reference design.

Suppliers - just put your chip or module on a carrier with pins (at human scale with 0.1” or 2mm spacing). Make your reference designs utilize other modules. Refer to said modules specifically if you like.

The only things the developers add are

A. wire interconnects between modules (and the developer at the end gets to choose which modules to use). There is no harm in a reference /design/, just do not make it the defacto only thing the developer can use as hardware.

B. code interconnects between module APIs.

The work in development becomes the interconnection for pre-existing functional blocks with accessible API and pinouts. There are some nice USB (and other protocol and wireless) bridges developers could really go to town with given accessible pins. This is to say nothing of a fair bunch of embeddable microcontrollers. Get humans something to get humanly started. Then the design wins will come.

Modbus Base Camp for Devices

If I were to make an appliance/device/meter/controller today, I would make it speak Modbus. You will note I have not defined my domain, market, breadth, nor whether wireless is needed, nor whether it is a consumer or end user application or for the enterprise.

The Modbus assertion is the aggregation of the nuances across the board… all the way from the level of hacking together a small Arduino http://en.wikipedia.org/wiki/Arduino based controller for sensing the kitchen window open - through medium sized embedded Ethernet controllers based on something like Lantronix Xports http://www.lantronix.com/device-networking/embedded-device-servers/xport.html - to the level of large equipment controlling real world industrial and mechanical processes for large enterprises (like entire agencies of sovereign entities).

Note that I have not specified Modbus over RS485 or RS232 or TCP/IP; nor have I specified layered ways of transporting the protocol (like Ethernet, Wireless and Fiber).

One can poke at Modbus saying – no security, no object model, and little structure. Modbus’ beauty is in its simplicity, and in that one's needed features can be overlaid. Two of my favorite overlays are BACnet and XML, but even these can be said to incompletely address concerns about security and standardized device model representations. But again, one can overlay, and for those who do not even understand what a “standard device model representation” might get them, they can have Modbus now, and deal with that issue later, once their understanding deepens.

Dealing with Modbus “now” is what it is all about. One way or another, with a public Modbus profile of implemented functions, and register map, for a device, one can get connected and talk to it. Systematic functional understanding can be overlaid as one learns.

Some have taken up the Modbus banner. Temco controls has done so in fine fashion http://www.temcocontrols.com/ .

Most meters have Modbus interfaces. Here are a few (in no particular order and without effort to be complete):
http://www.electroind.com/shark.html
http://www.eaton.com/meters
http://www.powerlogic.com/productcategory.cfm/c_id/1

Appliances that consume electric/gas/water (washer/dryer) and all things renewable (solar, inverters, wind, nano-hydro) should take up this banner. Appliances do not appear to be going towards HANs fast in any case. But the Sunspec Alliance http://www.sunspec.org/ is notable for placing at least some basis on Modbus (as well as more forward looking XML).

See my recent article in the December issue of Automated Buildings on making a small BACnet device where Modbus as a stepping stone is alluded to http://www.automatedbuildings.com/news/dec12/articles/cimetrics/121122110404cimetrics.html .