Serial Communications with Arduino Part 2 - Software Serial Ports

 Last recently, I put up a short post on how we can use Arduino to read data from a device. Cunningly, I made the process so simple (mainly for myself) that I neglected to actually use an Arduino.

So, in this post I will remedy that by providing an example on how to read data from a device using serial communication at the start, then move on to writing to the serial port.

In the last post, I gave an example of how you can connect a USB to TTL adapter to a device and read its data. This time round, we are going to use the UNO R3 to act as our USB to serial adapter. To do this, we are going to be using the following

• 1x    breadboard
• 1x    Arduino UNO R3 
• 1x Neo-6M/GY-GPS6MV2 GPS Module
• 1x CH340 USB to TTL adapter
• Jumper wires

The proposition is quite simple; we want to send the output of the GPS module to the board over a serial port. Unfortunately, I have not found a way to simply connect it to the TX/RX pins on the board itself and have it output data. So, to accomplish this we need to create a second serial port to handle the incoming stream of information from the GPS module itself and we need to create that port in software.

To do this, we are going to have to use the Software Serial Library.:

1:  #include "SoftwareSerial.h"  
2:  SoftwareSerial ss(8, 9);  

The first line references the library we need to use in this program. If you get an error when compiling this code, you might want to check that you have this library installed from within the Library Manager.

The second line is simply us creating a new software serial port called "ss", the numbers following represent the RX and TX pins on the board.

Next, we have to set up our ports, this should be familiar to anyone who has been using the Serial Monitor from within the Arduino IDE: 

1:  void setup() {  
2:   // put your setup code here, to run once:  
3:   Serial.begin(9600);  
4:   ss.begin(9600);  
5:  }  

Here we can see that on line 3 the hardware serial port is started with a baud rate of 9600 - this is the speed at which the port is reading/writing at. Line 4 is almost exactly the same, however this is the software serial port that is being started this time, note that we are also starting it at the same baud rate.

From reading up on using this library, it seemed that 9600 was the highest baud rate to go for and still have a stable connection. The GPS module can work up to 115200 baud, however when I configured the serial ports to use this speed, nothing happened.

Next up, we have the main executing of the code itself. We read the data leaving the GPS module on its TX port on to the boards hardware RX port and vice versa: 

1:  void loop() {  
2:   // put your main code here, to run repeatedly:  
3:   if (ss.available())  
4:    Serial.write(ss.read());  
5:   if (Serial.available())  
6:    ss.write(Serial.read());  
7:  }  

Line 3 checks to see if the software serial port is available, if it is then the hardware serial port then writes whatever the software serial port is reading on line 4.

Line 5 does the opposite, if the hardware serial port is available the software serial port writes whatever the hardware serial port is reading - which happens to always be whatever the software serial port is reading due to the structure that we have created.

Think of the above as an exchange - the hardware serial port is empty until it reads the incoming message from the software serial port. Once it has that, then both ports will have the same message.

Make sure you have your serial monitor running when you upload the code, you should see something like this:

The full listing for the code will be at the bottom of this post.

At the start of this article I mentioned that I used a CH340 USB to TTL adapter for debugging. This is because I had a fairly hard time getting the software serial port actually doing what I wanted it to do, quite a few of the articles I had read on the subject provided examples that simply did not work so I began to think my GPS module had become damaged.

So, to verify that the GPS module was working whilst the board was running the code, I connected it in series with the wires going from the GPS module to the board.

This let me run putty to make sure that I was getting something from the GPS module itself and make sure there was an incoming message for the board to do something with. It was actually quite helpful to do this while figuring out my problem. 

The setup, minus the USB to TTL adapter, looks like this:

If you are trying this out for yourself, then hopefully you are seeing a nice barrage of NMEA sentences scrolling across your serial monitor.

However, if you are seeing nothing, then try swapping your RX/TX pins on the board itself. You might have gotten them mixed up - I certainly did a couple of times.

SoftwareSerial is not the only library available that can do the same thing. Another, very popular library you can install is AltSoftSerial. Syntactically, it is almost identical to SoftwareSerial and supports a wide arrange of MCU's and development boards. You can also use a mixture of different libraries to give yourself multiple serial ports to work with, should you need to, for example if you had a number of devices that provided data in the same way as the GPS module you will need to have more than one serial port configured to a set of pins. That way you will have an uninterrupted flow of data from each device on its own serial port.

