Skip to content

15. Networking and communications⚓︎

I sense that this week is going to be a complicated one. From the very beginning Adrián has mentioned that it is a week that can get complicated due to the number of factors involved in the networking process, and as Fran said in his series of videos “How to survive FabAcademy” it is the most complicated assignment of the course. In this clip he says: It takes 5 things for communication to take place: Sender, receiver, channel, code and message. If only one fails, communication does not take place. and I think is quite accurate. These are the Assesment Criteria related to Networking and Communications:

  • Group assignment

    • Send a message between two projects.

  • Individual assignment

    • Design, build, and connect wired or wireless node(s) with network or bus addresses.

  • Learning outcomes

    • Demonstrate workflows used in network design.
    • Implement and interpret networking protocols and/or communication protocols.

  • Have you?

    • Linked to the group assignment page.
    • Documented your project.
    • Documented what you have learned from implementing networking and/or communication protocols.
    • Explained the programming process/es you used.
    • Outlined problems and how you fixed them.
    • Included design files (or linked to where they are located if you are using a board you have designed and fabricated earlier) and original code.

Networking simulation⚓︎

In other occasions the path to follow during the week is more defined, but in this case I don’t know where to start. Our instructors have recommended us to replicate an exercise that Pablo has prepared with a tutorial, to simulate the networking process between several Arduinos in Tinkercad. I’ve managed to replicate the tutorial in my personal account and embed the project so the schematic and the code can be checked below.

TinkerCAD⚓︎

When we start the simulation in Tinkercad, we can see how the serial monitor of our teacher board shows the output ababa... that our master cyclically makes and how the student boards interpret that output if it corresponds to them or not to turn on the corresponding led. When we check the serial monitor of the student boards they display in loop which assures us that they are reading the information displayed by the teacher board. I have recorded the process in the video shown below.

Replicating the project has been easy, but the interesting thing has been to understand the process by which the communication between the boards takes place, in order to replicate it in my physical ones. In our case, the communication we are using is called UART (universally asynchronous receiver/transmitter) and is a type of serial communication. In the next few paragraphs I will try to summarise some of the distinctions I have learned about types of communication.

Serial communication⚓︎

Embedded electronics is all about interlinking circuits (processors or other integrated circuits) to create a symbiotic system. In order for those individual circuits to swap their information, they must share a common communication protocol. Hundreds of communication protocols have been defined to achieve this data exchange, and, in general, each can be separated into one of two categories: parallel or serial.

  • Parallel interfaces transfer multiple bits at the same time. They usually require buses of data transmitting across eight, sixteen, or more wires. Data is transferred in huge, crashing waves of 1’s and 0’s.
  • Serial interfaces stream their data, one single bit at a time. These interfaces can operate on as little as one wire, usually never more than four.

Over the years, dozens of serial protocols have been crafted to meet particular needs of embedded systems. USB (universal serial bus), and Ethernet, are a couple of the more well-known computing serial interfaces. Other very common serial interfaces include SPI, I2C, and the serial standard we’re here to talk about today. Each of these serial interfaces can be sorted into one of two groups: synchronous or asynchronous.

Asynchronous serial⚓︎

Asynchronous means that data is transferred without support from an external clock signal. This transmission method is perfect for minimizing the required wires and I/O pins, but it does mean we need to put some extra effort into reliably transferring and receiving data. UART is a form of asynchronous serial communication because data is transmitted as sequential bits. The wiring involved with setting up UART communication is very simple: one line for transmitting data (TX) and one line for receiving data (RX). Hardware connection diagram for UART (left image) and UART data packet (right image) looks like this:

UART is called asynchronous because the communication does not depend on a synchronized clock signal between the two devices attempting to communicate with each other. Because the communication speed is not defined via this steady signal, the “sender” device cannot be certain that the “receiver” obtains the correct data. Therefore, the devices break data into fixed-size chunks to ensure that the data received is the same as the data that was sent. In this link you can find an extended explanation about Arduino communication protocols, asynchronous serial and thus UART, I2C and SPI protocols.

Hello.t412.networking.sergio⚓︎

During the Input Devices and Output Devices weeks I made two boards in which I included a specific connector so that this week I can communicate both, but I have no idea where to start this process. I have thought that, although it is not mandatory to build any board this week, almost as a ritual of each week and to get into the work dynamics, I am going to build a board that will act as a “master” with respect to my other two previous boards.

