Third electronics-related lesson of the FabAcademy. This time big step: learning code. The goal? programming the board I have made previous week, including a switch and a LED, to do something.
Understanding the communication
Very important at this point is to understand the connections we are establishing between the board and the computer. They are:
  • AVRISP connection: it powers the board and allows the computer to talk to it. It is through here that the code is loaded into the ATTiny.
  • FTDI connection: it powers the board and allows it to talk to the computer. It is through here that the board communicates back with the computer and with us through the serial monitor.

    Always install an FTDI header, if only to be able to calibrate the board or to debug if necessary. Then the header can be removed in space is needed.

    The second image represents the schematic for the FTDI cable, which has defined the order of the pins in the schematic as seen in image 1.



Note: important not to plug both cables at the same time. Instead, plug and unplug ISP and FTDI cable from the same USB port for an agile programing and serial communication with the board.



Setting up the communication

In order to set up the board to communicate to the computer and work with the Arduino IDE, the next steps were necessary:
  • Install ATTiny in Arduino environment as explained in this tutorial, so you can program ATTiny microcontrollers using the Arduino IDE.
  • Install the Crosspack for AVR Development (see explanation here) with the help of this tutorial. This is the necessary platform for programing AVR microcontrollers.
  • Install the VCP and D2XX Direct drivers for FTDI-USB using this tutorial (when done successfully something like "/dev/cu.usbserial-XXXXXXXX" should appear in the Arduino IDE under Tools > Port).
    • VCP drivers can be found here. As easy to install as opening the package and following the steps.
    • D2XX Direct drivers can be found here. As indicated in the cell specific for my OS X, you do not only have to install the drivers themselves, but also D2XXHelper to prevent weird errors from happening with newer versions of OS X. The D2XX drivers are trickier to install than the VCP, so download the .dmg and follow the instructions in the Readme.txt file. Be careful! since the steps for the terminal commands only work if you have copied the folders contained inside the .dmg and pasted them on your desktop. Also, the commands for the terminal don't all really match the directories of the files inside these folders, so adjust them (specifically the libftd2xx.1.2.2.dylib, that can be version 10.4 or 10.5-10.7 for newer versions). Apparently Emma recommends installing the 10.4 version.
      You could do all this copy paste by hand, for which you would need to access /usr/local/lib and /usr/local/include (both hidden from the Finder) through Go > Go to folder  (Cmd+shift+G) in the Finder . I used the terminal commands to do the operations, but checked afterwards that the files were indeed pasted in the new location since the Terminal doesn't give any feedback about the commands being successful. Ufff...

  • Make the AVR ISP cable for the communication between the ISP and the echo.hello-wold, making sure that wire 1 (white wire in my case) was aligned to the mark in both the headers.
  • Find the right orientation of the communication PINS in both the ISP and the board (marking them with a dot), so one makes sure that every Pin is connected to its relative on the other board.
  • Connect the ISP to the USB and the Echo.Hello_world board and burn the bootloader: Tools > Burn Bootloader. Make sure you have selected ATtiny as “Board”, ATtiny44 as “Processor”, 20MHz (external) as “Clock” and USBtinyISP as “Programmer”.
Everything should now ready to program the board from the Arduino environment.
Coding

First thing I tried is to upload the "blink" sketch from the Arduino examples to see if the board actually worked. For that, and given the fact that I am not using an Arduino UNO board, the first step was to redefine the pin that is connected to the LED. The following picture is an essential one for that purpose, and it is not included in the data sheet of the microcontroller. It establishes the relation between the pins in the schematic and the actual pins to be used in the code.


Having defined pin 7 as my the pin for the LED in the code (6 in schematic), I uploaded the sketch and the LED blinked with a second of delay. Yay! I tried modifying the delay to see if that also worked, and it did. I was ready now for including the tact switch into the equation and making both do something.

I had already worked with Arduino before and therefore I was somehow familiar with the structure and some of the functions, variables, libraries and so on. However, I decided to take the beginners approach and started from scratch by reading the book Getting Started with Arduino, written by one of the Arduino founders, Massimo Banzi.

As I advanced in the book I was going through different small incremental exercises used to explain different elements in the code every time (always including a LED and a tact switch). I wrote and coded everyone of them, and following you can find the exercises in the order that were done, a video demonstrating the interaction and the related code.
  • Exercise 1: the LED turns on when the tact switch is pressed and it turns off when the pressure is released (video 1). The code, that can be found here, is pretty basic and includes only one variable for the digital input of the button and an if statement for the behavior of the LED. The functions digitalRead, digitalWrite and pinMode are introduced in this exercise. Video 2 shows the total opposite (LED is always on and turns off only when the tact switch is pressed) because, in my case, LOW as an input value means that the button is pressed. This happened because  of the way the tact switch is connected to the microcontroler, reading the pin 0v (LOW) when the button is pressed.










  • Exercise 2: the LED turns ON and OFF alternatively every time the tact switch is pressed, remaining in its ON and OFF state when pressure is released. In this exercise, the code (find here) deals with difficult aspects like refreshing the value of the digital input variable to avoid multiple reads when the button is pressed, and performing a different action depending on the state of the LED (turn ON if it is OFF, turn OFF if it is ON). In this exercise, the function delay() as well as the boolean operator && are introduced.




  • Exercise 3: let the LED fade in and out. The objective was to understand the concept of PWM (Pulse With Modulation) in the simplest possible way. In the code (find here) the function analogWrite is introduced.



  • Exercise 4 - Final exercise: a combination of both exercise 2 and 3, the intention was to have the LED switched ON and OFF when the button is pressed once, and increase its brightness over time if the button is pressed for more than half a second. In the code (find here), the function millis() is introduced.

Serial Communication

 In addition to the previous sketch, I though it would be nice to try at least to establish a serial communication between the board and the computer.
  • Exercise 5: I started with a very simple code in which I eliminated all the fuss with the LED and the switch in order to stick to the serial communication. I basically made the board to say "Hola!" (hello in spanish) to the serial monitor every second. Find code here.


  • Exercise 6: for the second trial, I integrated the communication into the sketch for Exercise 4, making the board write "LED on", "LED off" or "Dimming" depending on the state. Code can be found here.
 




 Workfiles



Publicado por
0

