Categories
Uri_ba's pit Weekly Updates

“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.

Categories
Uri_ba's pit

[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
ΔA  CW  CW  CCW  CCW
ΔB  CCW  CCW  CCW  CW

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 🙂

Categories
Uri_ba's pit

Standalone Cougar TQS (Throttle) – Part III

In the last two posts we worked with the hardware and basic code for debugging. In this post we will go over the basic changes done in the actual code.

Everything is already available in the download page.
You can browse the code and download all the stuff you need (including a pre-compiled Hex, ready to be uploaded to your device – incl. a simple script to help with it for those of you who only want it to work :))

Here is a small clip showing how it looks in windows.

Now let’s dig into some technical stuff (only if you want to) 🙂

Categories
Uri_ba's pit

standalone Cougar TQS (Throttle) – Part II

In the last part We’ve went over the hardware side of building the DIY TQS adapter.

In this section we will discuss a bit on the firmware side, and the problems it creates.

Categories
Uri_ba's pit

DEDuino – V1.1.3

I hope this will be the last of the 1.1.X line

in this Version the FFI has come full circle and has been completly overhauled with the help of the community.

It now includes a new display mode dubbed “RealFFI” that renders like the real thing (rather then mimicing the BMS FFI behavior as before). Both version are available, with the Performance advantage on the BMS render mode.

New link for downloads, and it’s here to stay 😉

http://pit.uriba.org/download

V1.1.3 “RealFFI”:


A real FFI:

 

 

Categories
Uri_ba's pit

DEDuino – v1.1.1

Second quick patch for the DEDuino project.

Following input and assistance from “Moon” and “AiRdAncE” the VP community, I’ve been pointed to the real FFI font, “MilSpec 35588“.

I’ve adjusted size and removed unneeded chars to create a new custom FFI font pretty much in the correct size to match a real face plate. Once I have one fabricated, I’ll adjust the font some more – but for now that is good enough IMHO

This slideshow requires JavaScript.

As always, the code is available on github .
links are available on the Download Page

Categories
Uri_ba's pit

DEDuino – v1.1

First patch for DEDuino.

New features include:

  • a new optional DED font by “Cool hand” (activated by default)
  • A new optional FFI font based on the work of “Moon” (activated by default)
  • New FFI Bezel drawing  – based on the work of “Topper Harly” (activated by default)
  • Connector app bug fixes (Automatically updated)

Thank you guys for making this project even better

Source code and download links are available on the Download Page

Categories
Uri_ba's pit

Caution panel – tech post

Now that we have seen the Caution panel at work,
Let’s take a step back and have a look at the technical aspect of it.

This post will have some code samples and inner workings – so feel free to move on if that doesn’t interest you.

Categories
Uri_ba's pit

DED Adventures – Part 4 – And there be light

OK, So we got the DED and FuelFlow sorted out. we got a way to get the data over and drive the screen. Before we go on, let’s talk a bit about Arduino boards.

Arduino Boards are ATMEGA based development board, putting the I/O pins available for quick connections. Basic Arduinos traditionally have 13 available digital I/O pins and 6 ADC 10bit “analog” Inputs.

the “classic” arduino board is the Arduino Uno.
Based on the ATMEGA328P, a 16MHZ, 2K RAM chip that uses an on-board RS232 chip to handle serial communication via 2 of the 13 IO pins. I’ve done my initial prototyping work on this board and it works with comms of up to 96000 baud reliably. you might start catching some errors but YMMV.

on the other side of the scale there is the Arduino Due.
the Duo is ARM based 84MHz chip with 96k RAM, it has 54 IO pins, 12 ADC pins and so on. it’s bigger then the Uno.

in the middle this is the Leonardo, it’s about the same size as the Uno, but uses a different Chip, the ATMEGA32u4. However, it’s his little brother the Arduino Micro, is the one I’ll focus about. the 32u4  is pretty much identical to the 328P with a few exceptions, it has 2.5K of RAM, a bit more I/O pins, but the most important feature on the chip is that it has native USB capability, which means it can do serial communication much faster then the Uno. the added bonus is it’s size, the Micro is TINY, it’s slightly less the 5cm long, and has male headers in two rows, which makes it breadboard compatible, and allows an easier mounting . So I chose it and everything I wrote was Micro Optimized. However I do indend to try and make the code in an Uno version (but with diminished capability) and in  Due version (as Acef already has on – so why not).

