It’s the fucking cable

Buying cables from Monoprice has always been a no-brainer for me and they have all have worked pretty much flawlessly. So naturally when we wanted to try using SDI (with our Canon XF105) I ordered some BNC terminated cables off of Monoprice (back in Jan 2013) which I assume would work for HD-SDI (seems like a common assumption if you read the reviews) but we never could get it to work.

Come a year later, we get a Matrox VS4 which automatically selects the resolution and frame rate and we revisited SDI and happen to discover that it worked when we tried sending an SD signal. After that discovery I started digging into it deeper and there is a nice specification for SDI cables called SMPTE and we needed an SMPTE 292M compliant cable. Searching online for these kind of cables I found one from B&H. I quickly ordered a few of them and I was super excited and relieved when they worked flawlessly on the first try. They are definitely worth the price. The cables arrived the day before our AGM and were extremely useful because the tech area was about 70 feet from our camera and 120 feet from the presenter TV at the stage. So we were nice and out of the way instead of having to move into the range of HDMI.

Matrox Mojito Max and Matrox VS4 are not compatible

One would think that similar products from the same company would be compatible but with Matrox, that is woefully wrong. A few months ago we bought 2 Matrox Mojito MAX cards because I had assumed the BlackMagic Intensity Pro cards we were using were bad (turns out it was the motherboard). They worked great for capturing HDMI except we could never get it to capture the HD-SDI signal from our Canon XF105. My desire to use the BNC connector drove me to buying the Matrox VS4 because it claimed it did resolution and frame rate detection and it did in fact deliver on that promise. When plugging in the camera with HD-SDI we found that it did indeed work which was relieving and we quickly identified the cable as the problem. However there was a huge snag, we were forced to uninstall the Mojito MAX drivers to use the card and when trying to reinstall them, we were forced to uninstall the VS4 drivers. A quick call to Matrox customer support confirmed that the cards are not compatible and attempting to manually install the drivers caused BSoD on our livestreaming rig. The return process was pretty painfree.

I'm planning on doing a bunch of posts about what I've learned does and does not work for livestreaming company events in the coming weeks. So stay tuned.

Fixing sound on the PhidgetSBC3

When I got my PhidgetSBC3 I was really excited because I was going to try to get go running on it (which I did) but while it recognized my Logitech Z205 speakers, playing any audio file resulted in a lot of crackling (hear for yourself). After searching until my eyes bled months ago, I gave up. But recently I took another stab (because I want our foosball table horn back at Shopify) and finally found a solution then I figured out the actual problem.

I've tried solution after solution hoping it would work because none of the regular troubleshooting would work as the device was being recognized and was able to be used. It just sounded horrible. I did find this wiki entry for archlinux for crackling sound with USB devices but that solution didn't help. But did make me try restarting the PhidgetSBC3 which then lead some actual errors when trying to use alsa.

root@phidgetsbc:~# alsamixer
cannot open mixer: No such file or directory
root@phidgetsbc:~# aplay /usr/share/sounds/alsa/Front_Center.wav 
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM default
aplay: main:682: audio open error: No such file or directory

Searching for this lead me to this forum post about a usb speaker not being detected and suggested creating a /etc/asound.conf file and restarting alsa. This solved the problem of not finding the device and the crackling. The card 1 in the file suggested an ID of some sort and then I checked the ID of the device and found it matched.

root@phidgetsbc:~# cat /proc/asound/modules
 1 snd_usb_audio

I wanted to confirm this was the device missing issue so I restored to factory and plugged the Z205 in and looked again.

root@phidgetsbc:~# cat /proc/asound/modules
 0 snd_usb_audio

And suddenly it makes sense. For whatever reason, before installing alsa-base the PhidgetSBC3 will use ID 0 for the Z205 but after that it will use ID 1. I have no idea why the crackling went away but it might have something to do with setting type hw or maybe it just doesn't like ID 0.

TL;DR

If you're trying to get sound on the PhidgetSBC3 to work. Try this and restart.

root@phidgetsbc:~# apt-get install alsa-base alsa-utils -y
root@phidgetsbc:~# cat > /etc/asound.conf
pcm.!default {
        type hw
        card 1
}

ctl.!default {
        type hw
        card 1
}
root@phidgetsbc:~# /etc/init.d/alsa-utils restart
[ ok ] Shutting down ALSA...done.
[ ok ] Setting up ALSA...done.

Go on the PhidgetSBC3 Part 2

Now that go is installed (see Part 1), you can get down to business and start using phidgets. I've written a go phidgets library (currently only InterfaceKit and IR phidgets are implemented, open an issue or pull request if you want more) at github.com/samuelkadolph/go/phidgets.

Continue reading "Go on the PhidgetSBC3 Part 2"

Go on the PhidgetSBC3 Part 1