So what does all of this mean? Well essentially it is just a description of how you can easily set up a couple of serial ports to share data. But in this specific context, where could we take the build next? We are using a GPS module and we can see the NMEA sentences that it is receiving. We also know that each sentence begins with a $, so we could easily read the sentences into an array or object in order to process them further.

From looking at the output, we can see that there are six distinct types of sentence being received, or at least the module is trying to populate the contents of six sentences with data from the GPS constellation, with that knowledge we might be able to do something useful with that data...

The full code listing for used for this article is as follows: 

1:  #include "SoftwareSerial.h"  
2:    
3:  SoftwareSerial ss(8, 9);  
4:    
5:  void setup() {  
6:   // put your setup code here, to run once:  
7:   Serial.begin(9600);  
8:   ss.begin(9600);  
9:  }  
10:    
11:  void loop() {  
12:   // put your main code here, to run repeatedly:  
13:   if (ss.available())  
14:    Serial.write(ss.read());  
15:   if (Serial.available())  
16:    ss.write(Serial.read());  
17:  }  

Using Transistors As a Switch with Arduino

 Recently, I have had reason to look into switches and how they can work with Arduino, and other popular MCU's.

This is part of a larger piece of investigation that is looking into buttons, sliders, potentiometers, switches etc as inputs whilst I think about how to make my own keyboard.

Of course, everyone has heard of a transistor. We all have some form of awareness as to how important they are with regards to the evolution of technology and computing. But what is a transistor really? Anyone with a background, or an interest in computing will probably tell you that they are used to calculate things on a CPU, and they are correct - but this isnt what transistors are limited to.

I am not going to go into the science of transistors here or how they work on a microelectronic level, there are plenty of other blogs and articles who have done a much better job than I could ever do. What I am aiming to do here is to give a quick guide on how to pretty much use a transistor as a switch, how to connect one up and how to control one in the code.

Transistors basically can do two things; they act as switches and they can help amplify signals. And they do this by controlling the current flowing through them. However today, I am only going to be talking about how they can be used as a switch in this article. You may be asking why would you want to use a transistor as a switch? There are no physical controls, so you would need to programmatically control it - and that's the beauty of using a transistor as a switch.

One really good example of how this can be used could be this - you have a light somewhere that you want to turn on when it gets dark. You build a circuit with a lamp, and a light sensor. When the state of the light sensor reaches a certain point, you then want the lamp to light up. So you can use a transistor to act as the switch to do this.

Naturally, all of this would require an MCU of some type as well as some code, but it really is a nice little example of a potential application.

One of the neat features of using a transistor as a switch is, depending on your transistor, that you may be able to switch on a circuit of a much higher voltage. This is because a lot of transistors are capable of handling a lot more voltage because of their amplification abilities.

Transistors typically come with three pins, which are cryptically called:

• Collector: This is normally the current you are trying to control.
• Base: This is normally the current you use for the switch. It controls the bias on the transistor.
• Emitter: This normally goes to ground.

For the examples below, I will be using the following components:

• 2x 1 kohm resistors
• 1x red LED
• 1x PN2222A transistor
• 1x Pro-Micro/Arduino Nano MCU

Here is an example diagram to help visualise this:

On this breadboard we have a transistor acting as a switch to control the LED. When 5 volts is applied to the power rail, the LED will light up, if I remove the transistor from the circuit then apply power, the LED would not light up.

Why is this? Well, to explain this, lets look at the names of the pins in relation to the connections in the diagram. 

Starting from left to right, we have the collector first on pin 1. This has the LED connected to it, with a 1K resistor running to 5 volts. This part of the circuit represents the current we are trying to control.

The middle pin, pin 2 - we have the base. This is the switch itself, when enough current is passing through it, the switch is closed. When there is insufficient, or zero current flowing through it, the switch is open. This controls the flow of current through the collector - this means when the switch is closed, current flows through the collector and the LED lights.

On the right, we have the third pin, which is tied to ground.

If you construct this circuit, there are two ways to test it. Firstly, remove the transistor from the circuit and apply power - the LED should be off. If it is on, then you are passing power to the LED without the transistor controlling it.

Second, disconnect power from the base, this should turn off the LED. If it doesnt, then again - you are probably passing power to the LED outside of the control of the LED.

Now, the above shows a transistor controlling current to an LED using 5 volts, but remember when I said they can also be used to control the current in circuits that require a higher voltage? We can create an example of this as well, but this time using 3.3 volts to control the transistor whilst still using 5 volts to light the LED:

All that has changed in this example is that we are now applying 3.3 volts to the lower power rail as well as 5 volts to the upper power rail. When the power is connected, the LED will light up.

One point to note here is that using a transistor in this setting is rather pointless. All this circuit does is provide power to an LED. This can lead to some confusion  when building such a circuit for testing or educational purposes.

So how about we create the classic "blink", but this time using our transistor? To do this, we are going to need to use a micro controller, for this example I am going to use a Pro-Micro/Arduino Nano using 5 volts. This means we can keep our initial breadboard design the same, more or less.

All we need to do is alter the way the transistor is biased. Instead of simply being powered directly from the power rail, we are going to connect it to a GPIO pin:

This is the same circuit as the one I initially built. It is orientated differently to accommodate its one difference, and that difference is how we are controlling the base on the transistor.

Previously, we were simply providing it with current, which caused the LED to be illuminated for as long as power was available. However in this example, we have connected the base to pin 2 on the Nano. Unless you make it happen, pin 2 will not be high, which means if you create this circuit and power it, the LED will not light up.

So, on to the the classic "blink", to achieve this we need to write a couple of lines of code, the whole thing is this:

1 2 3 4 5 6 7 8 9 10 11 12 13

void setup() { // put your setup code here, to run once: pinMode(2, OUTPUT); } void loop() { // put your main code here, to run repeatedly: digitalWrite(2, HIGH); delay(1000); digitalWrite(2, LOW); delay(1000); }

The setup for this is simple, we just need to define the pin we are going to use to control the base. In the diagram we have it connected to pin 2, so that is what we define here. We need this to be used for output, as we will be sending a signal to the transistor.

The main body of the program should be familiar to anyone who has tried out the blink sketch that is used to test out various developer boards. We simply take pin 2 high for a couple of seconds before sending it low for the same amount of time.

This basically opens and closes the transistor as if it were a switch, if you try this out for yourselves, you will see the LED blinking on and off every couple of seconds.

Now, lets get in to some specific points that are worth mentioning:

Using resistors is essential. Not putting a resistor across a transistor in the way I have shown above can often cause your transistor to melt, it certainly did for me unless the ones I had were also defective. It is important to note that the resistors you use should be of the appropriate resistance for your load - it wont always be 1 kOhm.

The examples above use an Arduino Nano, but everything here is also compatible with the cheaper Pro-Micro developer board. The only difference between the two boards is that one provides a 3.3 volt rail and the other doesn't.

Using a GPIO pin to control the biasing of a transistor is the win here. The state of the transistor can be governed by the state of a separate sensor(s), the result of a programmatical state or pretty much anything that is capable of changing the state of that pin.

For me, it was fun but a little frustrating learning about how transistors work. Writing this blog entry has been part of my learning process and perhaps someone will find it useful in the future themselves :)

Lego is Great

Ever since I was a kid I have been interested in building things. I would use anything to hand, building blocks, plasticine and of course Lego!

I think that for most people who are the same age as me and were also Lego fanatics, there are always a few kits that stick in your mind. For me, it was the Mega Core De-Magnetiser, part of Lego's space line up.

At the time, there was no way I could afford it myself, and I didn't have similar pieces to make my own version. Funnily enough, it was a recession then, just like it is now. However, I am older and we have EBay!

I got mine off Ebay, and for something that's almost fourteen years old, it is still in pretty good nick. It really brought my childhood back to me, the only difference is that it took me four and a half hours to build it! I am certain that I would have been able to do it much, much faster when I was small.

Anyway, it was a fun diversion, I even documented the build to prove to others I am not just spouting off.

Now that I think about it a little more, I am pretty sure this kit came out closer to twenty years ago, not fourteen... poor memory must be a sign of old age...>

The chassis:

You don't really get a good idea of how complex this thing actually is. It is essentially a real wheel steering vehicle using split axels - a bit like the current Batmobile, but with added six wheel drive.

There is also a clever crane mechanism that sits on top the thing when it is built. It is one of the rare occasions where a mainstream Lego kit gets to use pieces from Lego Technic. When the build is complete, it is about 17 cm long and about 15 cm high, if you take into account the crane mechanism as well, it ends up as a fairly stout model:

The canopy is a little different to most other Lego Space kits from then as it flips up from the front. If memory serves me correctly, most kits from that time had canopy's that swing upwards.

Either way, I am pleased as punch to finally get one of these kits, I think I waited long enough!!