touchGUI.py

My first commit to github, yay!

It’s a rudimentary GUI system, optimized for touchscreen use. Very lightweight and totally OOP (except for properties, zomg!). Plus, about every second line of the source is a comment, because it was written to support an educational project. The basic Idea is this: GUI System -> GUI Pages -> GUI Elements. No other documentation so far, although there’s a built-in numerical keypad –  which will also give you an idea of how to use the code.

Find it on https://github.com/niston/touchGUI

Here are some screenshots of an embedded project using touchGUI.py:

screenshots.png

 

Advertisements

IoT Blinkenlights!

Niston Cloud’s WiFi IoT Signaleer is -you guessed it- an Internet-of-Things signal lamp. It can visualize a great many things: Internet connection availability, NAGIOS alarms, home automation indicators, (3D) printer job status – you name it. My use case is to monitor the order queue of a webshop we run at work. So, the current Signaleer Firmware uses HTTP polling. I plan to write an MQTT version for some other use cases.

Niston Cloud's IoT Signaleer

Niston Cloud’s WiFi IoT Signaleer – The Internet-of-Things Blinkenlights

The heart of the IoT Signaleer consists of a nodeMCU board. This integrates an ESP8266 Microcontroller (has built-in WiFi), 4MB FLASH memory, a 3v3 regulator and an USB-TTL Serial bridge onto a tiny, ridiculously cheap board. Thanks to the nodeMCU firmware, the ESP can be programmed in LUA. I had some previous experience in writing LUA code, dating back to my World-of-Warcraft days. So, getting going with nodeMCU wasn’t much involving. I found that it’s event-driven approach is very similar to writing event-driven programms in (ancient) Visual Basic 6 – Which is something I once used to be extremely comfortable with.

Stripeboard PCB, Revision 1

Stripeboard PCB, Revision 1

The light stack used in this project has incadescent lamps. As you can see, I took to some rather very, totally and extremely beefy MOSFETS (IRFP064N) to blink ’em lights. Because, you know, Overkill! The MOSFETS do not fully turn on @ 3v3, so I used pairs of BC547 transistors as non-inverting gate drivers (thx SpeedEvil). Due to the relatively high MOSFET slew rate, I had to take some measures to prevent ringing (which would emit unwanted RFI) and so used a 100KOhm gate resistor. Filament protection is provided by a bunch of 470Ohm bias resistors across the MOSFETs, which pre-heat the bulb filaments with roughly 30mA each (thx Kludge & _abc_).

Incandescent Lamp Driver w/ Softstart Option

Incandescent Lamp Driver (1 Channel shown) w/ Softstart Option

To further extend bulb life, I implemented softstart on all lamp channels, paralleling a 4.7uF capacitance with each MOSFETs Gate. Going overkill++ on the MOSFETs allows for this mode of operation (slowly ramping down RDS) without using any heatsinking or even considering thermal management.  Considering thermal management: I had to rewire the beeper inside the lamp stack, for common anode operation. Doing so, it came to light that the manufacturer had put unsuitable wiring in place, rated for 105°C only. But I measured the inside of the stack to reach 103°C @ 24°C ambient. Thus, some new 180°C rated SiF wiring finally fixed this potential fire hazard. There’s also a little piezo beeper inside the lamp stack; it is driven by a single BC547.

MOSFET sofstart curve (5V,20ms / div)

MOSFET sofstart curve (Gate Voltage – 5V, 20ms / Div)

MOSFET shutdown curve (5V, 10us / Div)

MOSFET shutdown curve (Gate Voltage – 5V, 10us / Div)

I mostly used ESPlorer to code the Firmware, which you can obtain from here. ESPlorer is a tad bit cumbersome to use, and some of the features don’t work at all while others do work, but just not quite right. Still: It got the job done, nonetheless! I need to look around for a suitable dev environment though. Something VS-ish would be nice indeed.

Using ESPlorer as a *rudimentary* IDE.

Using ESPlorer as a *rudimentary* IDE.

 

Linear High/Low Point Sensor Calibration

The other day, from the #raspberrypi@freenode IRC channel was looking for a way to calibrate a sensor he had on his raspi’s I2C bus. He stated that, the sensor gave a millivolt reading from an ADC, that the millivolt reading was linear to the measured parameter, and that his existing code was incomplete (no calibration) and thus produced a reading with considerable offset at the lower end of the scale, compared to a reference sensor. So he was wondering how to do High/Low Point calibration in software.

He had another requirement: He wanted to map the calibrated millivolt reading from the sensor to a zero based ppm scale in a linear fashion.

