Application Architecture Reloaded

A whole whooping full of classes.

The class diagram has grown considerably in size.

Advertisements

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

Coming Soon!

I’m currently very busy with my little embedded Raspberry Pi project. The C# firmware is basically functional now, and I’m about to construct the physical engineering prototype from its components.

Will post more details soon! In the mean time, here are some “Screenshots”:

menu2 tuner menu bootscreen

These are taken straight from the LCD framebuffer with lcdump.exe.

USB Chargers

The USB Battery Charging Specification 1.2 can be found here:
http://komposter.com.ua/documents/BC1.2_FINAL.pdf

More information:
http://www.righto.com/2012/03/inside-cheap-phone-charger-and-why-you.html

An USB charger IC:
http://www.ti.com/product/tps2511?DCMP=analog_power_mr&HQS=tps2511-pr

A table with D+/D- connections in common Chargers:
http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html

 

Black Magic Programming

Sometimes you get to write code that just doesn’t make any sense at all. Like this:

// BLACK MAGIC: persuade mono not to crash
var x = Bass.BASS_GetVersion().ToString();

Of course, the variable x will neither be used nor touched anywhere else in code and the whole thing seems rather questionable. But:

Removing it, or placing it elsewhere in the code will reliably make the application crash with an obscure segfault in mono 3.2.3 on ARM Linux – The jargon file’s Story About Magic comes to mind.

Also, presumably the crash happens due to unspecified native library load order differences between .NET and mono – This certainly appears to be the case, from what we gathered by investigating with gdb. But why? I don’t know, and the folks at #mono@irc.gnome.org appear not to, either.

Oh well.  “We don’t know why we have to do this, but it works.” – All hail the art of Black Magic computer programming! My thanks go to the great master of sorcery, Ian Luck of un4seen.com fame, and to Shana and ShawnWhite from #raspberrypi@irc.freenode.net for helping me devise this great spell of protection, which essentially ensures that libbass.so is loaded when we access libbassmix.so – even under mono.