Integrating Technology: diciembre 2015

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

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

Integrating Technology

Post 13: Fab Academy lesson #6 (Networking & Communication)

Añadir un comentario

Post 12: Fab Academy lesson #5 (Output Devices)

Añadir un comentario