Upgrading Mediawiki

So very recently mediawiki became “no longer supported” in debian Jessie. This coincides with the fact that the version in Jessie is a venerable 1.19 (current version is 1.26). I discovered this while trying to get a flexible banner extension working (WikidataPageBanner), and it wouldn’t play nice. So I decided to upgrade my wiki.

Hmmm.

Here is the Wiki about upgrading the Wiki! (Proof that it worked).

The one thing I wish I had done before starting is to prevent my ssh connection from timing out. It ended up backgrounding the database backup task and doing stuff every minute just to make sure the shell stayed open.

Posted in technical | Leave a comment

Choosing a php Framework

I have an old (10 years) web application that was designed to build, track and print characters and create spell lists for the 3rd edition of Dungeons and Dragons.

The application is written in php, without a framework, with a MySQL backend. It still works, and prints out nice pdf character sheets, but I don’t play 3.x anymore. We have (happily) transitioned into 5th edition, and I miss the functionality. So my main task consists of a re-write for 5th edition. At the same time, I want to use a framework, both in order to learn something new (I know, sucker for punishment), and to make it more maintainable going forward.

I did a bit of comparison “shopping”, and ended up taking a short dive into zend. Unfortunately, I found zend to be a little too nuts and bolts. Although I was coming from hand coding the whole thing, I have played with Rails, so I was expecting a little more framework than zend seemed to offer (and frankly, better or easier to follow docs). I am now trying Symfony, and I am much more impressed. It seems to have a very rails-like philosophy and layout, and I actually prefer php syntax to ruby. To me, ruby seems like a programming language written by someone who has a grudge against C, whereas php is unabashedly rooted in C like syntax, which is familiar to me.

I just noticed one weird side effect – all my (self hosted) sites now show up with the Symfony logo on the tab. Must be an apache configuration screw up!

Watch this space for details of how this progresses.

Posted in technical | Leave a comment

The TissueCam

An idea just came to me how I could package the dashcam case – in a tissue box! I could make one of those open-bottom tissue box covers that can sit on the dash (many cars come with a recess to hold just such a box).

That way, the Pi can be subtly hidden in plain sight. The box would be slightly (the thickness of the Pi board) wider towards the windshield, It would hold a normal box of tissues. The streaming interface would be used to view the camera in real time to adjust its position. The main challenges would be connecting to power inconspicuously – although it could be a handy USB hub, and keeping it stable and not sliding around. Some inconspicuous rubber feet, and some solid (laser cut plywood) construction should do the trick, I think, as well as look pretty good.

The size of a low profile tissue box look like 4 3/4″ x 9 1/2″x 2 7/8″ tall inside dimensions, which should hold a Raspberry Pi nicely when mounted vertically. The outside dimensions of my box would be about 6 1/4″ x 10″ x 3″ when constructed with 1/4″ ply.

View from below (not to scale):

+----( )-----------+
|    cam   ---Pi++ |
+------------------+
|                  |
|    (tissues)     |
|                  |
+------------------+

I would have enough room for the power supply board and supplementary battery. The Lens would fit into a hole on the front edge (more to the centre than my picture above). I will post a better diagram once I have sketched out the plan to scale.

Posted in technical | Leave a comment

Pi Dashcam Software

Having pieced together the hardware for my development system (Raspberry Pi Model A, Pi Camera, Microstack GPS module, SunAir power supply, Edisoft WiFi), it is now time for me to create the software.

Here is my feature wish list, in roughly priority order.

  • Forward facing camera
  • Save video recording to USB (or server via WiFi hotspot)
  • Save up to preset maximum video, in a ring buffer unless record button pressed, which will save previous clip plus next 2 clips permanently
  • GPS and timestamp to video
  • Rear facing camera (USB)
  • Recorded video playback on network device.
  • Live stream capture to a cell phone display.
  • Automatic data transfer to server via network.
  • Local battery, smart charging.
  • Accelerometer activated record mode.
  • Unattended car mode.