Añadir un comentario

  1. Last week I set out to design and make my very first input & output board from scratch. I decided to build on the previous prototype and use the same battery module in order to power the new design. Because I wanted to use a vibration motor since almost the very beginning and I found a nice way to do it by making a free wheels wooden casing with wooden balls, I went for it in combination with the idea of "taming" the toy by blowing at it. 

     Needless to say, I built on Franz example as well as the input devices week documentation from Loes. For the vibration motor, the set up seemed to not be difficult at all and and I started looking at my own output devices week in order to figure out the schematic design in my mind. However, I soon realized, after a quick search on Google, that motors need a few important things around them that I don't have in the board made that week.

     Working Board Design: schematic

     The first design I made is also the one that I went on to mill and includes several errors that made the communication with the serial port impossible, it is explained in next section. The following one is the last, after being corrected by Emma. Fortunately enough, the footprint of the components that needed to be substituted was the same, what allowed me to correct the errors without milling another board.


    • The set up around the microphone is quite a thing. Although digital microphones can be used, I don't know much about them and I went on for the safest option, since there was quite some documentation.
      • OPAMP (operational amplifier) is necessary since the small signal at the end of the microphone is right at the limit of what you can read with the ADC.
      • The combination of resistors and capacitors around the OPAMP are what is called a "bias circuit", whose role in fact is to feed the amplifying devices with the electrical power (DC) to activate it and make it capable of amplifying signals, which are time varying (AC). After biasing, the amplifier is able to receive the signal to be amplified at its input (more information in my Glossary of Electronic Terms). The chosen values are based on Loes example, which at the same time are based on Neil's example. In essence, the values of these components will set the gain provided by the OPAMP, together with the gain that can be achieved through software.
      • Microphone has orientation! Terminal 1 goes to OPAMP, terminal 2 goes to GND (check data sheet).
    • 3.3 volts regulator in order to power the vibration motor, that actually works at a maximum of 3.6 volts. Always go for the regulator that can drive 1A, since very few things like an IC, a motor and a led are enough to be demanding more than 100mA.

      The data sheet gave an example of a typical application circuit in which 10µF and 100µF capacitors accompany the regulator. The reality is that I installed a couple of 0.1µF capacitors in both sides (as done in previous occasions) and it is working.

      Fortunately both the microcontroller and the N-MOSFET work at 3.3 volts, but it is important to check beforehand in the respective data sheet.
        • As for the microcontroller, the Operating Voltage is 1.8 to 5.5 (see data sheet).
        • As for the transistor (MOSFET type N), the VGS (Gate-Source threshold voltage) sits around the 1-2 volts, which means that 3 volts are enough to activate it.
    • The 0Ω resistor after the regulator is there in substitution of a wrongly placed one. It was supposed to be limiting the current through the motor, but the fact that I took VCC after this resistor made that the powering voltage of the microcontroller was fluctuating depending on the current demanded (V=IXR). A mess, specially for the proper serial communication to happen. Placing a 0Ω resistor fixes the voltage and the 3.3 volts regulator outputs the right amount of voltage for all the things to work.
    • Attiny 84 was chosen over 44 because of its bigger capacity. Make sure VIN (voltage before amplifier) and VOUT (voltage after amplifier) go to ADC pins! (this is an analog microphone).
    • Resonator isn't necessary because the design is not very demanding in that sense (I am not using complex communication between boards) and there are ways to establish serial communication without a very accurate clock (see section below).
    • For the motor:
      • MOSFET type N: be careful when picking the component to make sure is type N! It drives current through once current is applied at the gate. The resistor before is not really necessary. According to this tutorial, it is necessary to avoid too much current from the MOSFET can be damaging the motor, but Emma said is not really necessary. It is not a pull down resistor since it is not connected to GND.
      • The diode acts as a surge protector against voltage spikes that the motor may produce. The windings of the motor notoriously produce voltage spikes as it rotates. Without the diode, these voltages could easily destroy the microcontroller.
      • The 0.1µF capacitor also protects the microcontroller by absorbing voltage spikes produced by the motor.

     Milling the board: double side
    My first double sided board. Made with an advanced milling machine, the twisting was quite easy. Double sided boards can save you a lot of headache with the layout, but they are more difficult to make. Specially avoid having too many vias, since connecting top and bottom for each of them is a tedious work. Here there are a few things to keep in mind:
    •  Change routing in Eagle from Top layer to Bottom layer and the vias will appear automatically.
    • Sometimes auto route in Eagle uses component holes as vias. If you haven’t soldered those holes, top and bottom won’t be connected.
    • Don’t put the vias underneath any component or next to their legs. They will not allow it to properly sit on the board.
    • Make thick traces, specially if you are milling the double sided board in the Modela, because the accuracy is not exceptional and you don’t want mismatches between Top and Bottom traces.
    • Double check the vias with a multimeter. Many times, really. They are challenging to make and the piece of wire might not be connecting both sides even when the soldering looks perfect.
    • Place components also on Bottom side. This way you can reduce the amount of vias considerably (otherwise lines have to go from top to bottom and to top again).

     Programing the board
    Programing this board was quite an odyssey at the the beginning. Because VCC that powered the whole board was fluctuating due R2, the communication with the serial port became impossible. I am still wondering how I was able to read something sometimes. These are some of the faulty readings I got:




    Because I didn't include any regulator (8MHz internal clock is enough) there is one thing that needs to be done:
      • Run this piece of code by Zaerc in your board.
      • Let the serial monitor tell you which configurations (hexadecimal numbers) work best for your specific case.


      • Pick the number in the list that is half way the faulty communications (0x6E in my case approximately, one among the good ones, in the middle) and include it in your other code as a script right before starting the serial communication.
    I basically run a code to check that the serial was this time working properly (find here), another one that gave me raw and mapped values from the microphone (find here), a third one that exclusively pulled the pin 7 down (pin attached to the motor) before attaching the motor (find here) and the final one that activated the motor when the microphone detected a blow (find here). The last piece of code is making the toy do the actual opposite (stops when microphone is blown) and includes a little delay before it starts vibrating again (find here).





    Caution!: for some reason the communication with the serial monitor interfered with the proper driving of the motor, so I decided to comment out all the serial communication lines in the final code.

    Important things I have learned
    • Regulators and other components, although equal in package, might have different pin out configurations. Be very sure about which one yours have before using any given footprint!
    • Next time use trick to connect soldered wires (see picture) in order to minimize risk of breaking. Or even better, use female and male headers to safely connect wires in a reversible way.

    • Most of microcontrollers have internal pull up resistors so pins are HIGH by default. Consider that when plugging your things to it, so they can go crazy before the code starts running.
    • Actually, it is quite likely that when board is being programmed (plugged to the ISP and the computer) all the things go crazy (leds on, motors running...). The microcontroller also takes a few milliseconds to start running the sketch. Keep it in mind.
    • Always make sure that the microcontroller is powered at a steady voltage. Specially if you want to establish communication: 2 boards can't communicate if they are working at different voltages (domains), even if the difference is small.
    • You can always reburn the bootloader as a way to “reset” the microcontroller when you notice  that strange things are happening.
    • Always read raw values when measuring analog input. Before you move on to set thresholds, make sure that the raw values fluctuate properly.
    • Good to know that there is no magic with electronics. Sometimes it might seem like that, but when things don’t work it is more than often a human mistake. That’s what debugging gear is there for.
    • Never trust values that are not fully stable. I have experienced how a board that was completely wrongly designed and running a program that made no sense, did things that were very close to what I wanted it to do. Not enough. Find the reasons and don’t take anything for granted. Double check is your friend.
    • Do not to panic. As usual, search for the easiest and most immediate thing you can do to advance towards an answer without asking. Ask to yourself, try to explain the situation to yourself before you reach out to others. Start from scratch if necessary, looking at the most basic things you took for granted. The fact that you were checking step by step and that it was working before doesn’t mean much. Swallow your ego and consider the option that you might have neglected something.
    • Always remember to show your layout to an expert before you go on with the milling.
    • Keep yourself open to the option of tweaking an existing board that has failed or has been wrongly designed, specially if it is for a prototype. I like thing when they are well done, but being able to repurpose boards in a cheap and dirty way is a very handy skill.
    • When boards are complex, and specially when motors are pulling a lot of current, it is recommended to use the whole plate as GND.


     Working files



    Publicado por
    0

    Añadir un comentario



  2. Last lesson of the FabAcademy electronics for the external learning activity at TU/e. This time maybe one of the most magical and surprising ones, it is still a big surprise for me what is possible to achieve with very few lines of code in a software like Processing, the one I will be using during this assignment.

     The goal is to make some sort of animation that interfaces with an input from a physical device. In my case, I will be using the hello echo board I made in week 2. 
    Getting started

    Having the application eventually interfacing with the board means that I will be in need of at least 2 sketches: one for the board (Arduino IDE) to read an input (digital or analog) and send data to the serial port;  and another one for Processing to read the input from the serial port and turn it into something interactive. Geometries are basically defined by some very few values, and a combination of only a few lines intelligently written can produce pretty impressive interface animation.

     The first step was to make sure that the serial communication between the hello.echo board and the computer was working correctly. I remembered the last exercise during week 3 involved sending information about wether the led was on and off ("Led on" or "Led off"). However, I wanted to keep it simple and I used an even earlier sketch for the hello.echo board with which the led only switched on when the button was pressed. I add a couple of lines to send the value "1" to the serial monitor when this happened and added a couple of delays to make sure the serial didn't read too many numbers for every press, just one. This is the modified simple sketch.

    Starting with a cute example that took the mouse click as an input to change the color of a cross that tracked the mouse movement (MousePress example),  I set out to modify it and include the push of the switch embedded in the hello.echo board as input. I looked at the Processing code in the documentation of other students and found some interesting things:
    • import processing.serial.*;
    • Serial myPort; 
      [...] 
      myPort = new Serial(this, "/dev/cu.usbserial-FTHC3YU2", 9600);

      This lines of code are very important for they set the communication between the serial port through the FTDI cable (address and baud rate need to be specified) and Processing, so the program can take the date coming from the serial as an input.
    • myPort.bufferUntil('\n');This line tells Processing to wait and not do anything until it gets the data it is waiting for. 
    • void loop() is in Processing void draw(), but still is a loop.

     Example 1: mouse cross change color
    Starting with the basic MousePress example, I modified it to get the press from the switch of the hello.echo board instead. The cross that follows the mouse movement switches from black to white when the switch button is pressed. You can find the code here.




     Example 2: Mouse Color Squares Pattern
    Building up on the same example, a series of rectangles are drawn based on the position of the mouse, superposing each other for every loop of the program. When the switch button is pressed, an new background is drawn and therefore the animation is reseted. You can find the Processing code here.




    Example 3: Switch Opposite Squares
    Starting with the Mouse1D example, I substituted the x coordinates of the mouse by clicks on the switch button as inputs for the squares to change size and fill color. You can find the code here.



    Workfiles


    Publicado por
    0

    Añadir un comentario


  3. 6th lesson of the Fab Academy. This time Networking & Communication, the fearsome exercise. I had heard from past Fab Academy students and from Emma herself that this was one of the most difficult week assignment, and it didn't arrive in the best moment since I am close to the Mid-Term Demo Day. So I decided to keep it simple...

     There are various reasons why one would want to break a bigger system into subsystems that communicate with each other. The more obvious one is because different parts of the system need to be in different locations, but there are less evident reasons, mostly related to the need for simplification. Many small processors doing one task are easier to debug and give less problems with interferences that one big processor doing many tasks, for instance.

    The intention of the assignment therefore was to design and build a wired and/or wireless network connecting at least two processors. Before I go on I would like to thank Loes Bogers for the splendid support and the reference to this very useful resource of Arduino knowledge.


    Some info about the different communication protocols

     The first thing worth mentioning is that the networking protocols for wired and wireless communication are the same but the wireless communication is enabled by an additional piece of hardware (radio, bluetooth, wifi...).

     Asynchronous serial
    Supported by all microcontrollers, the data is transferred without the support of an internal clock, which means that there needs to be an agreement between the devices based on some rules.
    • Baud rate: how fast the data is sent. Measured on Bits per Second (BPS), some standard baud rates are 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200...
    • Data bits, synchronization bits and parity bits: define the data package. 
    • UART (Universal Asynchronous Receiver and Transmitter): the piece of hardware inside some microcontrollers that regulates the communication traffic. If the piece of hardware is not included in the microcontroller the asynchronous communication can be enabled through software. Arduino IDE SoftwareSerial Library is one of them. I understand now why I had to call this library when I wanted to use the serial monitor to read values during week #3.
    • 2 wires: Tx for transmit and Rx for receive. Communication only happens from Tx to Rx, which means that we need one cable for Tx and another for Rx.
    • GND should be shared, like in real world. If humans would not share the same ground, communication would be pretty impossible...
    • Pitfall: the main problems with the asynchronous serial communication are that the devices have to agree beforehand in the transmission speed, and the lack of clock can make the communication quite unstable.
    SPI (Serial Peripheral Interface)

    Synchronous data bus that uses separate lines for Data (MISO & MOSI) and Clock (SCK), as well as one line per slave (SS). It is not supported by every microcontroller (for instance ATTiny - see data sheet!).
    • 4 wires (at least):
      • SCK (Signal Clock): Master generates the clock signal.
      • MISO (Master In Slave Out)
      • MOSI (Master Out Slave In)
      • SS (Slave Select): a wire is required for each slave, and therefore a pin in the microcontroller. Master pushes the line of the specific slave down when it wants to talk to it.
    • Programing: SPI library (not for ATTiny) or shiftily() shiftOut() commands in Arduino IDE.
    • Pitfall: the main problems with the SPI protocol is the need of so many pins (4 at least, plus one per extra slave).
    I2C (Inter-Integrated Circuit)

    Also called TWI (Two-Wire Serial Interface), it is probably the most powerful communication protocol. It can support up to 1008 devices with only... 2 wires!
    • 2 wires
      • SCL (Clock Signal)
      • SDA (Data Signal): address bits and data bits. Different devices are identified with different addresses.
    • Programing: TinyWireM and TinyWireS libraries (for ATTiny) as well as Wire library (for ATMega) in Arduino IDE.
    • Check Loes documentation for more specific info.


     The chosen connection: wireless SPI using the nRF24 radio module


    This time I wasn't quite sure how I wanted to integrate the present exercise in my Final Project, so I decided to go for the wireless communication. Although I2C is the most interesting communication protocol to explore, a wire is a wire and if I want to make magic toys, some nice invisible communication might be useful in the near future.

     I opted for the nRF24L01+ radio module, which besides the IC radio frequency transceiver (data sheet), has a built in antenna,  on chip voltage regulator and can tolerate 5v inputs (so the microcontroler can still work at 5 volts!). This type of radio modules are produced in such quantity that it is impossible to make it any cheaper. Moreover, they include all the elements that the radio needs to function: oscillator, mixer, power amplifiers, low noise amplifiers, filters, antenna... 

     This specific model is ultra low power, supports high date range and uses SPI communication protocol, although the distance it can cover is relatively short. It works in the 2.4GHz license-free frequency band (quite busy) reserved worldwide for anyone's use and it is largely used in market applications such as simple remote controls (for doors and windows), wireless peripherals, voice transmission, wireless sensor networks... The only thing that needs to be made is the base board in which the modules are connected to the respective microcontrollers.

    Setting up the hardware
    I used a couple of radio modules (what is the point of having a radio talking to itself?) and two Arduinos, since the aim of this exercise for me was to understand the wireless communication protocol and its possibilities with the module, and not so much to build the boards myself. I will have plenty of opportunities to make boards for the different prototypes next semester. One of the things I am observing as I feel more and more confortable using Eagle and making my own boards, is that I dislike breadboarding more and more. However, making the boards from scratch is still a lot of work, so being able to quickly improvise dirty solutions for test with breadboards and wires is a good skill to have. The more resourceful I can be with basic electronics material, the better.

    The first thing I realized was that with the 2x4 pin header, it was impossible to mount the modules on a breadboard, so I had to improvise a solution. Fortunately I had a rainbow cable with a 2x4 header and some borrowed alligator clips that I used to connect the pins of the board with the Arduino. As I said, quick and dirty. This is how the two modules looked after being connected (I had to use some insulation tape to make sure the aligator clips didn't touch each other!).



    I hooked up the modules to the Arduino boards, with the pinout as seen in the picture and the specific Arduino pins for the updated RF24 library to work. Other available libraries were RF24Mesh and RF24Network, probably better for networks of more than 2 radio modules.



    I learned (again) how to install the Arduino libraries from the Arduino IDE directly, quite handy to make sure you install them in the right directory. Simply by opening the Arduino IDE interface, Sketch > Include Library > Manage Libraries... and typing the name of the library you are looking for.


    Important: libraries available through the IDE are not always the most recent and updated ones, so it is worth checking for the newest version outside the IDE, normally in GitHub. Sketch > Include Library > Add .ZIP library will place the download folder (not necessarily a .zip) automatically into the right place.


    Getting the Arduinos to communicate through the modules

    I started by trying the GettingStarted example from the RF24 library, a sort of ping-pong play between the two boards, sending and receiving bits respectively. The example makes use of the embedded auto-ack and auto-retry of the radio modules that enables them to feedback each other about the successfulness of the communication and try again if it failed. The example also allows ack-payloads (acknowledgement payloads) to be written, which enables primary receiver to switch to primary transmitter if wanting to initiate communication instead of only respond to a communication. This way both can be master and slave.

    The key is to upload the same code to both microcontrollers, only making sure you give a unique number to each of them by commenting and uncommenting the following lines:


    After that, and through a serial monitor set to 115200, the only thing that needs to be done is to press "T" for one of the microcontrollers to start sending. Everything went ok and the other microcontroler started receiving and sending response right away.



    To officially complete the assignment, I wanted to have at least a led reacting to the wireless communication. After the piece of software that told the receiver to "pong back", I wrote a few lines that made a led connected to   the board switch on and off every time there was a successful communication (ping - pong). You can find the hacked example here.





    Sending sensor values

    Still, If what I want in the future is to have two prototypes communicating in the distance, I need to send more complex messages than simple  "Hello I am here - yeah me too". That would mean, for instance, sending variables from an analog sensor to a remote actuator.
    With some help again, I started by trying to send a simple constant from one radio to the other using the same previously mentioned sketch. However, the experiment quite didn't work because I was somehow trying to fit a  mono directional communication (sending a variable from one module to the other) into a bidirectional setup (ping-pong). After understanding this, I opted for trying a totally different code, much shorter and addressed to sending variable values, found in this tutorial. In the example, one radio sends the values of a joystick (basically two potentiometers) to a second radio that displays the values. I decided to use a potentiometer myself attached to an Arduino to control the brightness of the previously used led (attached to a second Arduino) and see if this was a good sketch for transmitting simple variables. As it turned out, it was. 

     Actually, they were, because two different sketches are necessary for master and slave. They include an extra library not present in the previous ping-pong sketch (nRF24L01.h - explanation in the link-) and I had to modify them to get rid of some bugs (common problem according to the comments on the tutorial itself). 
    The working code for the master (find here) relies on the function radio.write to send the values of an array previously declared ([1] represents the size > only 1 element in the array) without initializing it. potValue [0] means index 0 of the array, that is, the first element of line of variables. More info about the arrays can be found in the Arduino Playground. 

    Before that, the pipeline (or transmission line) was chosen to carry the alternating current of radio frequency necessary for the connection to happen between the radios.


    The working code for the slave (find here) relies on the radio.read function to fetch the data payload from the previously defined array if the radio is available (again an array with only 1 variable, the value from the potentiometer at every given time), printing a signal of "No radio available" otherwise. It controls the brightness of the LED attached to a PWM pin and prints the values from the potentiometer as they are being read.



    In the void setup, the communication is initialized and the module is set as a receiver.

    As an extra for the future, I like the idea of including the pinout of the hardware in the code. 

    At the end, the two sketches made for a successful wireless communication of the potentiometer values on the one side to an Arduino controlling the brightness of a led on the other, also displaying the values on the screen.


    Workfiles
    Publicado por
    0

    Añadir un comentario


  4. Fifth electronics-related lesson of the FabAcademy. The intention for this assignment is to get even more used to designing and making a board, in this case one that can control an actuator.

    Since the semester is fairly advanced and I need to prototype some of the ideas I have been having for the wooden toys, I decided to use a fan. I really like the idea of a toy that blows a gentle breeze to your face. Not only sweet but stimulating and relaxing to some extent.

     The Fan
    The fan is essentially a set of blades attached to a DC motor. They are often used to cool down electronic devices but in this case I am planing to give them a more pleasurable use. Depending on the kind of bearing they mount, they are more or less efficient, and more or less expensive. In this case, and thinking in small steps, I have chosen a fairly small model, reasonably powerful and that does not consume too much current (160mA). If the thing works well, I will think of buying a more efficient one, maybe under the 75 mA. has only 2 wires, one connected to VCC (5v in this case) and another to ground, and it only spins in one direction.


    The Schematic


    The circuit that drives the motor is relatively simple. However, there are a few important aspects to take into consideration now that we enter the world of actuators with this exercise. Some components that will play an important role are:

    • Regulator: a component designed to automatically maintain a constant output voltage from a range of input voltages.  Although the fan I am using works at 5V, it takes more current that the one the microcontroller can handle. Moreover, and thinking of the integration of the circuit in my prototypes, I want the board to be autonomous and therefore be able to power it with a battery. For those reasons the regulator becomes essential.
      Capacitors are recommended both in the Input and the Output       of the regulator, as show in the picture, to help filter and control the loop respectively. Moreover, a diode was placed at the exit of the regulator, avoiding back current flowing between OUT and GND when the board is powered through the AVRISP. This would cause the internal resistor to heat up in excess, and damages in the regulator might occur. 

      Regulators will burn if connected backwards!       Neil recommends placing another diode before the regulator, but I opted for not doing it (one more component, more space, more cost...). Instead, I engraved a + and - symbol next to the connections, so I make sure I don't place the cables wrongly      . It is also important to not connect the board to both battery and the ISP at the same time, or the regulator can burn.

      Very important! Make sure that your regulator is able to handle the amount of current that your device need from the power source. I didn't...      As a consequence of the use of the regulator, there are now two kinds of "power nets", one between the power source and the regulator (POWER), and another after the regulator (VCC). It is important to know to which power net every element should be connected to.
    • MOSFET Type N: a transistor, by far the most common in both digital and analog circuits, it requires very little current to turn on (less than 1mA), while being able to switch a huge amount of power (10 to 50A or more) with very little resistance. They can be N type (NMOS) or P type (PMOSF) depending on the type of semiconductor substrate they are made with.
      In the case of the N-MOSFET, electricity will flow though a piece of semiconductor material (between the Drain and Source pins) when a voltage is applied to the Gate pin. The closer to 5v the difference is, the more current is enabled to flow.       If the applied voltage is low, the current flowing is also low. If the applied voltage is higher, the current flowing is also higher. This way the speed of the fan can be controlled through PWM! In this case, the MOSFET is needed because the I/O pins of the ATTiny can only supply 40mA, and the fan needs 120mA to work, so the microcontroller only sends the instructions to turn ON and OFF the MOSFET, and the later drives all the needed current.

      In general, the use of N-MOSFET is preferred over the P-MOSFET, since the 5v difference between Gate and Source can always be achieved via the microcontroler if GND is the source (P-MOSFET), but not if the source is attached to a component that works with a greater voltage level (see picture below for more info).

    • ATTiny 45: small yet big enough for the current application. As can be seen in the schematics, pins 6 and 7 are given a double use! What a revelation! Apparently this is a very common practice when the use of the pins don't overlap. For instance, pin 6 has communication purposes (MISO) when the board is being loaded with the program; while driving the fan through the MOSFET when the board is functioning. In the case of pin 7, it works as receiver when the FTDI cable is plugged, and as Socket when the ISP is connected.
    • Screw clamps: since I want to board to be integrated on a reliable prototype, I need some reliable mechanical connectors. 

    Other components that are equally important and should not be forgotten in any board are:
    • Capacitor between VCC and GND: it compensates for the power drops and it has to be of 1µF at least. But some components like servo motors might require the use of bigger capacitors!
    • Resistor (10KΩ) to VCC on RST pin of the microcontroler: it prevents the Reset value from floating.
    • Resonator (20MHz): although I haven't included in this specific design because the fan is not very demanding and I don't need any delay or accurate timing, it is worth mentioning since it gives a more accurate timing as compared to internal microcontroller's  internal clock.


    • 2x3 pin header: for the programing through the ISP. Took me time to understand that pin headers are not for specific functions. they are group of cables (2x2, 2x3, 2x5…) that enable connections. It is the numbers of pins and its physicality that makes them more or less suitable for different application / connections.


    • 6 pin single raw header: for the FTDI connection. Although it could be avoided in simple circuits where there are no sensors to be read, I included it anyway.
      The FTDI cable could be used to program the circuit too, but this would require the installation of a software that "tricks" the USB connection and in line with Emma's opinion, I don't think is very wise to play around with such an important element as the USB connector of your computer.

    The Board

    After having made the Fabduino and a very simple shield last week, as well as the hello.echo board the week before, this was my real first board design. And I must say that the most difficult part by far was arranging the layout of the components, making sure the board is as small as possible and that I don't have to make use of any 0Ω resistor to bridge traces (although is not a sin, it should not be necessary in such a simple board). I constantly keep thinking on Neil's believe that one should be able to design and make a relatively simple board to test something within an hour. Well... not in my case. More like a day. 
    However, doing this exercise, I have noticed a couple of things that, however obvious they might seem, are handy to keep in mind for speeding up future board designs:
    • Handy to send VCC and GND around, so all different components have easy access to them. Sometimes the airwires are confusing, asking you to connect all this spots that are far away in the board, when the only thing you need to do is to connect those to GND or VCC.
    • Put components with lots of pins in an empty space. Microcontroller in the middle, for instance, and different components to the sides of the pins they are connected to.
    • Connectors towards the edges for easy access.
    • Always as a convention, pin 1 (dot) on the top left.
    • Make the boards a bit less tight, specially if they are not final products, but prototypes. You can save a lot of time if you give yourself space to work comfortably in the board.
    • Be a bit less perfectionist with corners, parallelism and equal distances. At least not until the layout is sketched.
    After spending all this time lay outing the circuit... surprise surprise! 1A regulators are much bigger and there is no way I can fit them in the footprint of the 1mA regulator. The worst part? I only found out after the board was milled and the rest of the components were in place. Lesson learned: always check the components beforehand, to make sure you have them available and to be certain about the required footprint. Below you can see the difference between the 2 board layouts (and sizes).



    It was time to mill another board. But before I had to struggle with finding the right footprint for the aforementioned regulator! How come is not included in any of the FabLab libraries? Or even worst,how can it appear when I call the libraries in the layout screen but not in the schematic!? I realized then that every component in an Eagle library consists of 2 elements: package and symbol, and that for whatever reason some manufacturers only provide one of them, which causes the specific component to only appear in the board layout or schematic screen.

     I consider this a good moment to actually review some of the components that always give me trouble when it comes to choosing the right footprint (I always have to check back to previous assignments!). Here they are:







    As it can be seen, the new board turn out a bit larger than the previous one (but still compact enough to fit into the stand alone prototype). Following you can find the milling files:





    Program the board

    Programming the board was, no reasons to lie, very straightforward. The code (find here) is as simple as writing an analog signal to the pin attached to the transistor, using the PWM values to regulate the speed of the fan between min. (0v) and max. (5v).

    This time, and based on the previous experience with the ATMega, I was very careful to check the microcontroler as soon as it was installed together with the few components it needs to work. I checked the fuses  and burned the boot loader. I did the first using the terminal and typing avrdude -c usbtiny -p t45, being t45 the code for the ATTiny45 microcontroller. Typing avrdude -c usbtiny the list of possible parts appear. Quite handy.


    This time the experience was just the oposite: no hustle whatsoever. I plugged, and it worked. Period. I even checked whether the board would get too hot after a while, but it didn't seem to be the case.



    Note from the future! Looking closely at how to drive a motor I found out that there are quite some components that are necessary to not burn the N-MOSFET (and eventually the microcontroller) that I didn't include in this design. It looked to easy right? that fan connected directly to the MOSFET. Find out which components were necessary and why here.

    Workfiles




    Publicado por
    0

    Añadir un comentario


  5. Fourth electronics-related lesson of the FabAcademy. The intention for this assignment is to get used to designing and making boards in an agile way, while introducing some learning about getting input from a chosen sensor.

     For the assignment I have decided to try a piezoelectric disc as an input device, a very simple sensor able to measure vibration from the environment, by transforming changes in pressure into electric charge. I am hoping to be able to prototype some magic interactions with wood, such a knocking, and being able to sense this knocking is crucial to be able to do something with it.

     FabKit v0.4 (also called Fabduino)
    Since I will eventually be prototyping different kinds of interactions and the ATTiny processors are fairly restrictive in terms of memory and number of pins, Emma proposed me to make the so called FabKit or FabArduino, a FabLab Arduino design and improved by the Fablab community, which includes an ATMega 328P instead. (More or less) detailed instructions can be found in this link.

    I thought that instead of modifying the given layout to include all the elements needed to read from a piezo, it would be intelligent to have the standard FabDuino made, so I can quickly design and make shields myself that I can attach to it and will allow me to use different kinds of sensors without the need of a breadboard. I knew it wasn't the fastest option, but probably the most intelligent thinking about the future of my current Final Master Project. 

     These are the schematic, final layout and milling files for the Modela:




    What I envisioned to be a fairly simple task (just making the FabDuino that someone else had designed and offered as open source) turned out to be tricky and time consuming due to different aspects. 
    • First of all, I had to do some adjustments in the given board layout, since the given design included very close traces (the ATMega has very small legs!), not suitable to be milled out with the end mills available at the FabLab (1/64 inch.). Using the given png files, I rendered the path using the Fab Modules (software developed by Neil Gershenfeld for the machines used in the FabLab) to be able to see from the simulation where the paths were too close. Based on that I had to make some magic to give enough space between the traces, but I managed. The fact that the Modela Rules gives so many errors still when checking the final layout, that has actually been successfully milled (almost), makes me think that this Design Rules Check is only partially trustworthy and should only be used as a reference,

    • I did find a couple of interrupted traces in places where the 1/64 inch. endmil could not enter, but they where easy to solve with the scalpel. The above attached milling file is exported after I fixed this two errors on the eagle file.

    • I also substituted the pins for the FTDI cable (SMD) for some through hole single row pins, which I can stick in and bend over the board, something that I like better than the surface mounted version.

    • I struggled for a while with an airwire in the Eagle file provided that turned out not to be a problem even if it remained unconnected. Somehow a redundant connection next to the switch (see pictures below).

    • Soldering the microcontroller wasn't easy this time, because the ATMega has truly small legs. The way it worked best for me was to apply one dot of tin, approach the microcontroller while heating up this leg, and once partially fixed, then adjust the position until all the legs are well aligned. Another option could have been to put a bit of tin in every trace / leg, and approach the component as you heat up with the hot gun.
      For the rest of the legs, simply put a drop of tin on the tip of the iron and gently approach until the drop touches the leg and sticks to both the trace and the leg (in the best case scenario).




    The final result was pretty neat, although the position of the switch makes it not very "shield" friendly. I opted for installing female headers like the ones that can be found on the Arduino UNO, so both standard cables and other shields that I might design can safely fit.




    1Knock shield


    I started with a 1 piezo shield, but the intention in the future would be to make a shield that can host a few piezo so I can sense the direction from which the vibration is coming. I'll see. As for now the design of the shield was very simple, basically including only a safety resistor between GND and the input; and a screw clamp (I don't like to be fearing that the eventual prototype won't work because the cable connection is week).




     Programming the board
    The new Arduino IDE (10.6) has brought significant difference when it comes to adding a custom board to the collection of boards available under Tools > Boards. Whereas before it was as easy as creating a text file called boards.txt within the Hardware folder as explained in the tutorial (Documents > Arduino > Hardware > "Your board" > boards.txt), for Arduino 1.5 and beyond the architecture is different and at least 3 different files are needed: boards.txt, platform.txt and programmers.txt (see this other tutorial).

    Being this option too complex for me, I opted for installing an old version of the Arduino IDE (1.0) and having the board "installed" as explained earlier. Another option was to select Arduino Nano in the board menu, since it uses the same microcontroller (ATMega 328).

    Now, the biggest problem (still unsolved) came when trying to burn the bootloader. I tried all three different options stated before hand but I kept having the same error. 

    Initialization failed, rc=-1
    Double check connections and try again, or use -F to override this check.

    A typical error message that pops up when there is a communication problem between the ISP and the board, mostly due to the fact that there is a short, some cable is in the wrong position or, as it was the case with me, the microcontroller does not respond.

    After more than an hour troubleshooting with Emma, we came to the conclusion that the ATMega was broken, and although it was a big endeavor, I managed to removed and solder up to 2 new ones without removing any of the other components. I even broke a trace and had to improvise a solution with a piece of wire (see pictures below), and had a lot of troubles with not soldering pairs of legs together, which I did many times and had to fix with both the tin pump and the copper wire.




    However, the solution didn't work and although the chip responded this time to the call in the terminal (see picture below), the bootloader appeared to be impossible to burn, which moreover cause the ruin of the 3rd microcontroller. 


    Note from the future: as it turned out, the only problem was... that I forgot to press the reset button when burning the bootloader! Such a silly mistake when it seems to be a common instruction appearing in every tutorial. I also substituted the 20MhZ regulator with a 16MhZ regulator to make sure everything was as similar to the Arduino UNO as possible (although at this point I don't know if it would have worked using the 20MhZ resonator and pressing the button).

    CONCLUSIONS: always try to check the board and program it before you solder all the components. The only pins you need are the important 6: VCC, GND, SCK, RST, MISO AND MOSI (some of the are connected to more than one pin). At least, after all the hustle, I have learned really well how to search for troubles!

    Alternative solution

    Since the most challenging part for me is actually the code, I decided to try to work it out anyway by wiring the piezo to an Arduino UNO as seen in the following picture.


    The code is simple (you can find it here). It reads the input from the sensor and turns it into volts to be shown on the serial monitor, sending a "Knock" message if the measured voltage raises over an programmed threshold. Some of the new elements I have use are:
    • AnalogRead: reads the value form a pin that allows analog input (ADC Analog to Digital Converter). When using Arduino UNO, this pins don't need to be defined as INPUTS, since they are so by default, not being able to do anything else.
    • Float: a data type for floating-point numbers, used to approximate analog and continuous values because they have greater resolution than integers.
    • Float(): converts a value to the float data type.




    Workfiles




    Publicado por
    0

    Añadir un comentario


  6. Third electronics-related lesson of the FabAcademy. This time big step: learning code. The goal? programming the board I have made previous week, including a switch and a LED, to do something.
    Understanding the communication
    Very important at this point is to understand the connections we are establishing between the board and the computer. They are:
    • AVRISP connection: it powers the board and allows the computer to talk to it. It is through here that the code is loaded into the ATTiny.
    • FTDI connection: it powers the board and allows it to talk to the computer. It is through here that the board communicates back with the computer and with us through the serial monitor.

      Always install an FTDI header, if only to be able to calibrate the board or to debug if necessary. Then the header can be removed in space is needed.

      The second image represents the schematic for the FTDI cable, which has defined the order of the pins in the schematic as seen in image 1.



    Note: important not to plug both cables at the same time. Instead, plug and unplug ISP and FTDI cable from the same USB port for an agile programing and serial communication with the board.



    Setting up the communication

    In order to set up the board to communicate to the computer and work with the Arduino IDE, the next steps were necessary:
    • Install ATTiny in Arduino environment as explained in this tutorial, so you can program ATTiny microcontrollers using the Arduino IDE.
    • Install the Crosspack for AVR Development (see explanation here) with the help of this tutorial. This is the necessary platform for programing AVR microcontrollers.
    • Install the VCP and D2XX Direct drivers for FTDI-USB using this tutorial (when done successfully something like "/dev/cu.usbserial-XXXXXXXX" should appear in the Arduino IDE under Tools > Port).
      • VCP drivers can be found here. As easy to install as opening the package and following the steps.
      • D2XX Direct drivers can be found here. As indicated in the cell specific for my OS X, you do not only have to install the drivers themselves, but also D2XXHelper to prevent weird errors from happening with newer versions of OS X. The D2XX drivers are trickier to install than the VCP, so download the .dmg and follow the instructions in the Readme.txt file. Be careful! since the steps for the terminal commands only work if you have copied the folders contained inside the .dmg and pasted them on your desktop. Also, the commands for the terminal don't all really match the directories of the files inside these folders, so adjust them (specifically the libftd2xx.1.2.2.dylib, that can be version 10.4 or 10.5-10.7 for newer versions). Apparently Emma recommends installing the 10.4 version.
        You could do all this copy paste by hand, for which you would need to access /usr/local/lib and /usr/local/include (both hidden from the Finder) through Go > Go to folder  (Cmd+shift+G) in the Finder . I used the terminal commands to do the operations, but checked afterwards that the files were indeed pasted in the new location since the Terminal doesn't give any feedback about the commands being successful. Ufff...

    • Make the AVR ISP cable for the communication between the ISP and the echo.hello-wold, making sure that wire 1 (white wire in my case) was aligned to the mark in both the headers.
    • Find the right orientation of the communication PINS in both the ISP and the board (marking them with a dot), so one makes sure that every Pin is connected to its relative on the other board.
    • Connect the ISP to the USB and the Echo.Hello_world board and burn the bootloader: Tools > Burn Bootloader. Make sure you have selected ATtiny as “Board”, ATtiny44 as “Processor”, 20MHz (external) as “Clock” and USBtinyISP as “Programmer”.
    Everything should now ready to program the board from the Arduino environment.
    Coding

    First thing I tried is to upload the "blink" sketch from the Arduino examples to see if the board actually worked. For that, and given the fact that I am not using an Arduino UNO board, the first step was to redefine the pin that is connected to the LED. The following picture is an essential one for that purpose, and it is not included in the data sheet of the microcontroller. It establishes the relation between the pins in the schematic and the actual pins to be used in the code.


    Having defined pin 7 as my the pin for the LED in the code (6 in schematic), I uploaded the sketch and the LED blinked with a second of delay. Yay! I tried modifying the delay to see if that also worked, and it did. I was ready now for including the tact switch into the equation and making both do something.

    I had already worked with Arduino before and therefore I was somehow familiar with the structure and some of the functions, variables, libraries and so on. However, I decided to take the beginners approach and started from scratch by reading the book Getting Started with Arduino, written by one of the Arduino founders, Massimo Banzi.

    As I advanced in the book I was going through different small incremental exercises used to explain different elements in the code every time (always including a LED and a tact switch). I wrote and coded everyone of them, and following you can find the exercises in the order that were done, a video demonstrating the interaction and the related code.
    • Exercise 1: the LED turns on when the tact switch is pressed and it turns off when the pressure is released (video 1). The code, that can be found here, is pretty basic and includes only one variable for the digital input of the button and an if statement for the behavior of the LED. The functions digitalRead, digitalWrite and pinMode are introduced in this exercise. Video 2 shows the total opposite (LED is always on and turns off only when the tact switch is pressed) because, in my case, LOW as an input value means that the button is pressed. This happened because  of the way the tact switch is connected to the microcontroler, reading the pin 0v (LOW) when the button is pressed.










    • Exercise 2: the LED turns ON and OFF alternatively every time the tact switch is pressed, remaining in its ON and OFF state when pressure is released. In this exercise, the code (find here) deals with difficult aspects like refreshing the value of the digital input variable to avoid multiple reads when the button is pressed, and performing a different action depending on the state of the LED (turn ON if it is OFF, turn OFF if it is ON). In this exercise, the function delay() as well as the boolean operator && are introduced.




    • Exercise 3: let the LED fade in and out. The objective was to understand the concept of PWM (Pulse With Modulation) in the simplest possible way. In the code (find here) the function analogWrite is introduced.



    • Exercise 4 - Final exercise: a combination of both exercise 2 and 3, the intention was to have the LED switched ON and OFF when the button is pressed once, and increase its brightness over time if the button is pressed for more than half a second. In the code (find here), the function millis() is introduced.

    Serial Communication

     In addition to the previous sketch, I though it would be nice to try at least to establish a serial communication between the board and the computer.
    • Exercise 5: I started with a very simple code in which I eliminated all the fuss with the LED and the switch in order to stick to the serial communication. I basically made the board to say "Hola!" (hello in spanish) to the serial monitor every second. Find code here.


    • Exercise 6: for the second trial, I integrated the communication into the sketch for Exercise 4, making the board write "LED on", "LED off" or "Dimming" depending on the state. Code can be found here.
     




     Workfiles



    Publicado por
    0

    Añadir un comentario


  7. Second electronics-related lesson of the FabAcademy. This time focused on learning PCB design with an E.D.A software, in this case Eagle. For this second lesson, the goal is to redraw the echo hello-world board, adding at least a button and LED with its current-limiting resistor, and make it at the FabLab.

    Redesigning the Board


    I started by watching some Eagle tutorials online: I found this and this specially complete, as well as this, full of small videos. For the actual board I went through the "official" tutorial, more tuned to the week's assignment.

    Before that I had a fantastic review of basic electronics with Emma, hopefully the last one I will need to go through after all the Arduino crash courses I have done before. Very good to refresh all this concepts again, complemented withe the book Getting Started with Electronics, a classic from the 80's available online here.

    As for the electronics design workflow in Eagle, I found it quite easy to grasp. Summarized:

    1. Create new project: File > New > Project (directory can be changed under Options > Directories).

    2. Create new schematic: File > New > Schematic.

    3. Use libraries of components. They can be found online, often from suppliers like SparkFun or Adafruit, so they not only make sure you have the correct footprint for their products but they also make it as easy as possible for you to purchase their product. In this case we will be using 1206 components (0.126 inches × 0.063 inches) from ng.lbr, fab.lbr and FAB_Hello.lbr. respectively.
    In order to install the libraries, just paste them in the folder Applications > EAGLE > lbr. Once there, go to Eagle's toolbar Library > Use > Select them all > Open. Libraries are now ready to be accessed and its content available.

     4. Add components: drop all the components you need before start arranging. Components can be copied and pasted. Using the integrated search engine can speed up a lot the process unless you know exactly in which library the components are. For this specific exercise the required components (BOM) are:
    • Included in the original design:
      • Pin Header 2X3: powers the board and let the computer talk (program) it.
      • Microcontroller: ATTINY44A. Once the microcontroller is installed, the program stored is non-volatile memory, so it will be remembered.
      • FTDI header: powers the board and allows it to talk back to the computer.
      • Resonator (20MHz): external clock. The ATTINY has an internal 8MHz resonator but this one is faster (increase the clock speed of the processor) and more accurate. It has no orientation!
        For the board to work, the resonator is not necessary. However, it is necessary for a proper communication and debugging.         If the only thing one needs to do is calibrate the sensor, using the internal 8Mhz clock and the Zaerc's script is enough to have proper serial communication for the purpose.
      • Capacitor (1µF): filters and stores power. Although in the schematic looks like polarized, the SMD capacitors that we are using have no orientation. Every board with a microcontroller includes this component.
      • Resistor 3 (10KΩ): helps hold or pull down current of the reset pin of the microcontroller. Every board with a microcontroller includes this component.
    • Added to the design:
      • Resistor 2 (10KΩ): pull up resistor. Here you can find everything you need to know what a pull-up resistor is and how to calculate the necessary resistance value.
      • Resistor 1 (499Ω): typical current limiting resistor that prevents the LED from burning. You can calculate the necessary value for this resistor with this simple LED calculator.
      • Button (OMERON Switch): to do something with it eventually.
      • LED: to be controlled with the switch. The Cathode was supposed to be indicated with a double line, but I could not see it so I needed to check the orientation with the multimeter.

    5. Rename and add values to components. Necessary to be able to see what is what and not make mistakes in the arrangement of things. Parts can be renumbered and renamed after in a more logical way based on their location thanks to scripts. File > Run ULP... > rename/renumber.ulp.

     6. Position and make rough connections using nets.

     7. Clean schematics (reposition, align, make junctions with dots...). By giving the nets the same names virtual connections can be made, avoiding the need of a very messy schematic full of lines. Eagle will ask if you want them to be connect them. Label them after so the name is visible in the schematic.

    Dear me (note from the future): when dealing with Tx and Rx, it is better to make the connections visible in the schematics rather than tagging the net. As it turns out, Tx (transmitter) from the FTDI cable (find picture bellow) goes to receiver (Rx) of the board, and vice versa; which means that the schematic above, although perfect in design terms, is confusing in the naming. It gives to pin 12 the name Rx when actually, from the perspective of the micro controller (the important one for the code afterwards), pin 12 is actually a transmitter (Tx). A better version of the schematic would be instead the following, where pin 12 is Tx (connected to Rx) and pin 13 is Rx (connected to Tx). Unfortunately it is not possible to assign different names to the pins that are physically connected.



    8. Verify using ERC (Electrical Rules Check) before you move on to the PCB layout: Tools > ERC. This will help corroborate that there are no lost connections. I had a few warnings (different than errors) related to the isolation of the CTS and RTS pins in the FTDI header, but they are not used in this case so this situation is normal. There was also a warning related to the lack of value of part S1, which is a button and thus has no value itself. Just approve them and move on.



    9. Make and adjust board layout: switch to board layout mode and move and rotate (right click) components inside the grey rectangle (board maximum dimensions). The yellow lines represent the connections defined in the schematic and they are referred to as airwaves. Every time you successfully route a connection the airwire disappears. I strongly recommend using the command Ratsnest as you go on with the rearrangement to recalculate the connections and clean up the airwaves.


    10. Route the traces: you can try the Autoroute command and change what you don't like or go directly for the manual routing using the command Route. On the menu above you can choose the kind of bend, radius and width of the trace. THIS IS VERY IMPORTANT! 

    • Firstly because the size of the traces will define the current that can flow through it (not so important for simple circuits like this). 
    • Secondly, because if they are very thick and the clearance (space among them) is very small, the end mill won't be able to go there and the traces will remain connected, generating a short in our circuit. 
    • Thirdly, because it is important to avoid straight angles in you board design. The electrons have more problems to travel through sharp edges, especially if the traces are thin.

    The way to avoid it is by eye, setting a grid of 0.4 mm (ø of the end mill) to be able to see if the space between traces is enough; and by verifying the design rules (see point 12).

    Note: if there is no way to arrange the traces so they don't cross and we don't want to make a 2 sides board, we can hop over traces by making use of 0Ω resistors.

    11. Clean and finish design: place holes for screws, adjust size and corners of PCB outline (radius can be made with the command Miter), and add text. Although text can be easily added in Photoshop when editing the png for fabmodules, text can be also added in Eagle, ideally using the typeface Vector that is rounder (friendlier to mill) and can be scaled by percentage.

    If you are going to to outsource the production of the PCB you can also arrange the location of the names and values to make sure the silkscreen print is nice and clean. For it you first have to detach the name from the component with the command Smash.


    12. Verify using DRC (Design Rules Check): this allows you to check the "manufacturability" of the board based on a set of rules you want the layout to respect. In every case will be different (depending on the manufacturer) but the settings the check up is based on can be changed. Tools > DRC. In our case, we want to check the design rules based on the Modela, and adjusting the settings is as easy as loading the MODELA_CORRECT.dru file and running the check with these design rules. However I loaded a different one that seemed not to be well adjusted (fab.dru) and therefore... (scroll down to see the mistake).

    13. Run a GND plane (optional): this helps you preview (and therefore make decisions beforehand about) the amount  of copper that will be removed from the board, although this can be adjusted in the Fabmodule for the Modela through the setting offsets. In my case I did the last.

    If you still want to do it, create a Polygon (make sure your are in the right layer, Top or Bottom) slightly bigger than the outline of the board, name it GND and run Ratsnest (remember that you have to redo this last bit every time you reopen the board layout). Make sure you Keep Orphans and Thermals on, as well as the Width, Spacing and Isolation are the adequate for the Modela to be able to reproduce it.


    14. Renumber components (in case you want the labeling to be based on the actual layout distribution instead of the schematics): you can File > Run ULP again. 

     15. Export the traces layout to be milled with the Modela: make sure all the important layers are on (Top, Bottom, Pads and Vias for the traces. Dimensions, Pads, Drills and Holes for the layout). File > Export > Image > PNG > Monochrome > 1000 dpi (the higher the resolution the finer the job can be).
    Very important!: in order to make sure that the outline shows up in our png when we export, we have to "extend the canvas" by making a bigger square around the board layout and keeping it hidden in layer 51 tDocu p.e. This way we make sure the program "broadens" its view and the outline is included in the export.
    Remember: the Modela cuts out black and leaves white.



    16. Generate BOM (optional): using the command run bom.ulp.

     17. Edit board files: clean unwanted copper with the Paint Bucket Tool, add text, and specially invert the color of the inner part of the cutout file. Holes will be made just by leaving them black. Make sure you didn't change the size by toggling between the preview of both the images of the traces and the layout to see if they differ.


    Milling and stuffing the board

    I proceed to run the milling job following the instructions I have collected in the previous exercise.
    The process went well and the result seemed excellent at first sight, so I went on for the stuffing. However, I didn't check for shortcuts with the multimeter (BIG MISTAKE) and only when all the components were soldered I found the shorts (well, Emma found them). I had also soldered a FTDI header that was too short for the FTDI - USB cable, so I had to substitute it for one with bigger pins.



    Always check with the multimeter (at least) that:
    • There is no short between VCC and GND.
    • There is no short between the different pins of the headers (try all possible combinations!).
    Mistake

    What happened is that, as it looks like, I checked the design rules with the wrong settings (loaded fab.dru) instead of MODELA_CORRECT.dru and so the little clearances didn't show as an error (clearance was set at 0.3 mm when the end mill is 0.4mm). The Modella didn't cut there and the traces that weren't supposed to be connected were, in fact, connected. 

    I had to remove the micro controller, cut the traces with a cutter (hein!?), check with the multimeter wether or not they were still connected and solder the micro controller again. But before I had to flatten the tin that remained in the footprint of the micro controller using a bit of the copper braid.


    I checked again with the proper design rules and indeed all the errors were there, ready to be found before I milled the board. Well, I corrected the layout by leaving more clearance and checked again (for next time).


    Workfiles

    Publicado por
    0

    Añadir un comentario




  8. First electronics-related lesson of the FabAcademy 2015 program that I will start doing with a delay of almost 6 months with respect to the official FabAcademy of the year. Never too late! This first lesson, consisting in the production of an In-System Programer (ISP) with a Roland Modela milling machine and surface-mount components, was done as part of the Fab Academy Light program, given by Emma Pareschi at FabLab Amsterdam. 
    First of all. What is an In-System Programer?

    An In-System Programer is a device that allows you to program logic devices, micro controllers and other embedded devices externally, rather than requiring the board to be programmed beforehand. The bridge between the computer and your board.

    There are commercial ISP's and even different models built within the FabLab community. The model chosen for the exercise is the FabTiny ISP designed and optimized by Zaerc, which I have heard will become the standard ISP for the upcoming edition of the Fab Academy.

    Why a surface-mount device?

    Surface-mount technology is the FabLabs' choice for producing electronic circuits. SMT is neat and much more reliable than breadboards or through-hole PCB's, as well as safer and cleaner than the itching process (electronic circuits can also be printed with conductive ink, sewn with conductive thread using an embroidery machine or cut from copper foil using a vinyl cutter, among others).

    Milling the board

    The milling of the plate on top of which the components will be mounted is made with a Roland Modela, a small and very precise milling machine. The starting point is a FR1 plate, consisting of a thin layer of copper sandwiched with a sort of cardboard (other models with glass fiber instead are less safe). Using the compiled version of the FabModules, the only thing one need is a PNG picture with the black and white traces to be milled.

    I started with a leftover plate that was already installed in the Modela. The available space in it was enough for the size of the ISP, but I had to flip the image since the space available was vertical rather than horizontal. I loaded the file with the traces, and milled them. So far so good. But here is where I made my first beginners mistake: I confused the end mills and installed an extra big one with the settings of a smaller one for the outline cut, which resulted in the following: a totally ruined board with really burry edges.

    It was time to start again, and this time, I need to do it from scratch. Here is where I made my second beginners mistake: I did not only remove the plate that had been milled, but also the sacrificial layer that lays in between the board and the bed. Now I had a lot more work to do: cleaning the bed and the sacrificial layer (using a scraper and sticker remover), placing them all together with the new plate (using double sided tape) and milling the board again.





    Using another piece of leftover plate and the given PNG, I run the work using the 1/64" end mill for the traces and the 1/32" for the outline. The default settings of the machine were used, except for the Offset, that was set to -1 to assure the complete removal of the black parts of the drawing (in this case, given the simplicity of the board, this detail didn't have a significant effect on the increase of machine time).








    Well I actually made another mistake  When I noticed that I couldn't remove the board from the plate I realized that due to my emphasis on bringing the head of the milling machine as close as possible to the board, the system almost touched its limit point, making it impossible to go deeper than the 0 point I had set. Fortunately I just had to redo the z-callibration, stick out the end mill a little more this time and run the job again.


    Once the board is milled and detached from the plate, it is important to wash it with water in order to remove the fat from the hands, which causes corrosion on the long term.

    Another good practice is to check wether or not there is a short in the board (trails are connected when they should not be) making use of the multimeter in sound mode, checking systematically all the possible combinations and making sure no unwanted current transfer.

    Don't forget to clean the milling machine with the hoover and place the things back.

    Stuffing the board

    Stuffing the ISP board seemed like a nice yet challenging activity with a good  amount of craftsmanship involved, and indeed it was. Given the small size of the components I opted for keeping them together on a piece on paper with double sided tape, in the order specified by the bill of materials (BOM) to avoid confusion among the quite similar components.



    The option I chose for keeping the board fixed while working on it was using the double sided tape. Making it a little dirty with your hands you make sure that detaching it to move it around is not so difficult, while keeping it stuck to the table just enough. The other option was to hold it using the circuit board holder, using a piece of paper to avoid scratching the surface.



    It is wise to lay all the components on top of the board before starting the soldering, so as to asses what is the most clever way of mounting them. In this case I have an example of a finished ISP next to me, so I could see which parts have difficult access at the end and started by soldering them. As a rule of thumb, it is wise to start the soldering process with the components placed in the middle of the board, and go on towards the edges.


    In general the soldering process went well and I managed to make quite nice and clean connections. Except for one in which I bridge two trails. The perfect opportunity to use the PCB pump, an utensil that helps your remove a wrong soldering point by creating vacuum for a fraction of a second right when the tin is melted.


    Needless to say, I burnt myself with the iron a couple of times. The experience would not have been complete otherwise!

    The last step was to check with the multimeter again wether there was a shortcut or the board had been milled properly. Unfortunately there was one, between VCC and GND, fixed a few weeks later by desoldering and soldering again a few of the components. But when trying to check wether or not the microcontroller was "alive" using the command avrdud -c usbtiny -p t45 in the Terminal, this didn't respond. Replacing it fixed the problem, and so I went on with programing the ISP.



    Programing the ISP

    Following Zaerc's tutorial is at least... challenging. It focuses on the programing with an Arduino UNO and it is not easy to "decode" (hehe) how to do it with another ISP. So I use instead Loes' pdf instructions, in which she explains really well the steps that can be skipped from Zaerc's tutorial. As Loes does, I keep the "vusbtiny" folder locally in my computer, so the final directory to be introduced in the Terminal (preceded by the command cd - change directory-) looks like:

    cd /Users/Ismael/Documents/ID/Electronics\ \&\ Arduino/FabAcademy\ 2015/Week\ 1\ Electronics\ Production/vusbtiny.

    The last step (the only that cannot be undone) is meant to "seal" or "lock" the ISP so it can only be used as that... an ISP. It is not mandatory, but recommended.

    Important note: when copying the commands from Loes' instructions to paste in the Terminal, make sure they are in one single line and not in two as they appear in the pdf (write it yourself or adjust it in a text editor before pasting it to the terminal).

    And voilà! Done!


    1M€ question: What is the slide switch for?

    Actually the purpose of the slide switch on the ISP is to switch ON and OFF the power source from USB , so one doesn't have to plug and unplug the ISP every time when toggling between ISP and FTDI. Useful!



    Publicado por
    0

    Añadir un comentario

  9. The last exercise of the semester regarding the integration of technology was the development of the Serendipity Camera, one of the main elements of The Secret Garden Toolkit. Called this way because of the intentional randomness I wanted to give to the pictures, the camera is composed of a Arduino Uno, an SD shield from Snootlab and a TTL serial JPG camera from Adafruit. Designed to be used in security systems, the camera streams video but it can also take snapshots of that video in color and transmit them over the TTL serial link to the SD card, which is actually what it is programed to do in the present example. The maximum resolution of the pictures is 640x480, which is quite low, and the accuracy of the color rather poor. However, it was the most suitable and affordable small camera I could find in order to construct the system myself, which was the real objective.

    It takes a picture every 30 seconds, helping children to randomly document their explorations. The intention was to offer them also a shutter button so they could take voluntary pictures (as explained in the flow chart). Nevertheless, when I built the camera and found out that it took up to 15 seconds to save a single picture, I decided to skip this option and stick to the automatic ones. Clearly something to look at in an eventual second version of the design.

    In between the camera and the boards a small resistor divider was installed (as seen in the circuit layout) to turn the 5v output on pin 3 into 2,5v and make sure that the camera input never goes above the 3,3v that supports. The resistors were soldered in is a small space for prototyping available in the SD shield.

    As for the code, it is made to have the camera first take a snapshot test, giving you information through the serial port about wether or not the camera has been found, the size of the picture that is going to be taken and the absence of the SD card (in case you have forgotten to put it in). After that and having defined a subroutine (a sequence of program instructions, packaged as a unit, that take the actual snapshot) it enters in a loop of 1 picture every 30 seconds by calculating the elapsed time since the last show. Pictures are saved in the memory card with names created by a piece of code that works as an incremental filename generator.



    The TTL camera

    The SD shield





    Flow chart representing the original intentions for the camera

    Layout of the current circuit

    Code with self explanations:

    #include <Adafruit_VC0706.h>
    #include <SD.h>
    #include <SoftwareSerial.h>         
        
    #define chipSelect 10

    // Using SoftwareSerial (Arduino 1.0+) or NewSoftSerial (Arduino 0023 & prior):
    #if ARDUINO >= 100
    // On Uno: camera TX connected to pin 2, camera RX to pin 3:
    SoftwareSerial cameraconnection = SoftwareSerial(2, 3);
    #else
    NewSoftSerial cameraconnection = NewSoftSerial(2, 3);
    #endif

    Adafruit_VC0706 cam = Adafruit_VC0706(&cameraconnection);

    unsigned long timeLastShot; //extended size variables for number storage, so it can store the number of miliseconds that passed since it took last picture

    void setup() {

      Serial.begin(9600);
      Serial.println("VC0706 Camera snapshot test");
      
      // See if the card is present and can be initialized:
      if (!SD.begin(chipSelect)) {
        Serial.println("Card failed, or not present");
        // don't do anything more:
        return;
      }  
      
      // Try to locate the camera
      if (cam.begin()) {
        Serial.println("Camera Found:");
      } else {
        Serial.println("No camera found?");
        return;
      }
      // Print out the camera version information
      char *reply = cam.getVersion();
      if (reply == 0) {
        Serial.print("Failed to get version");
      } else {
        Serial.println("-----------------");
        Serial.print(reply);
        Serial.println("-----------------");
      }

      // Set the picture size - you can choose one of 640x480, 320x240 or 160x120 
      // Remember that bigger pictures take longer to transmit!
      
      cam.setImageSize(VC0706_640x480);        // biggest
      //cam.setImageSize(VC0706_320x240);        // medium
      //cam.setImageSize(VC0706_160x120);          // small

      // read the size back from the camera
      uint8_t imgsize = cam.getImageSize();
      Serial.print("Image size: ");
      if (imgsize == VC0706_640x480) Serial.println("640x480");
      if (imgsize == VC0706_320x240) Serial.println("320x240");
      if (imgsize == VC0706_160x120) Serial.println("160x120");
      
       take_save_photo(); //take photo for the first time.
      
    }

    void loop() {
      
      if(millis()- timeLastShot > 30000 ){ // if 30 seconds passed since last shot...
      
        take_save_photo(); //take interval photo.
      
      }
      
    }

    void take_save_photo() { //subfunction
      
      timeLastShot = millis(); // remember when it took photo last time
      
      // Try to locate the camera
      if (cam.begin()) {
        Serial.println("Camera Found:");
      } else {
        Serial.println("No camera found?");
        return;
      }
      
      // Set the picture size
      cam.setImageSize(VC0706_640x480);        // biggest
      //cam.setImageSize(VC0706_320x240);        // medium
      //cam.setImageSize(VC0706_160x120);          // small
      
      Serial.println("Snap in 3 secs...");
      delay(3000);

      if (! cam.takePicture()) 
        Serial.println("Failed to snap!");
      else 
        Serial.println("Picture taken!");
      
      char filename[13];
      strcpy(filename, "IMAGE00.JPG");
      for (int i = 0; i < 100; i++) {
        filename[5] = '0' + i/10;
        filename[6] = '0' + i%10;
        //filename[7] = '0' + i%100;
        //filename[8] = '0' + i%1000;
        // create if does not exist, do not open existing, write, sync after write
        if (! SD.exists(filename)) {
          break;
        }
      }
      
      // Open the file for writing
      File imgFile = SD.open(filename, FILE_WRITE);

      // Get the size of the image (frame) taken  
      uint16_t jpglen = cam.frameLength();
      Serial.print("Storing ");
      Serial.print(jpglen, DEC);
      Serial.print(" byte image.");

      int32_t time = millis();
      pinMode(8, OUTPUT); //snootlab SD shield: pin 8
      // Read all the data up to number of bytes!
      byte wCount = 0; // For counting number of writes
      while (jpglen > 0) {
        // read 32 bytes at a time;
        uint8_t *buffer;
        uint8_t bytesToRead = min(32, jpglen); // change 32 to 64 for a speedup but may not work with all setups! -----> it didn't really work
        buffer = cam.readPicture(bytesToRead);
        imgFile.write(buffer, bytesToRead);
        if(++wCount >= 64) { // Every 2K, give a little feedback so it doesn't appear locked up -------> incremental ellipsis (puntos suspensivos)
          Serial.print('.');
          wCount = 0;
        }
        //Serial.print("Read ");  Serial.print(bytesToRead, DEC); Serial.println(" bytes");
        jpglen -= bytesToRead;
      }
      imgFile.close();

      time = millis() - time;
      Serial.println("done!");
      Serial.print(time); Serial.println(" ms elapsed"); //time it took to save the picture
    }





    Publicado por
    0

    Añadir un comentario

  10. Being decided to do as many activities related with electronics as I could on my now, I joined a DIY synthesizer workshop during DDW. As it is obvious, the purpose of the workshop was to build an analog synthesizer and learn, on the way, abut the function and use of simple electronics devices such as the squaresynth - a dual step oscillator analog synthesizer kit from Lifepatch.

    In my case, I made a synthesizer that I could control, and therefore make noises with, by using a simple variable resistor. After that, the intention was to substitute the potentiometer with other kinds of sensors and play around with them. Unfortunately, by the time the workshop was over I could not have my synthesizer making anything but a very subtle and almost unappreciable sound. Up to this day, I still could not find where the problem is.

    However, considering the fact that it was early in the semester (before most of the previous posts) it was a good activity to understand the functioning of some basic electronic components and to measure my level of understanding about what was being said.








    Publicado por
    0

    Añadir un comentario

Cargando