Solar Super Capacitor + Battery or Application.

Have seen lots of buzz around supercapacitors from IDTechEx.
Have mentioned them before in blog.

Beginning of 2014 saw news of new work on graphene devices.
Graphene solar cells.
Graphene supercapacitors.

How about combining the two? The core idea is to store the charge right where it is being generated, and cut down on transmission inefficiency while making the cells "flywheel" through darkness. And at the same time cut back (to zero) on all the voltage and amperage regulation needed for current (no pun intended) systems. Photovoltaic cell voltages are well matched to ultra-capacitor ratings.

If the graphene hybrid is too forward thinking, then go simply with standard commodity (cheapest) solar cell (say a nice 3-6W wafer or two - each 0.6V at 4-8A) and a big 5kF supercap. Now admittedly: The capacitor is big. It is heavy. It is only holding around an Ahr (integrating voltage). Alone, it is not for mobile applications. The /charging/ time constant is reasonable. Discharge depends on load and leakage.

However, the supercapacitor has an excellent temperature profile (can stand heat under a solar cell and cold in artic conditions), and excellent power density (can delivery a big power surge to a starting motor or...). The supercapacitor also offers an excellent front end for a battery hybrid. And the batteries can get you the next two orders of magnitude of raw storage... if they can be in a cooler place behind the refuge/buffer of the supercapacitor.

From there, there are other opportunities... Consider the atto or femto grid... Deliver solar photovoltaic energy - continuously - day and night - to directly attached fans and cooling units (eventually efficient solid state Peltier?). Maybe use the first coolers to keep battery array temperatures stable? Keep the high current distances down to under a metre.

Serial Bridges... Preparing for the Internet of Things (IoT).

Many embedded applications come down to I/O with "lesser" serial bus on one side (sensors via I2C or SPI or something straightforward like Modbus) via an intelligent agent which then interacts with a "greater" serial bus on the other side (like to a stateful serial protocol like BACnet MSTP, Profibus, ARCNET or even Modbus or USB). This is the essence of a serial bridge.

Most embedded developers pick a micro controller they are familiar with and go directly to work building their bridge.

What if one instead envisioned first how such a bridge could communicate via the Internet of Things?
That is to say - What if one envisioned a TCPIP and web interface from the start?
The web interface would be used for
- startup and configuration (minimizing dip switches and other UI hardware)
- ongoing status (minimizing indicators and hardware UI)
- "dip in" protocols to watch data flow - like RESTful interfaces (MTConnect, Sunspec and others), Modbus TCP and various XML schemas, or even simple .CSV data log files.

Basically one minimally needs two serial interfaces and a TCPIP (Ethernet or Wifi) interface.
[Wifi is a tiny bit harder to auto-configure - but not impossible].

The big problem was always price for TCPIP. And this was usually made worse by the fact that the TCPIP part was an after-thought or add-on - which had to be engineered /into/ the bridge. So what about taking a (cheap) TCPIP intrinsic part and using it "incidentally" as a serial bridge?

The Lantronix xPico is an embodiment of such a bridge, and a particularly "right sized" and economical version. Small ARMs and some recent x86 (Vortex86, Intel and VIA) are getting close,
but none have the sharp focus of the xPico... it being a child of a programme for TCPIP to serial bridging, which just recently branched into multiple serial. There are other small TCPIP UI systems with possible multiple serial... like Moxa and Digi. It is just that the price, tools and possibilities seem uniquely congruent with the xPico.

Only issue with xPico is actually humanly getting access to the two serials via the Hirose. The DKs have this... but also a bunch of excess. Ended up making a breakout DIP40 for prototype work... and working to a policy of keeping all useful pins exposed in viae or test points. See previous blog on breakout pins and APIs.
 
http://albertputnam.blogspot.com/2013/12/new-devices-just-give-us-pins-and-apis.html

Wearable Computers - Small Form Factor Redux

Was a bit surprised to find the definition of wearable computers so narrow.

The wearable computer I always wanted would have no intrinsic display or I/O. Have commented on these small forms for various purposes before.
http://albertputnam.blogspot.com/2013/11/minimal-portable-pc-usb3-hdmi-110g.html
It would have a battery, lots of compute, memory and storage, and would have IO ports like USB and HDMI. It would not be wireless locally, but would use a PAN (like Ethernet or USB).
Bluetooth would be okay... though it bleeds to WAN if intrinsic. External connect would be WiFi or 4G (again best if not intrinsic but via IO), but a direct Ethernet nearby is optimal. 802.3af Power over Ethernet would be preffered charging, but also via USB. Ideally wearable solar or energy harvesting would be integrated or integrable.

Do not want to be locked to any specific display or data entry method. Want I/O to be whatever is at hand. Maybe UI can be Oculus Rift ? ... for another post? And WAN disconnect to be guaranteed by using/executing a physical/visible/tangible mechanism.

[Update 140707: Interesting offering ECS LIVA . Available Newegg . Small and battery powerable.
Out of Stock Newegg with reviews].