The latest version of the PhidgetSBC line includes an ARMv5 processor which means it now has support for go. Unfortunately the current golang package in the debian repository does not work but I was able to compile golang from source on the PhidgetSBC3 and it worked (including cgo). Thanks to the
"The Go Language Gophers" team I downloaded the golang-tip package and built it on my PhidgetSBC3. I've made this deb available in my apt repository so you can easily install go and get rocking.

Continue reading "Go on the PhidgetSBC3 Part 1"

Fix locales on the PhidgetSBC3

If you are using a PhidgetSBC3 you might see this a lot:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
  LANGUAGE = (unset),
  LC_ALL = (unset),
  LANG = "en_CA.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

This is because perl is very vocal when you are missing the locales that your environment specifies. The fix is easy, just generate the locales that you want to use (en_CA.UTF-8 is the default). This assumes you have already set up SSH on your PhidgetSBC3.

  1. Enable full Debian Package Repository
    Enable the full Debian Package Repository
  2. Update apt
    • apt-get update
  3. Install the locales package
    • apt-get install locales -y
  4. Add the en_CA.UTF-8 locale
    • echo "en_CA.UTF-8 UTF-8" >> /etc/locale.gen
  5. Generate the locale
    • locale-gen

You should see it generating the locale you specified and once it's done, you will no longer see the locale error messages.

PhidgetSBC3 and D-Link DWA-160

There's actually a much easier way of doing this. Just apt-get install firmware-linux-free and boom! You get the carl9170 firmware and the DWA-160 is recognized.

I recently got my hands on a PhidgetSBC3 and plugged a D-Link DWA-160 into and found that it already had support built into the kernel but it had an error. So I went searching in the /lib/firmware directory and saw there was no carl9170-1.fw file. So I downloaded and when I plugged the DWA-160 back in it worked and correctly showed up in the web interface. Installing it is very easy:

apt-get install curl -y
curl -L http://linuxwireless.org/en/users/Drivers/carl9170/fw1.9.7?action=AttachFile&do=get&target=carl9170-1.fw > /lib/firmware/carl9170-1.fw

Send files to your trash in OS X from the command line

So yesterday I wrote a little Objective C tool that behaves like rm but instead sends the files or directories to your Trash using Finder. The code is available at samuelkadolph/trash. You can clone that repo and run make install or if you have homebrew you can run this:

brew install https://raw.github.com/samuelkadolph/homebrew/add_trash_formula/Library/Formula/trash.rb

PhidgetSBC2 and D-Link DWA-160

So I've had a little project going on with the foosball table at work: a system to detect when someone scores a goal. I've built a prototype photogate that goes inside of the goal. My design is to have 2 photogates hooked up to my PhidgetSBC2 and write some ruby code to detect a goal and send a message to a connected iPad app to indicate who scored. Everything was going fine until I took the PhidgetSBC2 to our foosball table and discovered our 2.4GHz network had no coverage there. Which means the wifi usb adapter I had for the PhidgetSBC2 was useless. Undeterred I started on 2 different solutions.

Continue reading "PhidgetSBC2 and D-Link DWA-160"

PhidgetSBC2 and ruby

Installing ruby (and the phidgets-ffi gem) on the PhidgetSBC2 is fairly simple. You will need to check Include full Debian Package Repository under System > Packages in the SBC admin page. And then just ssh into the server and run the following:

apt-get update && apt-get install ruby1.9.1 ruby1.9.1-dev build-essential -y

And then you can install the phidgets-ffi gem like so:

gem1.9.1 install ffi phidgets-ffi

The gem doesn't find the libphidgetsbc.so.0 on the PhidgetSBC, so we need to symlink it to somewhere that the gem will find it.

 ln -s /usr/lib/libphidget21.so.0 /usr/lib/libphidget21.so

Once we're done this we can test it with this:

ruby1.9.1 -rphidgets-ffi -e 'puts Phidgets::FFI.library_version'

I also like to run this to add the ruby1.9.1 executables (i.e. rake, irb, gem) without the 1.9.1 suffix.

update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.9.1 400 \
--slave /usr/bin/erb erb /usr/bin/erb1.9.1 \
--slave /usr/bin/gem gem /usr/bin/gem1.9.1 \
--slave /usr/bin/rake rake /usr/bin/rake1.9.1 \
--slave /usr/bin/testrb testrb /usr/bin/testrb1.9.1 \
--slave /usr/bin/rdoc rdoc /usr/bin/rdoc1.9.1 \
--slave /usr/bin/irb irb /usr/bin/irb1.9.1

I also like to create an .gemrc to skip installing ri and rdoc documentation to save on space.

echo install: --no-rdoc --no-ri >> ~/.gemrc
echo update:  --no-rdoc --no-ri >> ~/.gemrc