And back to the design..

Categories
Uri_ba's pit

DED Adventures – Part 3

now that we covered the basics, and we know how to run our FuelFlow, we can continue our dive into the project. DED screen was chosen as it is the closest I could get to the real thing from the selection of avaiable hardware. I chose the BuyDIsplay 2.8″ OLED Yellow-On-Black another option would be the New Haven 2.8″ OLED Yellow-On-Black they both use the same u8glib constructor and are interchangeable (different wiring is required of course).

Let’s look back at the DED in the “flightData.h” file.

 //DED Lines
    char DEDLines[5][26]; //25 usable chars
    char Invert[5][26]; //25 usable chars

in C a string is a char array ending with null character (ASCII 0)
so we actually have 5 lines of 25 chars ending with a 0 (from now it will be referred as “\0”)
DED is actually 5*24, so I don’t know why the extra \0, so we can safely only transmit the 24 bytes.

in Part 1 you saw a video with an early code, in that code I’ve sent the two arrays and drew them with the arduino, that required multiple passes on both arrays, costing many CPU cycles. I’ve decided to do the manipulation on the computer side, sending only one ANSI array. However that required a special font to be loaded onto the Arduino/Display. The font was drawn as TTF, re-positioned to correct ANSI position, and converted to the Format u8glib can use.
I’ve created the font using fontstruct and it’s available here

I ofcourse had to write the code to normlize the entire thing

        private string NormalizeLine(string Disp, string Inv)
        {
            char[] NormLine = new char[25];
            for (short j = 0; j < Disp.Length; j++)
            {
                if (Inv[j] == 2)
                {
                    if (char.IsLetter(Disp[j]))
                    {
                        NormLine[j] = char.ToLower((Disp[j]));
                    }
                    else if (Disp[j] == 1)
                    {
                        NormLine[j] = (char)192;
                    }
                    else if (Disp[j] == 2)
                    {
                        NormLine[j] = (char)170;
                    }
                    else if (Disp[j] == 3)
                    {
                        NormLine[j] = (char)223;
                    }
                    else if (Disp[j] == '~')
                    {
                        NormLine[j] = (char)252;
                    }
                    else
                    {
                        NormLine[j] = (char)(Disp[j] + 128);
                    }
                }
                else
                {
                    if (Disp[j] == 1)
                    {
                        NormLine[j] = '@';
                    }
                    else if (Disp[j] == 2)
                    {
                        NormLine[j] = '*';
                    }
                    else if (Disp[j] == 3)
                    {
                        NormLine[j] = '_';
                    }
                    else if (Disp[j] == '~')
                    {
                        NormLine[j] = '|';
                    }
                    else
                    {
                        NormLine[j] = Disp[j];
                    }
                }

            }
            return new string(NormLine);
        }

The arduino side is very simple, so I will not elaborate much

char DED[5][26] = {{ 0 }};

void  readDED() {
  for (short i = 0; i < 5; i++) {
    Serial.print("D");
    Serial.print(i);
    Serial.flush();
    Serial.readBytes(DED[i], 25);
  }
}

void drawDED() {
  /// Begin Picture loop ///
  dedDisp.firstPage();
  do {
    for (unsigned short i = 0; i < 5; i++ ) {
      dedDisp.drawStr(DED_H_CONST, i * DED_CHAR_H + DED_V_CONST, DED[i]);
    }
  } while ( dedDisp.nextPage() );
  /// End Picture loop ///
}

Combining this, with the code we saw in the previous part, gives us a DED and an animated FuelFlow. in the video you can also see the indexers modeled by 6 leds, but that code uses a different logic, and will be covered in a later post.

BTW – The code shown here is pretty old, so there is a bug in the FuelFlow code used here, the snippet in Post 2 is already corrected (one of the benefits of starting a blog late)

Enjoy! 🙂