It took me a while to figure something out, but here it is:

Linear High Low Point Calibration Formular

The idea is to provide ratio-based mapping between the two scales -millivolts from sensor to value on the target scale- while referencing the zero point on the target scale to the Low Point Calibration millivolt value. The targetCalHigh variable is the target scale value at calibration high point (the high point calibration solution’s known ppm value). Because the targetCalLow value is zero as he calibrates the low point with 0ppm solution, we don’t need it for the calculation. The targetValue is the calibrated reading, mapped to whatever zero based scale targetCalHigh refers to.

did some verification of the formula with different calibration solutions (0ppm, 550ppm, 1000ppm and 2200ppm) and said that his raspi based probe provides accurate readings now when compared to the same reference meter, and that the problem appears to be solved.

Feel free to use my Math as you see fit.

Building Stream One

As a little review on the making of Stream One, this is the PPT for a presentation I held at school today. Looking into aspects like: The idea behind it all, prototyping, cross platform development with mono, building and evolving the firmware, some of the software patterns used during design as well as some reflection about what has been done so far and where it’s all heading to.

buildingstreamone

You can view/download the PDF version: Building Stream One (PDF).

NISTON Stream One

What can you do with C#, a Raspberry Pi, a Pi-DAC, and a Matrix Orbital GLK Display?
Build a HiFi component that receives Internet streaming audio! But see for yourself:

Base plate with display unit mounted.

Base plate with display unit mounted.

The wonderful GLK series HMI unit comes from Canadian display manufacturer Matrix Orbital in either USB, Serial or I2C flavour. I develop the Firmware on my Windows machine, and not on the Raspberry Pi itself, so the prototype uses the USB version. Easy for me, because I can connect the display straight to my workstation for development and debugging purposes.

Raspberry Pi, PiDAC, Power supply & distribution.

Raspberry Pi, Pi-DAC, Power supply & distribution added.

Good single malt and good audio boards come from Scotland, it appears. IQaudIO’s Pi-DAC employs a Burr Brown (now TI) chip, the PCM5122. Not as audiophile as the legendary PCM1704 perhaps, but listening to it is certainly a pleasant experience. The engineers at IQaudIO designed the power conditioning with great care, and the output signal is very clean. This is indeed a high quality line output card for the Raspberry Pi!

Almost complete...

Almost complete…

A 15W Mean Well SMPS feeds its 5VDC supply to the distribution rails, where a 10k uF capacitor provides additional stability and reduces ripple. The display, the Raspberry/Pi-DAC-Combo, as well as the external USB port each have their individual power feeds from the power distribution rails. The USB port has an extra 3300uF capacitance added, to smooth out any load surges that might occur when operating power hungry USB devices.

Backplate with Line out, Ethernet and USB.

Backplate with line out, Ethernet and USB.

I chose professional (read: expensive) Neutrik connectors for Ethernet and USB on the prototype, as they are particularly sturdy and durable. The line out has isolated, gold plated RCA receptacles. A 500 mA fuse protects against catastrophic SMPS failure while still allowing for (theoretical) 110VAC operation. I took utmost care not to produce any ground loops in the internal wiring harness: Power distribution and grounding follow a pure star topology while the analogue line output ground is isolated from the (earth ref’d) chassis.

Stream One assembled and working.

Stream One assembled and working.

I wrote the SDD# open source firmware platform in C#. While the Stream One hardware runs SDD# on Raspbian ARMv6 Linux, SDD# executes on Windows, too. The software is a prototype framework design, composed of subsystems for audio streaming (built around the BASS audio library), LCD display abstraction, GUI and user interaction, general input/output and for application software management (Apps). With the project further serving as a technology demo, the Stream One Internet receiver is implemented as an actual App running on top of the SDD# core.

Instead of navigating through lists of tens of thousands of stations available on both Shout- and Icecast, I gave the Stream One a “TV-style” memory that holds up to 99 presets. Programming these presets is conveniently done through a web interface (yet to be developed as of today). The receiver also provides gap-less transitions between station presets and displays extended real-time information about the current station and the streaming conditions (buffer level).

Enclosure lighting controlled by GPIO.

Case illumination controlled by GPIO.

A special effect, the Raspberry Pi controls the blue enclosure lighting by GPIO pin. I plan to use the illumination for an alarm clock feature.

Build time for the hardware was 14 hours, for the software 200+ hours so far. And I spent close to $500 on materials – including shipping, handling and taxes.

Further information about the project can be found in this PDF: Building Stream One.2