On a personal note, I’m starting a course in Computer Science at Royal Holloway, University of London in a week’s time. As a result I’ve been running around sorting out accomodation and so on rather than writing blogs. I’ve been spending the rest of my time working (the sort that pays), and the tiny little nooks and crannies of spare time are crammed with work on EVE Metrics 2.

In the past week I also received some donated server hardware; this will be taking residence in my new home and hopefully in the future the cluster will be spending most of it’s CPU cycles doing reports and more complicated econometrics using the EVE Metrics dataset- stuff that takes way too long to do online, but is achievable offline.

Anyway, back to business. Read on for the lowdown on EM2.1, new features, new uploader info and more!

EVE Metrics 2.1, the API release, is a bit off schedule. We were hoping to have it done last weekend, but events have conspired against us. We’re 70% there on the bug tracker but it’s more like 95% in terms of time; the majority of the remaining tasks involve some of the finer points of the upload reward system (which has involved so far hours of Makurid poring over data and projections in MATLAB) and that whole front-end thing. On release, 2.1 will let you view market orders and wallet transactions/journal entries online, and the market orders will be autoloaded into the database.

Trades and an improved uploader

Those of you who are heavy EM users will have known for some time the ‘trading’ tab has been inactive. 2.1 opens that, allowing you to view all our inferred trade data. We’ll be adding in the API-aquired trade data sometime soon after release but it’s not in yet. By inferred data, we mean trades we can infer have occurred by looking at how orders change between uploaded datasets; it’s far from perfect but it’s a good indicator and can be useful.

There’s one other notable thing we have planned for 2.1/2.2- 2.1 will introduce OAuth, and 2.2 will fully implement it including components of the OpenSocial API to provide widgets for both iGoogle and AvatarsUnited. This is part of a partnership between MMMetrics and EnemyUnknown, and we’re very excited to see how we can make the market more of a social tool through these widgets and using social networking technologies. What we will have through API data in EM2 is a lot of useful information about how people trade, allowing us to develop better systems, algorithms and predictions about the market in the future.

What OAuth also means, though, is that we finally have a way to securely link API applications with EVE Metrics. This opens up the possibility of personal API feeds but also gives us a better way to do the uploader. So what we’ll be publishing in the near future is a new uploader, with total support for Mac and Linux as well as Windows. We’re still working out the technicalities and helping to develop some of the technologies involved (libevecache etc) to make the uploader as lightweight and fast as possible while being even more efficient and secure for uploading fantastic data. When we release the new uploader we’ll also be opening the upload protocol specification to let you lot make your own clients if you want to.

Realtime with RabbitMQ, plus feature creep!

One of the most-requested features for EVE Metrics has always been the real-time upload feed. We think email is the wrong way to go about this. It’s not designed for it, it’s overcomplex to parse, it’s a lot of overhead, etc. So we’re going for a more modern solution- a messaging queue based on AMQP and RabbitMQ. We’ll be providing example clients in Ruby and hopefully a few other languages, so if the technicalities escape you there’s no problem. But the point is, it’s fast, resilient, easy to use, and lightweight. Technical details and code samples will come later, of course.

And last but certainly not least, we will be putting new features in. That means trading tools, favourite-based price lists, UI changes to the item display page, and more. As ever, if you want features, hit the ‘feedback’ link on the site and tell us. Not everything will be coming out with 2.1; it’s mostly a framework release, with some very large changes to authentication and lots of new stuff in the market code, plus of course API support. New features will be coming on a more regular basis after that; once we’ve got the basics done, features are often pretty simple in comparison.

Pictures speak a thousand words

Which, incidentally, is roughly the length of this blog post. Speaking of posts- an article I wrote back in 2008 on delayed_job has been published in Rails Magazine issue 4! If you’re interested in background processing, you might want to give it a read.

Anyway, I promised pictures, so here you have the servers, plus some of my latest purchase, a fantastic DT109 headset.

[imagebrowser id=2]

While the manufacturer (ANYtronics) does indeed provide their own controller, we wanted one in a hurry, so I put together a box which does the job quite nicely when all’s said and done.

At present it does:

• Variable speed with preview
• Keyswitch on/off
• Momentary SPST trigger

It’s single-output for now. Considering the strobes have master/slave and can daisychain just fine, I didn’t see much point in doing this, at least for the initial version. The SPST momentary switch and keyswitch were both what I happened to have lying around in my box ‘o electronics stuff, and could easily be swapped for another solution. The SPST could be merged onto a switching rotary pot if you wanted to mimic the control on the back of the strobe precisely, but that wasn’t what I was aiming for- I wanted something that could be easily frobbed and adjusted in advance without having to guess at frequencies. That’s done via the three LEDs- green for power/system on (turns on with keyswitch), red for firing, and the third yellow LED pulsing exactly as the strobe would.

The whole job is fairly simple- it’s all active low TTL circuitry, using an Arduino Diecimila board as the brain. The Arduino manages the pulses, LED logic and switching logic.

The only complex bit of this came with the interfacing to the strobe.

The strobe’s interface is on a mono jack lead. After finding a socket, I needed to work out the pulse length and minimum interval. Given the specs list a 16FPS maximum, I settled on 64ms delay between pulses as a minimum. The pulse length I guessed at from the master-slave interface, again listed in the docs. Fortunately it seems the external trigger works on this too, so that ended up being the delay of choice therin. Code follows after the break.

To pulse the strobe we just need this little snippet of code.

In this I assume you’re constraining the value on read with map() or constrain() externally (I use a readInputs() function which is called once on the loop and once again on the key interrupt). You also need to have strobe_pin set to the Arduino digital pin which the strobe jack lead’s tip (hot) is connected. The sleeve of the jack lead should be connected to ground. If you have a TRS socket, don’t forget to join the ring and sleeve connections on the outside with a small wire to ensure a good connection is made.

The strobe for which I did this was the ANYtronics Superstar Strobe MkII, though this should work for all their strobes, slave or master versions. That said the speed limit I recommended above (at least 64ms between pulses) is not consistent across their range, so read the specs on their site first.