« transforming an idea »

niston cloud. The Art in IT @ Höhere Fachschule Uster, 03.12.2014

« NISTON Stream One »

Niston Cloud’s Streaming Internet Radio Project produced both hardware and software: A HiFi component to receive Internet radio and a quite advanced firmware for it.

• Inception • Nex Gen Requirements • Catalyst • Opportunity • Exploration in mono • Cross Platform Prototype • Human Machine Interface • Engineering Prototype • SIRP: Firmware in C# • Pattern: Engine-Controller • Pattern: Object Tree • SIRP Subsystems Map • SIRP Conclusions

• SDD# - Software Defined Devices in C#

• SDD# Core • Pattern: Observer • Pattern: Accessor • SDD# Apps • StreamOne Technology Demo • Responsive Web Interface • So much things to do! • Project Metamorphosis • Support SDD# • The End

Software Only Prototype: Chester Virtual Audio IRT-1 Mk4 • 2ppl «overnight» design (16 MH of work) • Built around BASS Audio Library • Simplicity-over-Features principle • UI Resembles traditional stereo Tuner • Programming through Paste of URLs • Has «responsive design» elements • Designed with Touchscreen in mind • Written in Visual Basic 6.0

Compact Mode for small Screens

Regular Mode

• Playback Shoutcast/Icecast streams w/o PC • Discrete HiFi component • Integrated mains power supply • HiFi quality line output (SNR >96dB, THD <0.01%) • «TV-Style» preset memory • Gapless preset change • Show relevant Stream Parameters

(Format/Channels/Resolution) • Show RX buffer level • Show audio signal levels (VU meters) • «RDS-Style» scrolling Shoutcast information • Programming/Configuration by Web Interface

Project: Monitoring a Diesel Generator more info @ http://niston.wordpress.com/2013/02/24/pi-based-snmp-monitoring-probe/

• Raspberry Pi Single Board Computer

• Linux Operating System

• Integrated 10/100 Ethernet

• Affordable @ CHF 32 (dealer price)

• BASS added support for ARMv6 – nice!!!

• Bitcoin selloff somewhat refilled the coffers

• No full time job meant lots of time at hand

• Found perfect solutions for HMI & Line Out

• Why mono? Because of portable C#!

• Using mono on a Raspberry Pi

• Compilinig mono on Windows

• C# Cross-Platform-Development: VS2013 on Windows for mono on ARMv6 Linux

• Portability of .NET code & Assemblies

• Using native libraries

• Debugging mono runtime crashes with gdb

Sauron’s Law: One EXE to rule them all!

• Develop on Windows in VS2013, Run on RPi.

• BASS Audio Native Libs (.dll/.so)

• Console UI (no X Win)

• Verification of Audio

• Result: SUCCESS

On Raspberry Pi (via SSH)

Prototype running on Windows 7

• Graphical LCD, Resolution 192x64 Pixels (1bpp) • 7 Generic Navigation Buttons, 3 Bi-Color LEDs • Integrated Piezo Buzzer • Serial Attachment (TTL UART, Serial-over-USB, I2C) • Simple binary command set, easy to work with • Is it fast enough for the VU meters ??? YES IT IS!*

* at 115k2 Baud COM speed easily, no problem!

[ going physical ]

• Raspberry Pi Model B at heart • Sturdy aluminum case: baseplate, cover, front & backplate • High quality components, excellent build quality • Switch mode power supply w/ ample power reserve (15W) • Large capacitors on USB and pwr distribution rails for stability • Power distribution and GND follow pure star topology • Decoupled audio GND (look ma, no ground loops!) • High quality Burr-Brown (now TI) DAC Chip

• Using my own «Engine Modelling» design approach • Making extensive use of my Engine-ControllerTM Pattern • Completely modular architecture built from subsystems • Applying knowledge gained during prototyping phase • Constructing an LCD GUI System from scratch

1 Controller

n Engines

Instantiate, Destroy, Access

Combines classical patterns: Factory, Facade, Extender

