11: Interface and Application Programming

This week I tried to implement an interface within Windows OS instead of Linux - I decided to first replicate Neil's python interface.

Some notes:
1. In windows 'sudo' and 'apt-get' does not work. Use 'pip install' instead.
2. In the Input week I wasn't able to install tkinter but I found a way this week following TkDocs webpage instruction. In Neil's hello.load.45.py tkinter was written with capital T. Changing it to lower case allows to import tkinter successfully.
3. To figure out available ports on the computer, I used this code from stackoverflow. I downloaded as a python code and found that in my computer 'COM5' was the only available port.

After this Neil's code ran successfully on Windows.

The first interface I wanted to try out was Grasshopper, partly because I use it often in architecture studio and I thought it would be good to learn how to communicate with the devices through that environment. Grasshopper requires an add-on called Firefly to listen to serial port.

I was hoping that this process would be simple- from my understanding ATTiny45 was sending the digitized signals in interger format (12 numbers: up_high1, up_low1, down_high1, down_low1... etc) converted from capacitance analog signals through the serial port. I first opened the serial port in grasshopper, and found that even though Firefly was able to identify the serial port, open it, but the output was empty. I wasn't really sure why this was, because the python version that Neil set up worked fine, and when I printed the value of up_high1 in hello.load.45.py, it was outputting the value to the terminal. Dalma told me that ord() returns an integer representation of the Unicode.

I just wanted to understand what Grasshopper was getting. I opened the arduino serial monitor and found that it was sending illegible characters (to arduino / grasshopper).

After some hours of frustration and searching I found Andrew Payne's HTMAA page, that describes the additional steps required to make the characters legible in grasshopper environment. This involved changing the binary representation - I couldn't figure out entirely what was going on (where the current digit is appended by '0') I moved on with his code.

  //function to write DEC value to the serial port
    void put_decimal(uint16_t value){
      uint8_t temp[6];
      int8_t p = 0;
      uint8_t i;

      while (value > 0) {
         uint8_t curr_digit = value % 10;
         temp[p++] = curr_digit + '0';
         value = value / 10;
      }

      while (p>0){
         put_char(&serial_port, serial_pin_out, temp[--p]);
         char_delay();
      }
   }
              

After updating the c code and reprogramming the board, the serial monitor was now reading integer values. There are large fluctuations in the values when the copper contacts the skin.

Since grasshopper firefly is built with arduino in mind, once the serial communication was legible to arduino, grasshopper was also able to read in the serial input. Here is the grasshopper chain set up with taking the first four values:

1. Port 'COM5' Open // open port for serial communication
2. Serial Read // start listening to serial
3. split the string into four values 4. evaluate the values using Neil's formula
5. average three values at a time to smooth output

What I found was that when there is a full contact between the copper and the skin, up_high and down_high tends to be 'null' character. For the time being I am replacing all 'null' values with 0 but I suspect there is something wrong in my importing method. Here is the graphic output of the result.