Wizkers.io is live!


Wizkers.io is live!

This is the first week of 2015, and the next step in a project I started almost two years ago: today, I am releasing “Wizkers“, a full Javascript/HTML5 Open Source framework that provides data visualization, logging and data upload to any instrument or device that produces data.

Wizkers CPM Count

What makes Wizkers different? First of all, it is designed to be super easy to use: any computer running Google Chrome can be up and running in a matter of minutes using the Chrome Packaged app version of Wizkers, which we call “Mouse Wizkers”. But you are not limited to running inside of Chrome: Wizkers works just as well as a server on hardware as small as a Beaglebone Black or as virtual as an Amazon Web Services EC2 instance!

Second, Wizkers provides a much needed missing link between Internet Of Things data services and the actual devices that produce data, by enabling complete local control, logging and visualization, while still letting you forward data to whatever backend you want.

Last, Wizkers is designed in a very modular manner, which makes it possible to support new instruments and devices with as little work as possible. If you have designed a device that produces data, and want to give it a great interface, look no further!

Wizkers is already being deployed by quite a few testers, including professional users, and I am very excited to see where 2015 will take us!

State of the project

Wizkers can be considered to be in advanced beta state. The documentation is a work in progress, as is customary, and will improve over time. So while you can expect a few rough edges, dive in and give us feedback, and help us make Wizkers better!

Wizkers support about half of dozen devices, as varied as Ham radio transceivers or Geiger counters. we encourage you to visit our site, Wizkers.io, and get better acquainted with this project.

And by all means, please get in touch with any remark, comment, or question you may have!

Mini game of life

Two months or so ago, the kids and I bought a few bits and pieces at www.adafruit.com to build small LED badges. They had been staying in their box since then, but I eventually got to it with my youngest this Sunday afternoon.

Animated GIF!

Animated GIF!

The idea was to create simple animated badges using the cute 8×8 “mini” LED matrix displays that Adafruit sells, and using some of their small ATTiny45 boards to run the ARV Arduino sketch they described at http://learn.adafruit.com/trinket-slash-gemma-space-invader-pendant/overview .

Fried Circuits USB Tester OLED backpack: adding autoscale

USB Tester on 200mA scaleI am a big fan of the USB tester designed by William at http://friedcircuits.us/, and I contributed a bit of code a few months ago, to implement scrolling of the USB voltage graph display.

Since the OLED screen on this device is fairly small, I thought it would be nice to implement autoscaling, so that the display always makes the best use of available space. I implemented this yesterday, and it seems to be working pretty well.

Using this updated firmware, the OLED backpack will now change its display scale dynamically from 200mA to 5A. One nice thing if you are a developer, is that you can simply define the scales in one single array at the beginning of the firmware code and you won’t need to touch any other part.

This new feature is already rolled into the official firmware that is available at https://github.com/FriedCircuits/FC-USB-Tester-OLED-Backpack so go try it, test and report!

One area where I would be interested to get feedback: do you think it is worth displaying the scale on the display? Since we only have 24 vertical pixels, the graph is more of a trend indicator than anything else, so I decided against it. The display flashes a “*” briefly when changing scale, and current reading is always displayed at the bottom anyway…

Z-Scale controller part X: Bootstrap and UI design

Z-Scale controller part X: Bootstrap and UI design

Bootstrap logo

Twitter Bootstrap

See this big “B” on the left? B is for Bootstrap, a “Sleek, intuitive, and powerful front-end framework for faster and easier web development”. Or at least that’s what the project page says.

In practice, Bootstrap is a set of stylesheets and javascript code that define an extensive and coherent set of widgets that can be used on HTML pages, along with “Scaffolding” elements. This scaffolding is also mainly a set of styles that, when used as intended, make it very simple to organise assets on a page – including ‘responsive’ elements.

Z-Scale controller part IX: managing state and talking to the server

This article will focus on two parts of our application that provide some of the support functions that are needed across most application screens: the link manager, and the settings.

The Link manager

The link manager is created once in the application, and used by every view that needs it. It is in charge of handling direct communication with the controller board. In particular, it handles the “socket.io” connection to the server, and triggers javascript events whenever there is serial data incoming:

Z-Scale controller part VIII: modelling our data

Z-Scale controller part VIII: modelling our data

We laid the foundation for our app in the previous article. The next step is now to create a data model to make it run smoothly.

High level logic of the application

The application lets the use create “locomotives”, where we track a few informations such as picture and description, as well as a runtime and maintenance log. We also manage “layouts”: a layout contains a layout diagram, and a list of controllers and accessories.

In a standard session, the user will select a locomotive and a layout, connect to the controller, and then drive the train & accessories. With that high level view in mind, we can define what screens are required to support this:

Z-Scale controller Part VII: Controller web app

Z-Scale controller Part VII: Controller web app

We are now moving on to the last part of this series: the part of the application that is running in the browser. As I explained in the previous article, I took the decision to have as much as the overall application run in the browser. There are several reasons for this:

– Keep the code simple by avoid too much back and forth between browser and web app
– Keep server tasks as lightweight as possible in order to run it with good performance on very low end hardware
– Related to the previous point: take advantage of the fact that every tablet around is capable of pretty advanced and fast javascript processing.

But before going further, here are a few screenshots of the final result!

Train Controller home screen