Forward facing camera.

The forward facing camera is the official Pi Camera, so the python picamera module will do all the heavy lifting (did I mention that I intend to write everything in python?

On startup, the unit should check for USB storage available (and if so, create directory tree if non-existent), and do all recording to USB. Otherwise, recording should happen to local (SD) recording directory.

Implementing a simple ring buffer should be straightforward. I will capture video in 20 second chunks continuously. When the ring buffer is nearly full, I will delete the oldest chunk and continue. If a record event occurs, I will link the previous and the current chunk to the save folder, and setup the next chunk to be linked to the save folder, until the stop recording button is pressed. It occurs to me that the start and stop buttons can be the same button, and that a double press will work to save the previous current and next (3 segments of video). An LED to show that we are saving video would be a nice addition to the hardware. I could use the camera LED to indicate this, as long as I make the LED visible to the driver.

GPS and Timestamp.

Using the GPSD daemon and it’s python module, I can get the current Lat/Long and I can use the GPS time to set my system clock (since the Pi lacks a real time clock).

The picamera module include the ability to add a line of text overlay using the annotation feature. We can use this to provide a timestamp and GPS position information (and speed) to the recording.

Rear facing camera.

To use a USB camera (cheap webcam) from python, OpenCV has a suitable python module. It is (perhaps) a pity that we need two different APIs one for each camera, but such are the vicissitudes of life.

Recorded video playback on network device.

Use recording to network stream, or file mounted by NFS?

Live stream capture to a cell phone display.

Hmm. Tricky? It seems we can create a custom output stream which wants a write and a flush method. We can use this to write to a file, and to a network stream with the same frame. I will need to play with this to see how it works (and how well it works).

Automatic data transfer to server via network.

On connection to local WiFi, a dashcam script can copy all recorded video chunks to a predefined server location (may use ownCloud for this).

Local battery, smart charging.

Using the SunAir card, I can connect a mini-usb for normal power, and a LiPO cellphone battery for backup. The SunAir will charge the battery when the car is running. The SunAir will power the Pi from either the USB or the battery (when the ignition is off). I hope to find a signal from the SunAir card that will tell me when USB power is interrupted so I can perform a smooth shutdown of the Pi.

Accelerometer activated record mode.

Automatic recording when a significant accelerometer event occurs (strong braking, sudden change in direction etc). There is a python module for using the accelerometer.

Unattended car mode.

Mode to record video when a vibration occurs. Perhaps this will be normal operation with file save triggered by a very low threshold accelerometer event, or even a sound event (captured by webcam microphone).

Posted in technical | Leave a comment

Minimal Pi Dashcam

Here I am creating a dashcam with simple software features and a minimal UI. One may think that this is pointless given the plethora of cheap devices already available. Indeed, the simple designs I have seen can be had for as little as $30. However, a two camera design competes with dashcams that cost over $200, and with added GPS, the home build becomes competitive. The new release of the Pi zero now has added camera support! I will continue prototyping with the Model A, and switch to the zero when it arrives (albeit I had to subscribe to the magazine to get it).

Main component pricelist:

Raspberry Pi zero      5    Raspberry Pi (via magazine)
Pi Camera             25    Raspberry Pi (on hand)
GPS module            25    Microstack (on hand)
WiFi adapter          10    Edisoft (on hand)
USB camera            10    (Tiger Direct)
Wide angle lens       10    Aukey kit (Amazon)
Power supply          25    SunAir (on hand)
Battery               free  Old cell phone (on hand)

Obviously these are retail module prices, and a finished manufacturing design would have much cheaper components – but that is unlikely to happen, since this is just a hobby and I lack the resources to compete with manufacturing companies.

At this point, it may or may not have a display (I have a handy 2.8″ 320×200 display from Adafruit). As a headless design, it could connect using WiFi, and push chosen video to a cloud drive (such as google drive, or ownCloud), or simply save to a USB key. It could use a model A (with WiFi or a USB stick), or the latest model 3 B (which has WiFi included), or even the elusive Pi Zero. A benefit of a headless design is that the only component that would have to be visible would be the camera (and it’s cable).

Conceptually, it will take video in x second chunks, in a loop of y segments. On the “save” button press, it will save the last y segments, and continue saving for another z segments – where x, y and z would be programmable parameters. A rear facing camera would be a nice addition (using USB since the Pi only supports a single CSI camera interface). Audio would be another option (requiring a microphone – but the rear USB cam might have one included). Conveniently, I think my truck would make mounting a rear camera fairly easy.

The user can view video using their existing mobile device or computer screen, either from the USB stick, over WiFi from the cam, or their cloud of choice.

I intend to use this guide as the starting point. I would gladly credit the author, but I can’t establish his name.

So far, I have installed minibian on an 8 GB SD card. I have expanded the filesystem, renamed the system to “dashcam”, enabled the camera and also SPI and I2C (required for the Adafruit screen), and updated the software. I made the necessary modifications (from Adafruit’s website) to the kernel and boot config to drive the display. I also installed fbcp – a tool which copies the internal GPU frame buffer to the SPI console frame buffer – required for the SPI driven screen to show the Pi Camera output in real time. This may go away if I switch to headless design. Initial tests show the video from the camera on the display. I installed omxplayer to allow local replay of the h264 video produced by the raspivid tool.

In terms of hardware I have ordered a set of camera lenses from Aukey to get a wider angle on the Pi Camera. I could have gone cheaper, but I wanted glass lenses. I have a small camera bracket, and a couple of simple Pi cases I can use until I have settled on a configuration and mounting method.

I want at least two buttons – one to trigger saving video, and one to initiate shut down. If I go with the touchscreen, it has optional physical buttons already. Otherwise I will use buttons on GPIO lines and project them through the case.

I have a GPS module which I can integrate, software can overlay the time and coordinates on the video. If I take this route, I am strongly considering adding navigation software and a larger screen (7″ Pi Display) to make full use of it. NAVIT sounds like a strong contender for this. However, I shall continue building from small and see how it works out. Another piece of hardware to consider is an INU. The accelerometer can be used to trigger autosaving – in the event of a crash for example – although I suspect a simple tilt sensor would also work for this purpose. As well, an INU can be used to augment or smooth GPS data using a Kalman filter – although I am not sure whether (or how hard it would be) to integrated that into NAVIT.

I successfully hooked up my gps module (a microstack board), by connecting the 3.3, ground and TX/RX lines to my Pi headers. One issue I ran into with gps is the gpsd package does not much like systemd. On initial install, it works fine, but as soon as I reboot, it does not start. running dpkg-reconfigure gpsd starts it up again, but again it fails on reboot. I followed the instructions here, and replaced systemd with tradition sysvinit support, and my problems miraculously vanished.

I then discovered another problem – raspbian jessie comes with libgps21 and the dashcam scripts were built for version 2.2. Anyhow – I think I need to go beyond the scripts from the pidashcam guide. I think I will write a python application from the ground up, using the picamera module, gpsd.

Last but not least, I need to look at the power supply. Car cigarette lighter chargers usually drop abruptly as soon as they engine is stopped – in order to protect the car battery. This could be disruptive to data collection, and possibly injurious to the SD card. Ideally, I would have a constant 5 v supply available, and a notification when ignition goes off, in order to shutdown gracefully. I am considering tapping into the overhead cabin light supply (as this is available after ignition off), and find another line in the vicinity to tell me when ignition is off.

On further consideration, I realize I have a SunAir Solar Power Board kicking around – I bought it on a kickstarter some time ago. It is a $25 board that controls charge to a 3.7 V LiOn battery, and supplies 5 V to Raspberry Pi-like devices. It expects 6 V from a solar panel, or a mini usb connector to charge the battery / power the device. This, coupled with a cell-phone battery or two will ensure I have a smooth shutdown, or ignition-off power available. The downside of this device is that it supplies only 1000 mA, which would only supply the model A + camera safely.

Posted in technical | Leave a comment

A Delicious Serving of Raspberry Pi

You are viewing a WordPress blog post served up by a Raspberry Pi 2 Model B sitting in my living room.

This post is living proof that I have completed an initial foray into some serious Raspberry Pi server functionality, albeit with a few glitches (photos are not now showing). I have not yet gotten a case for the Pi Drive – it is resting in the foam packing it shipped with. I am looking at either printing one – or using the small stacking case from WD themselves.

20160210_200805

I was only intending to test operating systems, but my primary file and print server (of the last 5 years) went down with a power outage, and didn’t come back up properly. I could boot it with a CDROM, but while attempting to fix its boot problems (and it is using RAID5 with 3 hard drives), I munged up the OS and got into apt-get hell. So I thought to myself – why not expand the scope of the project? It’s not like I don’t have enough on the go, right?

I had a lovely little piece of kit from Western Digital – a Pi Drive, which is a 1 TB hard drive in 2.5″ form factor, with a nice little Y cable and a power supply for both the Pi and the drive. Turns out I only have 500 GB of data, so this is perfect for now. If all else fails, I can use the drive as a backup and I can wipe the big server and reinstall.

Note that I have a Wi-Pi Wifi adapter (which I later remove as I am not using it) in the picture. Strangely, the much smaller Edimax adapter gets a better signal than the Wi-Pi. I will also be ditching the display, and the large(ish) box, as I don’t need it – and both are designated for another project.

Pi model 2 with Pi Drive and 7 in Display

However, I am a real cheapskate, and an environmentalist (if for no other reason than I am a cheapskate). It has always bugged me that my server chews down over 100W continuously, 24/7, 365 days a year. The Pi draws about 1W when idle, and the Pi Drive probably about the same. So I thought to myself – lets see if we can get file and print serving up and going, see what performance is like, and then I can futz around porting web-site stuff and anything else I used to rely on the old server for. I didn’t want to get bogged down learning a new distro’s package manager, but I had noticed a new kid on the block in the form of Minibian – a stripped down version of Raspbian, my favourite Pi OS. I gave that a shot – since it uses the familiar debian package manager. It has not let me down. There were no issues whatsoever in getting packages installed and configured to my liking.

My first priority was getting my data copied over. It took about 11 hours to copy over 500 GB of data (mostly videos and music). I quickly set up NFS exports, so now I can get to my stuff from all the other computers as before – except if I boot Windows (which is rarely). I still need to setup Samba to complete this task. While still on the basics, I configured cups for printing from my Linux machines – and to my joy I also discovered a ChromeOS extension for printing to cups. That – after some configuration glitches – was accomplished, so now I can print from Linux or our Chromebooks, 90% of our needs. Samba will deal with another 9%. The missing 1% I hear you ask? I will need to install the Chrome Browser and add the Google Cloud Print extension. Hey – I just discovered the Google print cups connector!

I have also installed owncloud – a personal cloud solution, to wean myself off of reliance on Google and Dropbox. So far, owncloud works pretty well. It even has a document creator – using Libre Office as a back end, although for now it only supports docs, not spreadsheets or slides. I am quite impressed – and it is under an Apache open source license.

Initial trials with my web sites were a little more discouraging. I got blank pages, or only the static content. I decided while doing all this I might as well switch to mariadb instead of mysql. That installed fine, and I simply manually copied my ISAM and InnoDB tables over. I then basically ported all my apache “sites-enabled” over, put the right passwords in the right places, and very little worked. I fiddled around for a day or two – before I discovered that I had a broken wordpress theme. I activated the twenty-fifteen theme and suddenly all my sites worked. So – wordpress is working well – this post is on the new WordPress Blog, successfully ported to a Raspberry Pi 2. Soon after that, I installed the current version of the twenty-ten theme for which all my header images were customized, and we were gold.

Now for my old php driven D&D sites. I maintain a 3.x edition character database and pdf producer of nice character sheets and a spell database which is great for choosing and printing spell books. I want to upgrade these to do both Pathfinder and 5th edition. So far I have partial success. I am confident I will soon have everything working.

I would also like to get an e-mail server working. I used to run my own for about 10 years, on a Linux server. I gave it up when google became the defacto provider, and I had moved once too often to want to be without e-mail for 3 days while ISPs failed to live up to their installation agreements. I have installed postfix, which came with an unexpected challenge. The upstream debian posfix package had a requirement for either mysql or postgresql. I was using mariadb. After forcing it to install anyway, I still got error messages blocking my progress with every subsequent apt operation. I bit the bullet and hand-edited the .deb package to allow mariadb-server as an alternative. Something the package maintainers themselves ought to do. However, it was quite easy, and I learned something new in the process. All good. I then needed to use the same trick for mediawiki, which installed fine once I added mariadb to the “recommended” list in the control file.

Postscript:
I will add posts giving detailed technical HOWTOs for various portions of this project if people show any interest. Let me know!

PPS:
Also based on interest – I will create a unified configuration system for all the local configuration (server name, domain, user logins, outgoing smtp etc), and an SD image for download. I may need to create a kickstarter for this (at least so I can justify all the time to my wife).

Posted in technical | 3 Comments

Raspberry Pi based Navigator

I am exploring the possibilities of the Raspberry Pi with its new 7″ display for embedded devices. Here is a brief list of possible projects I am considering.

  • Dashcam
  • GPS navigation
  • Marine navigation
  • Home security system

Obviously the list can be further expanded.

Before embarking on any of these there is some basic groundwork. The first thing I want to determine is which OS to use for all of these. I say which one because I want to start from a common base for all of them, not having to relearn basics for each project. I already have years of experience in Slackware, SuSE, Debian, Ubuntu and Mint. The leading distros for the Pi are Raspbian and Arch.

My first mini-project will be some exploration around which OS is the best for my purpose. To that end, I have scoured the web for actual data – but there is surprisingly little head to head comparison. Here are some of the criteria I will be concerned about.

  1. Performance
  2. Footprint
  3. Application support
  4. Flexibility
  5. Ease of integration

Performance will matter – some specific tests will be speed of bootup, speed of launching principle applications, time between screens within applications, responsiveness to user input.

Footprint is not as important, but being able to have as much space for actual user data as opposed to unused applications, as well as having a small memory resident footprint for the limited (and un-expandable) Pi does have merit.

Application support will really be a question of library support and whether the distro will support the latest libraries and applications from its repositories. I am not averse to compiling the latest source for specific applications, but I balk at large trees of supporting libraries. The OS has to do some of the work.

Flexibility – how easily can I add or remove major subsystems such as X Window (I may not need it), unwanted utilities and apps. Is touchscreen support ready and working, and if not – how hard is it to add.

Ease of integration – how easy is it for me to configure the kernel to support my specific hardware – GPS module, INU, add on communications hardware (such as WSPR transmitter) etc. I am OK with tweaking the device tree, or adding platform data, and rebuilding the kernel, but I would prefer as little of that as possible. Tweaking if necessary, but not necessarily tweaking!

So my first task is to play with different OSes and establish which one meets these criteria best.

Posted in Uncategorized | Leave a comment

The official Raspberry Pi 7″ touch display

I had set up several information feeds about the Raspberry Pi, all in the hope that when the official display dropped (expected for over a year now), I could jump on it.

I forget which media site I saw my first glimpse – on 15th September 2015, but it showed up on almost every site within 5 minutes of that first post. Not of course before I jumped onto MCM and searched for it. For a couple of worrying moments it didn’t show up, but another minute or two and I found it and plunked down my credit card. It finally arrived at home on Saturday 19th September, and play commenced.

Display in box

I opened it up

Opened box

And the display itself

The display itself

And then all assembled

Assembled display

Assembled display

The screen appears well made, and surprisingly thin. I suspect it was made for android devices, as to one side (or bottom in portrait mode) it looks like the touchscreen hardware extends beyond the display area into the bezel. The mounting for the circuit, and posts for the Pi work perfectly. I followed a web video from MCM’s site and placed my Pi upside down (for compactness). I will most likely use a gpio extender to add more features to my system later.

I have already added my Raspberry Pi B+ and have some initial experiences with it. It is clear and bright, with good viewing angles. The version of Raspbian I had already included the necessary drivers. I could navigate the touchscreen – pull down menus and launch applications. I was able to enter my WiFi password and get on the net using the “matchbox-keyboard” right on the touchscreen.

Here I encountered my first bug – which has nothing to do with the screen. Once matchbox-keyboard is used, the file manager installed with the desktop, pcmanfm, immediately shoots up to 100% cpu utilization and stays there indefinitely. I did try “florence”, another keyboard but I did not like its default configuration. There is some work to do here in finding a suitable virtual keyboard.

Another glitch is that the screen cannot (at present) be turned off from software (or hardware) – a known shortcoming that should be addressed in the coming weeks. This means that when a software power down is issued, the screen will remain powered on with a glitchy pattern of dots displayed once the Pi itself is off.

I did not calibrate my touchscreen, and so I found some spots on the screen were hard to hit. I expect this will be corrected with calibration. The distro did not have support for multitouch or gestures so I could not test those. In a future post I will detail those features.

Posted in Uncategorized | Leave a comment

In the Air – Automated Greenhouse – First Post

This is a duplicate of the blog post on the sponsor’s website.

Firstly – thanks Element14 and Sponsors. This is an amazing opportunity. As a first reaction, I am a little staggered by the enormity of what I have taken on. My second reaction has been to reach out to people I know for assistance and encouragement.

The environment has long been a passion of mine, and at the same time I have always loved gadgets and building things. With this project I can scratch both itches, and advance my own understanding of electronics, software and agriculture.

My initial plan is to get the help of a few people with enthusiasm and/or knowledge in the areas of gardening, environment, sensors, actuators, microcontrollers and software. Then we will probably get together and shoot crazy ideas back and forth for a bit, capturing all ideas. Then we will give ourselves some time to digest everything, and I will create some kind of framework for us to move forward from that point.

Posted in Uncategorized | Leave a comment

PiMusicBox

I just reached a milestone with another Raspberry Pi project – a network music player.

PiMusicBox

The main aim was to provide access to my extensive digital music collection on my file server, in a form my oldish (but decent) stereo can digest. Access to other music would be a bonus. I intended to control the player through a web interface.

Mopidy seems to be the thing for the job, and it adds support for a bunch of music services, as well as access to some free web-radio stations. On top of that, some kind person has even bundled a pre-configured and ready to go version of mopidy for the Rasberry Pi in the form of PiMusicBox.

It turns out that “out of the box”, there are a few problems. The Pi itself has less than stellar audio output. I can hear distortion (apparently from the power supply), and there are clicks and worse yet, gaps when I play files. To solve these problem, I bought a Wolfson audio card.

The PiMusicBox project, would handily provide all my needs. However, it turns out that it is distributed in the form of a standard Raspbian image with the mopidy software and setup baked in. While this is great for inexperienced users to get going fast, it uses a kernel that does not support the Wolfson audio card, and the Wolfson drivers are not integrated into the upstream kernel. However, they are available in source code, or there are pre-compiled images of the kernel out there. Wolfson distribute their own complete modified Rasbian image for use with their card, which of course does not include the nifty PiMusicBox software.

Parts List:

Steps:

  1. Assemble.
  2. Download PiMusicBox image, copy to SD card.
  3. Build recent, Wolfson capable kernel and copy to SD card.
  4. Configure PiMusicBox (mopidy) software.
  5. Enjoy!

I should have started by starting the downloads of software – I could assemble my gear while that takes place.

Assembly
However, I assembled the case – which sort of required inserting the Pi as I went. So I disassembled the case, and seated the Wolfson audio card on top of my Pi B rev 2. You must use a rev 2 Pi, since the Wolfson uses the P5 pads on the Pi, which are only found on the rev 2 boards – either A or B (but not B+).

I then assembled the case around my Pi-Wolfson sandwich. It fit really nicely, with the case milled to accept the edges of both boards. I tested the Pi with an existing Raspbian SD, and it worked fine – although of course there was no Wolfson audio.

Prepare the OS Image
Meanwhile, I dd’ed an image of the PiMusicBox software onto a 2GB SD I had lying around. I didn’t need local storage for music, as I had it all on a central server in our house (an arrangement which Apple’s iTunes software does not care for).

I then tested this, and was able to play some music on the standard (built in) Pi audio Line Out. Now for the Wolfson.

Cross compiling a new kernel.
I used a this page to cross-compile a 3.12 kernel with built in support for my Wolfson Audio Card. I then copied the kernel and modules onto the Pi’s SD card.

Initially, the Pi crashed on boot as it was (by default) loading the modules for the HifiBerry DAC, which appears to be incompatible (also uses i2s bus) with the Wolfson. I removed the modules from the /etc/modules file, and added a blacklist file for them, and the Pi booted fine.

Configure
So – now I have a PiMusicBox with Wolfson support. So far, so good. But it is not yet tested or configured to do anything. Once the Pi booted, I looked on my router’s DHCP Client list for it’s IP address so I could connect, using a web browser.

To do detailed configuration, I wanted to ssh into the box, so first I had to enable ssh using the musicbox interface under settings. While I was at it, I checked off the box that would automatically expand my filesystem to fill the SD card on next boot. Then I could connect with a terminal. The next thing I wanted was an editor (for those config files), so I installed vim (# apt-get update; apt-get upgrade; apt-get install vim). Other folks may find nano adequate for their needs.

The first thing was to get sound output working from the Wolfson. I ran # aplay -L to see the setup of sound devices under alsa. My device (snd_rpi_wsp) was listed as 0. I modified my /etc/asound.conf to point the default output to the Wolfson, and that was it.

I happen to subscribe to Google Play Music, so I wanted to configure that service on the PiMusicBox. One “gotcha” I discovered about the config files, is that although the /etc/mopidy/mopidy.conf file has “” (quoted empty strings) as place holders for values like user-name and password, the conf file does not work if you quote your strings for answers to these questions. In other words, don’t put "my.name@gmail.com" – just plain my.name@google.com is what will work. I used the “Android Device Id” app from Google Play on my phone to get the deviceid required – which was called the “Google Service Framework ID” in the Android tool.

As mentioned earlier, our household’s music is on a network server. It happens also to be a Linux box. Although PiMusicBox comes with instructions to connect to a Samba server, I prefer to use NFS when both ends support it – I imagine it is more efficient. Poking around the PiMusicBox distribution, I discovered that it’s web server finds music in sub-directories under /music. There is already a directory /music/Network there. I created another subdirectory /music/Network/gemini named after my music file server. I tested the idea with mount 192.168.2.100:/home/export/data/music /music/Network/gemini. After restarting mopidy /etc/init.d/mopidy restart, firing up a browser on a PC let me browse my music files and play them. Then a quick edit of the /etc/fstab file and I could make my change permanent:


192.168.2.100:/home/export/data/music /music/Network/gemini nfs defaults,soft,ro 0 1

Next Steps
For Phase two of this project, I intend to mount a nice blue 16×2 LCD panel, which will allow it to show the artist and song title playing, and subsequently an IR receiver for direct player control, for which I will write a simple interface (probably using python). Then the PiMusicBox can be a stand alone player.

My wife would like me to integrate SiriusXM play capability into the project as well. I think it would be possible using a mopidy extension, which I will have to research. As a starting point, she is having fun building Google playlists to listen to in the meantime.

Posted in technical | 1 Comment