Vive la Vive – My VR adventures Part II

2016 had given us not one but two VR ecosystem. Oculus’ Rift, which we had discussed in Part I, and the HTC/Valve Vive. Today, I’ll try and explain why I think the Vive is the a more technologically viable option of the two. This will not be an “unboxing” as those can be found all over the internet. In this post I’ll try to go over the reasons I went the Vive way.

I will not go over the details as for the usage of the system, his will be discusses at a later date, after I’ll be using the Vive for some time and gained some experience with the system and have found the correct balance for my rig. (as we do for all new hardware). I don’t believe in Reviewing a product 10 minutes after getting my hands on it.

I was initially very fixated on getting the Rift. But we have established that Oculus just didn’t want my money… fair enough.

HTC however did, and boy they took it. 900USD (800+tax+S&H) and that is just to get it in the US, I still need to fly it over… another 200USD… And that is before local taxes 😐 Compare this to the 600USD Rift (free S&H, no sales tax) + smaller box, leading to “only” 100USD of shipping. for me that translates to 400USD in purchase price alone, not to mention, local taxes…. Now you understand why I initially insisted on the Rift?

Continue reading Vive la Vive – My VR adventures Part II

To Rift or not to Rift? – My VR adventures Part I

I’ve been lazy in the past few months, and I’ve unfortunately didn’t work on the pit at all in the last few months (since January 2016 to be exact).

However, As you are probably aware 2016 is a big year for VR, two major companies had launched their first consumer devices to the market. Oculus with the Rift, HTC/Valve with the Vive.

I’ve decided to dip my toes into the VR pool and check the water out.

Continue reading To Rift or not to Rift? – My VR adventures Part I

“Weekly update” – Nov/Dec 2015

I have been quite for too long 🙂 with the release of BMS4.33 followed by the Israeli Theater, I’ve had not much time to update the blog. However the Pit has been going places 🙂

first of all, I’ve replaced by 27″ 1440p display with a 40″ 4k computer monitor. I’m still tweaking graphics options, to get the performance to where I want it.. but it looks good!

I’ve also finally re-wired my pit, and installed the ICP, making things even better 🙂

This slideshow requires JavaScript.

in addition, I’ve been tweaking with the TQS adapter, trying to add a curve to the microstick, allowing better finetuned control in game.

In addition,
I’ve also published on github a little GUI wrapper for avrdude that allows a quick upload of images to ATMEGA 32u4 chips, I use it to quickly upload new FW to the throttle and ICP, but I assume others might find it usefull for other things as well.

Both of them are linked on the download page.

[Tech-Post] Encoders – re-discovering the obvious

I didn’t write any proper “tech post” in  a while. However while working on the ICP I’ve had to re-learn (like everytime) the basics.

This time it’s encoders that got my attention.
The Web is filled with howtos and tutorials about encoders, pages upon pages upon videos. all demonstrating and explaining how everything works.

in a sentence or two (or more), Rotary encoders have two output pins, connected to a common pin. When the encoder is in a detent (or stop), both pins are the same state, which is OPEN. when rotated, the pins pulse on and off between the stops, they do it in a staggered way. allowing us to determine rotation direction (and speed) of the rotation. I’ve yet to learn the speed bit, so let’s concentrate about direction. the pulses look something like this:

Rotary Encoder pulses (from the Arduino website)
Rotary Encoder pulses (from the Arduino website)

In this diagram the outputs are pulled down, and the common is connected to 5V. it can of course be the other way around.

to get the state we can use poll, an interrupt pin attached to one of the outputs, or two interup pins. attached to both outputs. the more interrupts you use, the less chance you will miss a pulse causing a step to be missed).

Regardless of the option you choose to use, all the articles have  an elaborated list of if statements, designed to figure out which thing goes where.. something in the spirit of:

if (pinA == HIGH) {
  if (pinB == LOW) {
    // it turned CW
  } else {
    //it turned CCW
} else {
  if (pinB == HIGH) {
    // it turned CW
  } else {
    //it turned CCW

Anyway, this is long, complex and pretty hard to understand.
But if we create a truth table based on the diagram above it reveals a little loophole.

 what triggered/pin status  A1B1 A0B0 A1B0 A0B1

as you can see, the pin that changed, determins the rotation. if we use interrupt on pin A then:

if (pinA == pinB) {
    //it turned CCW
} else {
    // this is CW

Interrupt on the B pin will be the other way around.

And if you are triggering on both it’s also quite easy. you just need to use the correct if statement everytime.

That’s pretty much it 🙂

DEDuino – V.1.2.0

DEDuino version 1.2.0 is finally here.
The main change is the switch to i2c protocol to drive the lights. However several other change has also has been implemented.
To support the new features, a new software version has been released. please note that this version is not backwards compatible with the old code. and vice versa, DEDuino 1.2.0 can only work with app version and up. please note that DEDuino software will not automaticly update major version – so current devices should not be effected.

Continue reading DEDuino – V.1.2.0

Weekly update – 2015/08/16

This week’s topics:

  • ICP still stuck in customs  😐
  • Still working on the eyebrow lights – hope to get it done sometime soon 😉
  • DEDuino code and app are going through some major changes and evolved quite nicely over the last few weeks
  • Caution Panel – I’ve ordered a caution panel from Jshep, in stead of building one from scratch.
  • DEDuino “User guide”.

Continue reading Weekly update – 2015/08/16

Quick tip – Binary to HEX and DEC conversion

I’ve been doing some work on the code, mostly involving i2c commands and addresses. Those are usually given in Hex in the datasheet, sometimes with binary reference, but you might find yourself needing to convert between the two and sometimes to Decimal.

There is a quick way to convert back and forth between all of them by hand with nothing but a piece of paper (you can do it in your head if you are good with numbers – I’m very bad at it :))

Anyway it’s a good old trick but it works.

Continue reading Quick tip – Binary to HEX and DEC conversion

When passion meets crazy people