4th April – Lab – In class Demo

In the lab each of us presented our ideas and designs so far showing the development of our models. We used presentation for better visual demonstration making sure to score each other on the complexity, functionality, aesthetics and clarity of presentation. This allowed us to get feedback and comments positive and negative to help us further develop our designs.

The feedback I got was really helpful in letting me know exactly the areas that I need to attend to for my project. I have made notes on this and can now move forward positively after positive constructive feedback.

21st March Lab – Tolu

Seminar: In the seminar I did my presentation of potential ideas and inspirations that I have had for my project. This was a good way of presenting my project and also getting feedback from my peers as to ways I could improve my ideas, things I can add, and how to go about documenting my work.

Lab: In the lab we were looking at our individual projects. We were introduced to how we can access softwares that will help us to build the casing of our projects. In my case I know that in order for me to progress to the stage of case design etc I would need to make sure that my code works, my circuit is built and everything works accordingly so that I can accommodate this with my casing. I was able to grab inspirations from different Arduino keyboard projects and this helped me to understand the coding of tones and what numbers to type regarding the tone I desire. This has made my job easier for next lab as I can then come to the lab with the correctly selected codes.

14Th March Lab – Tolu

Seminar – In the seminar, we had 2 presentations from colleagues of potential ideas that they have for their projects. We scored them according to their complexities, aesthetics and functionality out of 4. We also scored them on their presentation skills out of 4.

Lab – In the lab we recapped on the learning of the previous weeks and went down to the mechanical workshop to tour and understand what we can do. In the tour we were given the availabilities of materials, tools and different options we could take in making our cases. With the options I’ve been provided I was able to get many potential idea of how I would want my project to look like. With all these branches of ideas, I still need to make sure I plan accordingly to the electronic and audio parts of my project the proceed to design casings and structures.

I am planning on using the mechanical workshop to create my casing. My idea is to produce a miniature keyboard/piano running from C to C. when a button is pressed it will play a tone that aligns with the scales of a piano. Tones should be able to be played at any time when the circuit is working.

7th March Lab – Tolu

We started the lab with a special guest. He was going through a similar project that he had completed to give us an idea of how to plan, things to implement in our timelines. He was also giving us the stepping stones to where he went wrong and the improvements he was and was not able to make. He was clear with his mistakes and even after everything was completed he gave us alternatives on way he could have made his personal project better. Overall it was helpful for me as it helped me to think of a possible idea, how to plan it and how to execute it.

We then recapped what we had done in the lab 2 weeks ago just to refresh our minds before we went into this weeks Lab.

We began looking into detail about timelines and gannt charts using knowledge we had gained from 2 weeks ago lab. We each created a draft of the timeline implementing possible tasks and milestones that link to what we would be doing for our final project. The aim for me was to make sure that there is time for iterations, time to make mistakes so that in the end I can at least have a working model if the casing was a problem. Making sure I have enough time to look at code, and circuit models have become the more important part for me to make sure I complete the task to a healthy standard.

21st Feb LAB – Tolu

In the beginning we looked closely at timelines. Specifically looking in detail about the similarities and differences between a Gantt chart and timeline. (Post white board screenshot)

Next week looked at the different softwares that we could create timelines and Gantt charts. Here below are the various options that we have towards creating these types of timelines.

Next we focused on Goals, tasks & milestones. Collectively looking at what they are, their differences and how we set them. Even looking to set some for our projects for specificity & clarity.

14th Feb Lab (online) – Tolu

As usual at the start of the lab we recalled the information and findings of the previous lab making sure we were up to date with everything that we learned and were caught up on anything we may have missed.

Firstly we looked at CC (Creative Commons license). looking specifically at BY 3.0. This is what I found out.

The Creative Commons Attribution License 3.0 (“CC BY 3.0”) is a public domain license which permits most forms of use or re-use of a licensed work provided that (a) due acknowledgement is made of the original source and authorship, and (b) no additional restrictions are placed on subsequent users.