Design⚓︎

As the main purpose of my board is to act as a master and in principle I only need pins for the networking connector, I’m going to use an ATtiny412 as a microchip. I’m going to add two LEDs, so that each one corresponds to one of my boards, since both have the usual led for debugging. In this case the inputs board has a green one and the outputs board a red one, so in this board I will use both colours to associate the leds when they are communicating. When I turn on the green led on this networking board (master) so will the green led on the inputs board (node 1), and in the same way with the red led in master and the outputs board (node 2).

The design process is detailed in the Electronic Design week and later iterations of other boards, as the one made in the Embedded Programming week with also an ATtiny412, so I won’t go into it here. It is summarized in adding the components to the schematic, generating the labels, transferring it to the board file, routing the connections, exporting the board as png and then editing it in GIMP to obtain a traces file and an outline file. As always, here are some screenshots of the process and the list of components used in the schematic.

COMPONENT LIBRARIE NAME COMPONENT NAME QUANTITY
Microcontroller ATTINY412 ATTINY412-SSF 1
UPDI connector FAB SW_SPDTSWITCH 1
FTDI connector FAB CONN_06_FTDI-SMD-HEADER 1
Networking connector FAB CONN_02x2-PINHEAD-SMD 1
Button FAB SW_SWITCH_TACTILE_6MM6MM_SWITCH 1
Capacitor FAB CAP_UNPOLARIZEDFAB 1
Resistance FAB R1206FAB 3
Led FAB LEDFAB1206 2

Fabrication⚓︎

Once we have the board designed and we have generated in GIMP our traces and outline files we take the those to the Mac which we use to drive the Modela and mill the boards. As always we will use FabModules, a 1/64 milling bit for the traces and 1/32 for the outline. Below I attach some pictures of the process and screenshots with the values used for each file. After milling the board it is important to do a post-processing to remove all the imperfections that may remain and the dirt that may have the tracks, to avoid soldering problems. This process and all the materials used for it are detailed in the Electronics Production week.

With the board ready, it’s time to list the necessary components and take them from the Fab’s electronics inventory and prepare the soldering station. Soldering has become an easy and relaxing process because of the repetition involved. I have had some problems getting the tin to flow on some pads but the result has been good.

Programming⚓︎

To check that everything is working properly and as a debugging element, we start by uploading a basic blink to the board, which will reveal if electrically and software-wise everything is OK. The process of uploading code to the ATtiny412 is detailed in Embedded Programming week. Both leds are blinking so we can move on to the next part.

Networking blinking⚓︎

Debugging⚓︎

Communication only acomplished through the serial monitor but not getting the master to send the orders to the nodes. Finally getting the board to post on the serial but it still does not send to the nodes.

The problem was that I was connecting all TX in one channel and the RX in another, instead of wiring the TX masters with the RX of the nodes and vice versa. During the regional review the suggested me to try this out and it worked. I first tried with just one board and dupont connectors, and as you can see in the photo below GND(black) and VCC(white) are wired in the same way, but RX and TX are swapped.

In the second photo you can see how I connected the master with the nodes through the bus connector and swapped pins.

Final shot⚓︎

//ATtiny412 MASTER (NETWORKING BOARD)

void setup(){
    Serial.begin (115200);
    pinMode(3,OUTPUT);
    pinMode(4,OUTPUT);
}

void loop(){
    Serial.write(1);
    digitalWrite (4,HIGH);
    delay(500);
    digitalWrite (4,LOW);
    Serial.write(2);
    digitalWrite (3,HIGH);
    delay(500);
    digitalWrite (3,LOW);
}

//ATtiny412 NODE 1 (INPUT BOARD)

int nodo=1;

void setup(){
    Serial.begin (115200);
    pinMode(2,OUTPUT);
}

void loop(){
    if (Serial.read() == nodo){
        digitalWrite (2,HIGH);
        delay(450);
        digitalWrite (2,LOW);
    }
    else
        digitalWrite (2,LOW);
}

//ATtiny1614 NODE 2 (OUTPUT BOARD)

int nodo=2;

void setup(){
    Serial.begin (115200);
    pinMode(8,OUTPUT);
}

