FabAc 2021
Mauro Herrero-FabLabLeon-URJC

13. Networking and communications

I have to admit that I was quite scared before the last week ended; I have only been able to partially complete almost all electronics related assigments, and was not confident at all with the embedded programming part. But finally, I managed to go through the complete workflow with all the boards that I've made to the date, and that has been a blast for me.

One of the key concepts that Neil talks about in designing is modularity. Up to now, even that I did not know how the inteligence of my final project was going to be built, I thought that one component in that modularity was going to be the electronics. But after the class, all the electronics is going to be splitted into subsystems:

Before the class, I thought that Networking and communications dealt only with the last item. Now I now that it deals with how each of those subsystem talk and listen to each other. This is huge, when I thought about it, and I found two great advantages over having all the electronics in a single board:

Understanding how computers comunicate: line code

In any given transmission line, if voltage, current or photons can flow using pattern to represent digital data, that pattern is a line code. In the scope of Fab Academy, we have been using patterns of voltages, either 0 or 5 v, to move data in our systems.

Parallel vs. Serial

Up to right now, to me parallel and serial were just two names, refering, mostly, to two different types of ports in a computer. I went through a tutorial on serial communication, by Jimblom from Sparkfun. I learned that parallel interfaces transfer multiple bits at the same time, using buses of data, controlled by a clock. On the other hand, serial interfaces stream their data one bit after the next, and can operate even with just one wire. The most common being 4 wires (i.e. Tx, Rx, Gnd, Vcc).

Parallel communication is fast and reliable, but requires one I/O per wire. Since pins in the little microcontrollers we use are precious and few, we will stick to serial communication when using them.

Synchronous vs. Asynchronous

If there is a line that carries a clock signals, so all devices connected share the same clock, then the protocol is said to be Synchronous. Otherwise, and widely used, it is Asynchronous. Since there is no clock signal, the numer of wires and I/O devices can be minimized, but there are some rules the protocol needs to follow in order to assure that the data recieved actually is the data sent.

When connecting two devices, it is critical to have them configured so they use the exact same protocols. The mechanisms used to ensure proper data transfer are: Syncronization bits, data bits, parity bits and baud rate.

Baud rate sets how fast data is sent over. The usual units are bits-per-second (bps), or bauds. As one may intuitively think, faster rates allow faster communications, but can run into errors. If speed is not critical, use 9600 bps, but with the family of microcontrollers we use can go up to 115200 bauds, as stated, for instance, in the ATtiny 412 datasheet.

Data chunk is the portion of the message that carries the info the sender wants the reviever to have. Its size is not specifically stated, and each packet can have anything from 5 to 9 bits, being the most common the 8-bit byte.

The Synchronization bits are transfered with every data package, before and after the actual data. The start bit sets the idle data line from 1 to 0, and the ending bit will set it back to 1.

Parity bits are used to check for errors: all of the bits of the data packge are added up, the result can either be odd or even. Parity has to be set beforhand both in transmitter and receiver, to odd or even. If it is set to odd, then the parity bit would be one in case the sum is odd and zero in case the sum is even. There are pitfalls, since it slows down the data transmition, and an error handling protocol has to be implemented.

Baby steps: communicating three Arduinos in Tinkercad

First I did thing after our local instructors recitation on Thursday, was to follow this Arduino networking tutorial, written by our instructor Pablo. At first, both the setup and the code did not mean much to me.