In todays lab we looked at a new software called fritzing. This software allows us to build circuits, look at their PC layouts as well as export our creations to out computers. The first task was to create a basic circuit with fritzing. There is the ability to change the colour of the wires, the colour of the LEDs etc which I can do.

The next task in the lab was to design a PCB for the classic 74C14 Hex Schmitt Trigger oscillators. This circuit was a little bit more complex but I eventually completed as shown below.

Lastly we looked at the pros and cons of both tinkered and fritzing as a final discussion.

7th Feb Lab – Tolu

As usual we recalled information from last weeks lab as well as sharing information from our individual research on mozzi.

The first task was to build the circuit for the buzzer. I firstly built the circuit using the solder-less breadboard and then copied the code that would be needed to make the buzzer work. This was the code:

//Specify digital pin on the Arduino that the positive lead of piezo buzzer is attached.
const int piezoPin = 8;
void setup() {
}//close setup
void loop() {
/*Tone needs 2 arguments, but can take three
1) Pin#
2) Frequency – this is in hertz (cycles per second) which
determines the pitch of the noise made
3) Duration – how long teh tone plays
*/
tone(piezoPin, 1000, 500);//tone(piezoPin, 1000, 500);
//delay(1000);
} –

The final outcome was that the buzzer worked. We were able to play around with the delay time and the tone which would affect the pitch of the sound as well as how long the sound is played for.

The next task was to change the tone that it would continue to get a higher pitch as time went by. The delay time has to be changed for that to be made possible and this is shown below in the code:

//Specify digital pin on the Arduino that the positive lead of piezo buzzer is attached.
const int piezoPin = 8;
void setup() {
}//close setup
void loop() {
/*Tone needs 2 arguments, but can take three
1) Pin#
2) Frequency – this is in hertz (cycles per second) which
determines the pitch of the noise made
3) Duration – how long the tone plays
*/for (int i=31; i<10000; i++) {
tone(piezoPin, i, 1000);
delay(10);

The next task was to upload a Mario tone. Using the code it would use different delay and tones to create the melody of the Mario tone we all know well. My outcome was positive in the end even though I did run into an issue with the upload of the tone. This was because I was working with 2 active functions in different tabs. I fixed this by beginning a new file and putting in the code and it worked. (The code is toooooo long to copy into here)

The next task was to create a digital oscillator. This had a different breadboard configuration so I firstly put the components on the breadboard first. Then I uploaded the code on to Arduino. This is the code that was used:

//CODE DigitalOSC ******
const int ledPin = 13; //variable to represent LED Pin
const int periodKnob = A0; //variable for knob pin (A0 = analog in pin 0)
int delayTime; //variable for the delay time

void setup() {

pinMode(ledPin, OUTPUT); //configure pin 13 as a digital output

}

void loop() { //set delay time equal to the current value read on analog pin 0 delayTime = analogRead(periodKnob);

//map the analog read range from 0-1023 to 10000-1 //delayTime = map(delayTime, 0, 1023, 10000, 1);

digitalWrite(ledPin, HIGH);

delayMicroseconds(delayTime);

digitalWrite(ledPin, LOW);

delayMicroseconds(delayTime);

With this code I was able to use the knob to change the tone of the sound. turning it up to make the tone high and turning it down to make the tone deeper.

31st Jan 2022 – Tolu

In this lab we began by recalling the information from codes that we studied in last weeks lab. We then took one of the codes we used and began to look in depth at the functions and the variables of that code to make more sense of it.

Next we took time to look at different softwares/libraries that are available to produce sound on Arduino. I looked at Teensy and Mozzi. These two are similar audio libraries that enhance the function of the one we have on our board. They don’t need any external boards to work and can produce a variety of sounds and sounds can be altered using the builtin audio toolkit which includes things like synthesisers, oscillators and delays.

(Individual research task)

What is mozzi about?

Mozzi allows the production of more complex and interesting growls, sweeps and chorusing atmospherics. These sounds can be quickly and easily constructed from familiar synthesis units like oscillators, delays, filters and envelopes. 

You can use Mozzi to generate algorithmic music for an installation or performance, or make interactive sonifications of sensors and can be done without additional boards.

From listening to the sounds, there is the ability to:

  • modulate amplitude
  • change shapes of waves
  • change sounds using oscillators

What are key features?

  • variable control rate
  • designed to be easy to use & extendable
  • has a broad audio toolkit: oscilators, samples lines, filters etc.

Weird Behaviours

audio glitches can be caused when calling delay or other functions that wait.

analogRead() is replaced by mozziAnalogRead(), which works in the background instead of blocking the processor.

24th Jan 2021 – Tolu

In the beginning of the lab session we were reminding ourselves of the previous lab and the things we did.

The first task of this weeks lab was to build a circuit that would cause a push button to control a LED using the bread board, Arduino software, switch and resistor. I firstly began by putting all the components in the right place on the breadboard then making sure that my circuit board also had the correct components in the correct place. After doing all this the next step is to put the code into the Arduino software. Making sure that everything is clear and there are no errors. Verify the code and upload the code and check using the switch if the LED is being controlled when you press it. Good for me it worked.

The next task was to use the code that would cause the LED to remain on after the button had been pressed. The code does not really change however it just gives the instruction to Arduino to “store” the value of the integer that keeps the LED on. This is important because without the store function, the LED would not be able to stay on. 0 = LED off and 1 = LED on. The state variable was determining whether the LED was on or off. The end result was that the button worked for me.

Next I used an improved code because there were times that the button was pressed and it wouldn’t register meaning the LED would either not turn on or turn off. The reason for this is because there’s bouncing from the two pieces of metal inside the button. The bouncing is only for a very small distance and happens for a short time, it causes the switch to change between off and on a number of times until the bouncing stops, and Arduino is quick enough to catch this. The outcome still worked for me at times but not consistently so I went ahead to use a code that would help with the bouncing.

The next code was more improved. It wanted to use the change of state (on and off) and keep them so that it was consistent. The main thing in this code was the if state (high and low). This is a point where the code is remembering the previous function. For example if the switch is off, when you press it the LED comes on. Even though it has changed from on to off it remembers the previous state of the LED being off so that when the button is eventually pressed again, the previous remembered function will be applied (The LED turns off).

The next task was Controlling the LED with PWM. Our task was to take advantage of the effect of Persistence of Vision (POV). In the code, by changing delay times if i made the on delay different from the off delay, yI would make the LED brighter by leaving it on for longer, and the LED dimmer by leaving it off or longer. The technique being used here is called pulse-width modulation aka PWM. This is because there is a change in the LED’s brightness by changing the width of the pulse. My end product produced an LED that was dimming and relighting.

17th January 2021

In the beginning of the session, students that took part in a previous module demonstrated their models that were created. It was cool to see how light could affect sound.

The first thing we did in the lab was to look at the Arduino board. Looking at the different part of the board and identifying specific parts of them making sure that we know where things would be placed.

We began coding using the software Arduino. the first task was to implement the coding that would cause the LED to flash. Making sure that each step was followed I was able to complete this and get the correct outcome.

The next task using Arduino was to experiment with the delay time of the LEDs changing them in the software just to see how a smaller delay time would affect and how a higher delay time would affect the rate at which the LED flashed.

Next we looked at using a function to loop 2 chosen letters for me which were L & H. when performed correctly using the correct format the end product would be automatic looping of L and H as such … LHLHLHLHLH etc. We did this by set up a function that would enable a loop when we were to go into the serial monitor. Making sure that all instructions and functions were written accurately and carefully spaced out, I was able to achieve the final goal.

The final task we did was to substitute our old functions for a new and simple one to get the same end goal of the blinking LED. This was done by first of all naming our function and then pasting it in place of the the long function that was used in the first task. This task was well performed as I had a good outcome with the blinking LED.