void loop(){
    if (Serial.read() == nodo){
        digitalWrite (8,HIGH);
        delay(450);
        digitalWrite (8,LOW);
    }
    else
        digitalWrite (8,LOW);
}

The video below is a timelapse of the final upload of code for each board and the hero shot of the master and nodes working in sync.

Group assignment⚓︎

The goal for this week group assignment is to send a message between two projects. I found this sentece unclear in many ways. Could it be by bus communication as we have done through all this assignment? Does it have to be wirelessly? Can I use a comercial board for it? I’ve found this statement in the Assesment page for this assignment.

  • What does “two projects” mean in the group assignment? Answer: You need to send a message between any combination of boards, computers and/or mobile devices. You need to write code that sends or receives the message in question.

This means that the group assignment is covered by the work documented above, as I have sent data from one board to another writting my own code, but for making sure I don’t miss understand the goal, I’m going to use a HC05 bluetooth module to comunicate between a board and my smartphone. This is a feature I want to add to my final project and comes pretty close with the next group assignment, in which we can build our own phone App.

HC05 bluetooth module⚓︎

To establish communication between two different devices we are going to use a HC05 bluetooth module. This group assignment is carried out together with the one at Interface and Application Programming week, in which we have connected with our smartphone using the bluetooth module to send a blink to the board using an application previously programmed in the assignment. In this part, I will show how to configure the module for its operation and connection to the pc or mobile.

I have started trying to use my output board as bridge between the BT module and the serial monitor because I thought the module needed a board to send those commands to it. Since the serial port of our board is already being used to communicate with the serial monitor on the PC, we cannot send data using the same channel at the same time, so it is necessary to use the SoftwareSerial.h library to establish both communications. This is the code written for it:

#include <SoftwareSerial.h>

SoftwareSerial HC05(5,4);  //(RX,TX)

void setup() {
    Serial.begin(9600);
    Serial.println("Listo");
    HC05.begin(38400);
}

void loop() {
    if (HC05.available())   //Reads BT and sends to Arduino;
        Serial.write(HC05.read());

    if (Serial.available())   //Reads Arduino and sends to BT;
        HC05.write(Serial.read());
}

After several attempts I have not been able to make it work, and now I doubt if this double communication can really be achieved through serial software. All the tutorials that I have seen configure the BT module with an Arduino board and this method, but apparently a specific hardware is necessary on the board and on the micro to carry it out, which is obviously the board that I have designed as output devices. does not have. Even so, Edu, an instructor from the FabLab in Barcelona, during the Regional Review on Tuesdays gave me the trick to configure the module. The module can be connected directly to the FTDI cable without the need for a board that acts as an intermediary, since you have the 4 necessary connections in both: VCC, GND, TX y RX.

Configuration⚓︎

To configure the Bluetooth module we will use AT commands using it’s AT Mode 2, also being valid AT Mode 1, with the difference that you will have to change to the speed with which you have configured your Bluetooth module(if it is the first time configured, the default speed is 9600). To enter AT 2 mode, we have to keep pressed the module button and power it. It’s easier if we press the button before powering or turning on the module. After it turns on we can just release the button. If the LED blinks slowly it is because we already were or have succesfully entered in AT Mode 2.

Now we open our Serial Monitor from the Arduino IDE, although any serial monitor can be done. At the bottom we must choose “Both NL & CR” and the speed “38400 baud” (the speed to communicate in AT 2 MODE). Done this We can start sending AT commands to our Bluetooth. The first thing is to check if our bluetooth responds to AT commands:

  • Send: AT
  • Receive: OK