Events, Types

Consumer*

Holds instances in Field

Handles all n Engines, Abstracts many into one.

Each one performs a specific Task

*Cares not about individual engines but about functionality provided.

• Facilitates creation of layered abstraction levels – this helps manage complexity

• Encapsulates responsibility by

delegation: a layer performs a specific set of tasks within a particular scope or domain of the problem only, delegating micromanagement and implementation specific details to sub-levels as needed.

• Code near the root of the object

tree is more generic in terms of functionality, whilst fanned out levels solve more specific problems.

subsystems.ui subsystems.ui.screens

subsystems.display

subsystems.io

subsystems.audio

subsystems.memory

main

• Build time ratio hardware:software == 1 : >14

• Hardware platform totally generic

• Built entirely from readily available COTS parts

• Device functionality almost exclusively defined by software running on general purpose CPU/OS

Course of Action:

Turn the SIRP firmware into a generic, open source framework for building software defined devices!

[ for .NET/Windows, mono/Linux (and mono/Android and mono/OSX) ]

Mantra: «Virtualize your Device!» B u z z w o r d s : C l o u d , I n t e r n e t - o f - T h i n g s

Principles: • Use generic, inexpensive hardware base platform • Add specific HW extensions as per requirements • Implement device overall functionality in C# - local and remote! Software Building Blocks: • .NET Framework / mono • SDD# Core • SDD# Apps

WTF! Why do this? Why not MCUs and C? • Powerful C# language and tools • Complete UNIX (and Windows) networking • Easy Cloud integration, Internet-of-Things • Easy File System handling (FAT, FAT32, NTFS...) • Reduced hardware development cost • «Heavy duty» stuff like Databases, Network Services • Lots of smart C# developers out there ! • Humongous open source codebases for C# and Linux! • MCUs still required for specific extensions ;-)

The SDD# Core provides:

• Generalized serial IO

• Concrete support for RS232 serial ports (or Serial-over-USB solutions)

• Generalized layer for LCD interaction, so you don't have to mess with serial IO

• A concrete implementation for a specific LCD module

• An LCD screen manager

• An LCD menu system with support for submenus and interactive menu items

• Audio support (powered by BASS)

• Configuration management (not much implemented)

• Support for Apps (ApplicationManager, IApplication interface).

• TODO: GPIO support

• TODO: HTTP service

[ provide notification of value changes to MenuItem’s owner ]

Notifies observer(s) of change to value. Usually there’s only one observer: The MenuItem owner. Yet, anyone holding a reference may choose to listen to this event.

Problem: Provide an unified, type-independent way of sending notifications about changes to the MenuItem value to all interested parties.

Solution: Introduction of generic ObservableMenuItem. This provides one ValueChanged event for all derived MenuItem types.

[ decoupling MenuItem from MenuSystem ]

done through accessor interfaces

All actions on MenuItems

• .NET Assemblies (DLL) that implement the IApplication interface

• Dynamically loaded/unloaded by ApplicationManager instance

• Provide IScreen implementations for GUI, handled by ScreenManager

• Provide App-specific MenuItems for MenuSystem

• Host problem/app specific code

• Can access SDD# features by Object Tree

• App for SDD#

• SIRP firmware on top of the SDD# Core

• Provides tuner and alarm clock functions

• Holds preset memory

[ remote control ]

• Currently in the making

• Designed by André Ceres

[ a glimpse into the future ]

NISTON Project One – Raspberry Pi compatible* SDD rapid prototyping kit

Building A Hardware

Platform for SDD#

Rpi HATs, CM Progger,

Case Accessories,

User Port Modules

& more ...

* Powered by genuine Raspberry Pi Compute Module

Physical manifestation:

Was: Idea written down as code

Became: Hardware implementation

Ideological transformation:

Was: Internet streaming audio receiver

Became: Generic framework for Software Defined Devices.

12vB2Zephh4wgjyqUQ3SCsSSjTcpVbT41d

Contact:

niston.cloud@gmail.com