I might be living under a rock, so this maybe old news (obviously it will be for some :)), but some places where Electric Imp is been used:
http://hackaday.com/2013/06/11/building-a-wifi-enabled-nixie-counter/
http://www.wired.com/design/2013/02/budweiser-red-light/

Okay, I like that one, a LOT!!!!

Thanks for posting the links!

I, too, think it's the bee's knees.

Question, not answered by their FAQ, that maybe someone on this board (Hugo?) will know: Where is the data coming from, and what is the expected latency? In other words, I see the goal happen on the TV screen, how quickly will the light go off after that? And if it's instantaneous, how do they accomplish that?

I know there will be significant inherent latency in getting the TV picture to me, so the red light might get an off-the-line advantage to help it win the race. This can be proven by trying to watch various so-called "live" feeds of an event on different channels coming through different delivery mechanisms. When you do this, you notice that they will all differ greatly in terms of how quickly the event reaches my eyeballs. So I know that the TV picture doesn't reach my eyeballs at the speed of light. In fact, there's enough latency there that I could envision situations where the light might fire off *before* the TV picture shows me the goal.

But I guess my curiosity is, what is the data path, from the goal judge's button to that red light? The goal judge sees the goal and presses his button. This lights up the goal light in the arena and sets off the horn. From there, there's probably automatic scorekeeping systems that update the score on the scoreboard and such. But what else is that system connected to, and does that automatically go to some sort of data source that is instantaneously web-accessible? And does the Imp simply scrape that web page? If so, at what frequency does it do so? How does that data get distributed to all the people that purchased the red lights without overwhelming the web page? Is there a proxy site involved, and does that proxy have the permission from the source site to scrape their data at a high frequency? I find all of this fascinating and I'd love to know how well it works in practice, and if it really does happen instantaneously like they show in the video.

*adds some electric imp powered red lights to the new build system wishlist*

I googled around earlier (but didn't save the links), and found a youtube review of the device, where the guy said that for him, the latency was about 1-second compared with the TV. Except for one cable package, where the red light typically preceeded the TV by a few seconds.. spooky, he said!

Others have reported more latency, of perhaps 5 seconds or so.

Fantastic use for the imp!

Speaking of which.. Bud Canada is still accepting orders for Canadian delivery. Anyone want one outside of Canada? I can buy and reship it.

-ml

That is really tempting. I won't be around for the finals, but in preparation for next year could be something to think about.

I'm interested. The Avs new management structure has me hopeful I'll be able to watch more games next season without screaming at the screen constantly

Well, think about it and PM me if either of you decide to go for it. I can order one (1) unit from them (their restriction, not mine).

Cheers

This seems a bit Rube Goldberg.

Grain of salt here, as I'm not a goal judge, nor am I a hockey scoring system installer, but I really don't think there's any connection between the goal judge's button, and the score keeping system. The goal judge's job is to make the light go on when they see the puck go in the net, but that's purely a signal for the on-ice officials (aka the refs), in case the refs missed it. It's the ref who makes the decision of when something is a goal (okay -- the video goal judge has final say; all goals are reviewed), and can wave the goal off, in the event of something like goalie interference. Once the ref has called the goal, he'll inform the official score keeper, who awards assists. In addition, there are 6 real-time scorers, who sit there and enter data electronically. All of this comes from section 5 (officials) in the NHL rule book.

My assumption is that the data on the web comes from these real-time scorers, and the imp is pulling a live RSS feed with the scores.

Makes sense. What I'm wondering is what's the data path to the server hosting the RSS feed, how often is that scraped, whether the data is scraped to a secondary server that's then read by the imp, etc...

Is it possible that the server is just listening to the TV audio of the game, and has some sort of sound recognition software that fires when it hears the horn?

tanstaafl.

No, not all (or most?) arenas have a "horn", and not all of the horns sound the same.

My impression is that the data comes directly from the official scorers, or perhaps from the arena's scoreboard system, as a paid subscription (paid by Bud or their service company).

Peter rigged up a pixel-addressable RGB LED strip that shows the jenkins build status for the last n builds. Rather nice when it's all green!

It depends a lot on your TV feed. The path through our system is generally well under a second, even with thousands firing concurrently (and this will get better before the next season).

Generally though, it's quicker than your TV feed - if you're watching it streaming, it's a LOT quicker which takes a lot of the tension out of the game

Is this relevant to the Electric Imp story? I haven't heard much about the Electric Imp in a while. Is it still a going concern?

tanstaafl.

Yes. But seriously, check out the blog.

Ahh, interesting. I'd be curious to hear about your transition to Erlang. I'm toying with what sorts of languages would be good or bad for undergrad teaching, and that's one that occasionally comes up in discussion. There's also a newer variant called Elixir that looks like it's trying to modernize some of the older syntactic cruft. Did you look at this or other new stuff that runs on the ErlangVM?

(And how about that Electric Unicorn thing? Swanky.)

"Cruft" is a bit harsh. You get used to it. What's with all those semi-colons in C, amiright?

We looked. There are two reasons we didn't use it: first it was still, like, version 0.6. The second is what I'm calling "the CoffeeScript problem". To use CoffeeScript, you still have to know JavaScript. To use Elixir, you still have to understand Erlang, otherwise none of the libraries you'll be using will make any sense to you.

Purely stylistically, I think that, in its attempt to look vaguely like Ruby, Elixir changed more of the Erlang syntax than it really needed to. I find it a bit jarring when I look at Elixir code.

With that said, I've not looked at that much Elixir code, so maybe it'll grow on me.

There are other languages that run on the Erlang VM, such as LFE (Lisp-Flavored-Erlang) or Joxa.

There are a bunch of good reasons to use Erlang (actually OTP). The actor model is simple; supervisors are a good way to structure problems. Akka has both of those, though. The hot code loading is great in production environments. The introspection tools (fire up a remote console on a production server, start asking questions) are epic. We're not doing much with zero-downtime upgrades or with node clustering yet.

As an undergrad language, it's not a 101-level language. The learning curve's not particularly steep, but the ceremony involved in getting "Hello World" up the first time is a little off-putting.

The electric imp keeps popping up in unexpected places. I saw something about it a couple weeks ago, and then today, I saw MetaMorph on Slashdot. Looked interesting, so I went to give their web demo a lookyloo, and lo and behold, one of their five featured projects is an electric imp module!