If we receive an OK response then we can continue with the configuration. If not check the connections or the previous steps. Once the module is asnwering we can change some parameters. Here is a list of most of the AT commands:

  • Rename our HC-05 module: By default our bluetooth is called “HC-05”.

    • To know current: AT+NAME?
    • Answer: NAME: HC-05
    • To set it: AT+NAME=<Name> (Ex: AT+NAME=Sergio_BT)
    • Answer: OK

  • BT password: By default it comes with the link code (Pin) “1234”.

    • To know current: AT+PSWD?
    • Answer: PSWD: 1234
    • To set it: AT+PSWD=<Pin> (Ex: AT+PSWD=2560)
    • Answer: OK

  • Communication speed: The default speed is 9600 baud, with Stop bit = 0 (1 stop bit), and without parity.

    • To know current: AT + UART?
    • Answer: UART: 9600,0,0 ((Baud,StopBit,Parity) Baud equals speed communication, the values ​​can be: 4800, 9600, 19200, 38400, 57600, 115200, 23400, 460800, 921600 or 1382400. StopBit is what it sounds, it can be 0 or 1, for 1 bit or 2 stop bits respectively. For common applications we work with 1 bit so this parameter is normally left at 0. Parity is what it sound, it can be 0 (No Parity), 1 (Odd Parity) or 2 (Even Parity). Parity is not used for common applications, so it is recommended to leave this parameter at 0)
    • To set it: AT+UART=<Baud,StopBit,Parity> (Ex: AT+PSWD=9600,0,0)
    • Answer: OK

  • BT module communication role: By default our HC-05 comes as a slave.

    • To know current: AT+ROLE?
    • Answer: ROLE: 0 (0 = Slave; 1 = Master)
    • To set it: AT+ROLE=<Role> (Ex: AT+ROLE=0)
    • Answer: OK

  • Connection mode (only when working as a master): This configuration applies for when the module is working as a master, the module needs to know if it is going to connect with a particular device or with whatever is available.

    • To know current: AT+CMODE?
    • Answer: CMODE: 0 (0 = Connect to a device with the specified address (Another AT command is needed to set this address).; 1 = Connect the module to any available address (random).)
    • To set it: AT+CMODE=<Mode> (Ex: AT+CMODE=1)
    • Answer: OK

  • Specify device address to connect (only when working as a master and connection mode set to 0): To specify the address to which we are going to connect.

    • To know current: AT+BIND?
    • Answer: BIND: E668,46,9277F2
    • To set it: AT+BIND=<Address> ((Ex: AT+BIND=E668,46,9277F2) The address is sent as follows: 1234,56, ABCDEF which is equivalent to the address 12: 34: 56: AB: CD: EF.)
    • Answer: OK

Other useful AT commands:

  • Firmware version:

    • Send: AT+VERSION?
    • Answer: VERSION: 2.0-20100601

  • Address of BT module

    • Send: AT+ADDR?
    • Answer: ADDR: 98d3: 31: 2052e6

  • Reset module: After doing this we exit the AT MODE

    • Send: AT+RESET
    • Answer: OK

  • Set default values: By doing this all module parameters are reset to factory default values. In some versions the speed changes to 38400 baud and in others to 9600.

    • Send: AT+ORGL
    • Answer: OK

Comunication⚓︎

I’ve managed to connect the BT module to the PC and the smartphone, so now I’ll try to send some data to the board using this connection. Below is the code written for the board. Basically it reads the serial port and turns on and off the led depending if it receives a 0 or a 1 value.

char IncomingValue = 0;

void setup() {
    Serial.begin(9600);
    pinMode(8, OUTPUT);
}

void loop() {
    if(Serial.available() > 0) {
        IncomingValue = Serial.read();
        Serial.println(IncomingValue);
        if(IncomingValue == '1')
            digitalWrite(8, HIGH);
        else if(IncomingValue == '0')
            digitalWrite(8, LOW);
    }
}

Data is being sent between the smartphone and the BT module when using the App, but the board doesn’t respond to it. This is probably due to an error in the App code as I explain in the Interface and Application Programming group assignment documentation

Files⚓︎

  • Arduino code for the Master board of the Tinkercad project (.ino): file
  • Arduino code for the Node 1 board of the Tinkercad project (.ino): file
  • Arduino code for the Node 2 board of the Tinkercad project (.ino): file
  • Traces of the hello.t412.networking (.png): file
  • Exterior of the hello.t412.networking (.png): file
  • Schematic design in Eagle of the hello.t412.networking board (.sch): file
  • Board design in Eagle of the hello.t412.networking board (.brd): file
  • Arduino code for the Master hello.t412.networking board (.ino): file
  • Arduino code for the Node 1 hello.t412.input board (.ino): file
  • Arduino code for the Node 2 hello.t1614.output board (.ino): file
  • Arduino code for software serial int the hello.t1614.output board (.ino): file
  • Arduino code for turning led on/off in the hello.t1614.output board through BT (.ino): file
Last update: June 22, 2021