By the end of the week, I replicated physically the setup (just with one staff Arduino, and everything made a bit more sense. I still do not get why in most setups that I have seen, Rx and Tx are crossed over. I do get that that way one is the manager while all the remaining are the staff. So all communication between staff has to go through the manager.

Choosing three boars for networking

I know I could modify the boards that I have made in the previous weeks. But I am also aware that I need lots of practice, both designing and soldering PCBs. So I will make at least two new boards for this week. One will use the VL53L1X, to measure the distance; the other will be another version of the stepper driver. I will reuse the first board I designed, the hello board with the LED and the button.

Time of flight: VL53L1X

During input devices week, I would have loved to use also this device, but I just struggled to finish the sonar. So now it is finally time for this one!

After looking at Neil's hello VL53L1X I wondered why had he used the t1614 instead of the smaller t412, since only six pins where used. After a quick search, I learned, thanks to Omar Al Dajani that it is because the 412 does not have enough memory for the wire.h and VL53l1.h Pololu library.

This board has quite a few connectors: FTDI, UPDI, network and VL53L1X. For the UPDI I used Adrian's enhanced version which added a Vcc pin. I also added an LED, my intention is to blink it whenerver the ToF sensor makes a measurement. I intentionally let more room between the t1614 pads and the next components, to make my life easier when soldering it.

I added a 2x2 2.54 pin header to the board, with Vcc, gnd, Rx and Tx. I can already tell that I work faster after every cycle, and I keep enyoing routing the PCBs. Something I noticed this time, was that I was able to close a ring for the gnd net. I really had no idea wheather that would be right, wrong or indifferent, so I asked my instructors. Adrian told me that it would be a good thing: if, for whatever reason the gnd track would fail at a given point, the board would still work.

Files for ToF board:

I order to test the board, I installed the Pololu VL53L1X library. This was the first time that I was adding a library to the Arduino IDE, so I followed the instructions from the Arduino guides. It is really staightforward, and it lets you choose what version of the librery you want to install.

The procedure to upload a program using pyupdi even is something I am working on in this week, is under embedded programming.

After a quite hefty debugging cycle, my local instructor Adrian figured out that my FTDI cable was damaged. I ordered a new FTDI-TTL converter, that arrived just before Wednesday's review, and I succesfully loaded the program!

Bipolar stepper driver: A4953

Nuria, Pablo and Adrian advised me that I could just add a Tx and a Rx connection to two free pins in the t44, reusing the board that I had already made. But, there are a number of reasons why I rather make a new one, including practicing with soldering, not messing up a board that seems to work, and adding a better looking conection for the network wires. I know I have little experience, both programming and soldering, and no experience at al in networking, and that is going to be challenging. But when I succed, I know it will have been a great leap towards completing my final project.

Last week, it took me a quite long time to solve the sudoku. It was the board with the highest component count that I have made to date. So this time, instead of reinventing the wheel, I copied Neil's hello.stepper.bipolar, just adding the 2x2 ping header with Vcc, gnc, Rx and Tx. I know it would have been easier to use a newer microcontroller, getting rid of the ISP mess, but I still have a few more t44 to spare, and this was a chance to do so.

Mods and milling

I used the same workflow as I have during the last assignments, using mods to get the g-code, with the g-code 2.5D pcb mill program. The parameters used are:

I milled two instances of each board, to have a backup. Due to lockdowns, I am doing most of the work from home, and milling is the one thing I have to go to the shop to do. To optimize milling time, I milled several boards in the shame copper plate. By changing the position of the origin of each one, I could mill all the traces first and the cutouts later, so I just had to make one toolchange.

Since the VL53L1X board uses the t1614, I also needed a serial to UPDI converter. I used Adrian's enhaced version, which adds an Vcc pin to it. This time, I did not redrew it in Kicad, I just used his png files directly.

This time, I am really happy. Previous weeks took me way more time to get to the point where I am today, and I modified not one but two boards! Soldering has also improved a lot, using a lower temperature (320C) and clean iron tip have really helped me. Also, reflowing tough to solder components, such as the A4953, has also helped to reduce the time spent. So hopefully, during the weekend, I will be programming and connecting the boards.

Connecting two boards

Since I am still debugging the board with the ToF sensor, I will connect for this week assignment two boards that are already working: the new version of the bipolar stepper and my hello board with an LED and a button. I will use the 2x2 pin header in the first and the FTDI pins in the latter.

I used colored cables with Dupont connectors:

It took me and my instructors a lot of time to finally figure out what was so wrong... but the FTDI cable was damaged, so I could not read properly the data from the boards. At the very least, I was able to get some of the code up and runnign in an Arduino one, so every time the button is pressed, it sends a signal through serial, that the computer can read.

Also, I also managed first to have one Arduino board turn on and blink the light of a second board, also using serial communication. This is the scheme of the conections, note that the manager board connects Tx to the staff board Rx:

And a video showing how the program works, and the data flow from one board to another. In this scheme, more staff boards could be added, always connecting their Rx to the manager Tx.

And here can be found the code that made them run:

Group assignment: connecting two projects

This week's group assignment is also a bit awkward for me, since being a remote student I am alone in my lab. At first, I wanted to connect some of the boards I had made to date. My first idea was to use the one that has the button to send a letter through serial, and when the steeper board received that leter, it would turn.

Everything was going ok, but for some reason I still do not get, the data is nonsense. Instead of receiving a letter "a", I get a reversed question mark:

I uploaded the same code to an Arduino setup, and it worked just fine, sending the letter through serial everytime the button was pushed. I am really sorry for the tangle of wires, but this is an emergency...

For the stepper board I had to use the SoftwareSerial.h library, since the two pins for hardware UART were already in use in Neil's desing... I set PB1 (Arduino 9) and PB0 (Arduino 10) to Rx and Tx. Then I wrote a very simple code that read from serial and compared to the node character. If they matched, the stepper would turn; if not, it just would stay still.

And finally this is the communication between the two boards. Notice that Tx and Rx are crossed, so one transmits and the other listens.

This are the code used in the two boards:

Debugging, debugging, debugging...

This week's work had tons of debuggin in it. I made new boards, with the risk that it renders. But I really felt that I needed to make them in order to iterate as many times as possible. Probably the goals that I set at the beginning were way too high for my skills. But I know I have to push in order to advance. It is true that I got plenty of errors:

But is debugging when I find I learn the most.