Continuing this project, in this post I will talk about preparing the Raspberry Pi to become a weather station. I won't go into the details about installing Raspbian onto the SD card or using raspi-config to set the time zone and locale info for your system. You can read my previous Pi posts for those details.
For this project the Raspbian group has released something new - a "lite" version of Raspbian. This is perfect, I can get a clean bare bones Pi right out of the box. Getting wifi setup on the Pi zero is a little more complicated because there is no ethernet port. So it's a multi-step process. First you must use a keyboard and monitor and manually edit the /etc/wpa_supplicant/wpa_supplicant.conf file to add info for your wifi network. Then power down the Pi, remove the keyboard and monitor, attach the wifi adapter, then power up the Pi and connect via SSH. This is where I ran into my first problem. The RNX-N180UBE I've used in the past and ordered for this project did not work. I quickly discovered Rosewill is now making "version 2" of the adapter which uses a different chipset and Linux does not have drivers for this adapter. After much searching I found this forum post with details on where to download drivers specific to the type or Raspberry Pi and version of Raspbian you are running.
For the BME280 sensor I bought, it can be accessed via SPI or I2C. The Pi supports both, but is one better than the other? From what I can tell, SPI is a faster connection, but I2C is a better designed interface with more control. Since reading this sensor won't involve large amounts of data, I decided to go with I2C. But in order for this to work you need to enable the I2C bus inside of raspi-config.
Another step was to solder in the header to the Pi Zero. This isn't hard, and in fact it's kind of fun. But if your soldering skills are lacking then save yourself the trouble and use a Pi 1, 2, or 3.
Monday, July 25, 2016
Raspberry Pi Weather Station - part 1
My latest Raspberry Pi project is a home weather station. My original goal was a have a useful set of sensors connected to the Pi, and to make the results accessible over the Internet. That said, this process took several twists and turns along the way, probably because there are fewer people out there doing this type of project than say my previous projects of a homemade DVR or home theater. This project, unlike my previous Pi projects, is less a step-by-step guide. This is for several reasons. First, this project morphed and changed several times so it was harder for me to document as I went. And secondly, I had less free time to work on it, so I gave up on documenting while I worked.
When I decided to make a homemade weather station, I wanted to do as much "homemade" as possible. So all my sensors are connected to the Raspberry Pi's GPIO pins. The more common solution for people is to buy an off-the-shelf weather station and connect that to the Raspberry Pi's USB port. I purchased all the hardware necessary for this project (more on that later) before I even knew how it would fit together. I just had faith it was possible to do what I wanted to do. The major missing link was the software. I did not know how to read the sensors and display it meaningfully. And it was researching the software solutions available is where this project deviated from my initial thoughts. But I'll get into all that in a future post. First let's look at the hardware I used.
Raspberry Pi Zero:
For this project I went with the new Raspberry Pi Zero. Any Pi would do, but I chose the Pi Zero for several reasons.
Temperature / Humidity / Pressure
For basic atmospheric measurements I went with the Adafruit BME280. This sensor measures temperature, humidity, and pressure.
Wind / Rain
For the final set of sensors I went with the SparkFun weather sensors. These sensors measure wind speed, wind direction, and rainfall. But at $77 they are by far the most expensive item in this build.
Miscellaneous
To complete the project I needed a bunch of smaller items. I bought a Samsung Pro micro SD card because it's one the fastest cards available and I've had good luck with them in the past. For wireless I went with the Rosewill RNX-N180UBE. For power I selected an Anker wall charger (I selected a dual-port model because this single charger will power a couple of my Raspberry Pi's) as well as a 10' long Anker power cord. Lastly I purchased a waterproof electrical case at Home Depot originally designed for running conduit outside, but houses the Pi nicely and has openings on the bottom where I can run wires into the housing.
When I decided to make a homemade weather station, I wanted to do as much "homemade" as possible. So all my sensors are connected to the Raspberry Pi's GPIO pins. The more common solution for people is to buy an off-the-shelf weather station and connect that to the Raspberry Pi's USB port. I purchased all the hardware necessary for this project (more on that later) before I even knew how it would fit together. I just had faith it was possible to do what I wanted to do. The major missing link was the software. I did not know how to read the sensors and display it meaningfully. And it was researching the software solutions available is where this project deviated from my initial thoughts. But I'll get into all that in a future post. First let's look at the hardware I used.
Raspberry Pi Zero:
- The smaller size, so the weatherproof enclosure doesn't need to be as large.
- The extremely low-power consumption. As a weather station this won't need the processing power of the Pi 2/3, so save on electricity use.
- It's new and cool. I've worked with the original Pi and the Pi 2, so this was something new to try.
Temperature / Humidity / Pressure
For basic atmospheric measurements I went with the Adafruit BME280. This sensor measures temperature, humidity, and pressure.
Wind / Rain
For the final set of sensors I went with the SparkFun weather sensors. These sensors measure wind speed, wind direction, and rainfall. But at $77 they are by far the most expensive item in this build.
Miscellaneous
To complete the project I needed a bunch of smaller items. I bought a Samsung Pro micro SD card because it's one the fastest cards available and I've had good luck with them in the past. For wireless I went with the Rosewill RNX-N180UBE. For power I selected an Anker wall charger (I selected a dual-port model because this single charger will power a couple of my Raspberry Pi's) as well as a 10' long Anker power cord. Lastly I purchased a waterproof electrical case at Home Depot originally designed for running conduit outside, but houses the Pi nicely and has openings on the bottom where I can run wires into the housing.
Thursday, July 14, 2016
Programming Languages
As a computer programmer the language I prefer to program in is obviously an important subject. In my opinion C/C++ is the best all-around programming language. When I was learning to program in the mid '90s, C/C++ was the undeniable king of programming languages. However, in the time since then I feel like the industry has moved away from C/C++ to the point where some developers consider me to be a "dinosaur" for using such an old language. But I don't think I'm a dinosaur, so I wanted to talk about languages in general and defend my preferences.
There are literally hundreds if not thousands of programming languages. If you're learning programming for the first time or if you're starting a new project, how do you know which language to select? Programming languages breakdown into 4 categories; 1 low-level category and 3 high-level categories.
Assembly:
Assembly is the only low-level language where the developer writes code targeted at a specific hardware platform. Whereas hand-written assembly can be used for general purpose programming, it's very difficult to manage and nowadays assembly is mostly reserved for very specific cases, typically firmware and embedded programming systems.
Native Machine Languages:
Native machine languages are high-level languages that are compiled to target a specific platform. That is to say, if your code will run on different platforms you must compile your code once for each platform it will run on. This category includes languages like C/C++, Pascal, Fortran, Cobol, and Ada.
Virtual Machine Languages:
Virtual machine languages are similar to native in that they are compiled. But the output is not hardware or platform specific. Instead the output is "virtual" machine code that must be converted at runtime to the native machine code for the platform where your code is running. The benefit is the developer compiles once and releases a single binary, but it can run on multiple platforms. This category includes Java and C#.
Interpreted Languages:
Interpreted languages (often times called scripted languages) are not compiled. Instead at runtime a program called the interpreter converts the code from human-readable to machine code. Interpreted languages have the benefit of not needing the slow compilation process and can be quickly changed or tweaked. This category includes Python, Perl, PHP, Javascript, Ruby, and many more.
So how do you pick a language? What is the best programming language? Well, the answer is the right tool for the right job. All languages have pros and cons, so picking the best language requires an understanding of those.
Skipping assembly, because it's not really general purpose in today's world, let's talk about interpreted languages first. I might take a lot of flak for this, but I don't consider interpreted languages to have much use outside of academia. Interpreted languages are perfect for learning the basics of programming. Because these languages don't require the developer to think about things like variable types, memory management, strings, etc. they allow the person to focus on learning the basics of programming. After all, pilots don't fly a 747 as their first plane, they start on small propeller planes. To me the only use for interpreted languages is when used as a scripting language to speed up tasks and eliminate human errors. For example, say an IT person needs to create a new user account, add a machine to the domain, and assign that user to the machine. This is a perfect task for a scripting language.
But languages like Javascript, Python, PHP, and Ruby are some of the most popular programming languages, so what's wrong with these languages? The problem is speed and efficiency, or lack thereof. Because these languages are interpreted at runtime there are significantly slower than other languages. A recent comparison found these languages can be as much as 400x slower than a natively compiled program. Probably a good rule of thumb is expect between 10x and 100x slower performance compared to natively programs. That is a huge price to pay. I'm dumbfounded that so many server applications are running in languages like Javascript. That's like entering a car race with a bus.
Ok, so that leaves us natively and virtually compiled programs. Here too native programs have the performance advantage, although it's much less pronounced. A recent study found that on average C/C++ outperforms Java/C# by 20%. On the flip side, Java/C# can be faster and easier to develop in compared to C/C++. For many software companies, their highest cost is developers' salaries. So picking Java or C# may result in quicker development times which results in lower development costs. This all assumes your application is not performance critical (which most client/desktop applications aren't).
However, there is another side to the equation which developers rarely consider. If your application runs on the server side, that extra 20% performance increase by going with C/C++ translates directly into 20% less electricity used by the servers. It also means less electricity for cooling the server room which saves even more money. When you start talking about applications that run on servers, suddenly the hardware for those servers, electricity used to run those servers, and the cooling costs for the servers outweighs development costs. So in cases like this a native language is probably your best choice.
There is another benefit to native languages - extended battery life. In that same study above, they found that C/C++ programs ran for approx. 20% longer on a given battery charge compared Java/C#. So anyone developing applications that will run on a laptop, tablet, or phone should seriously consider a native language.
It is true that C/C++ is not the king it once was. However, when you group C/C++ together it's still the number 1 programming language ahead of Java. Also, any programming field where you need performance (e.g. video games) then C/C++ is the language of choice. Yet another example is operating systems. Every major operating system in existence is written in C - which includes Windows, Linux, Mac, Unix. Even "mobile" operating systems like Android are built on top of Linux which is written in C.
So without a doubt C/C++ has a place in the modern world. I think it's unfortunate that so many developers have gotten caught up in the virtual and interpreted language hype and forgotten about the power of a native programming language. That said, recently there has been a resurgence in native programming languages driven largely by mobile devices with their relatively low resources and battery power, they are the perfect platform for a native programming language.
There are literally hundreds if not thousands of programming languages. If you're learning programming for the first time or if you're starting a new project, how do you know which language to select? Programming languages breakdown into 4 categories; 1 low-level category and 3 high-level categories.
Assembly:
Assembly is the only low-level language where the developer writes code targeted at a specific hardware platform. Whereas hand-written assembly can be used for general purpose programming, it's very difficult to manage and nowadays assembly is mostly reserved for very specific cases, typically firmware and embedded programming systems.
Native Machine Languages:
Native machine languages are high-level languages that are compiled to target a specific platform. That is to say, if your code will run on different platforms you must compile your code once for each platform it will run on. This category includes languages like C/C++, Pascal, Fortran, Cobol, and Ada.
Virtual Machine Languages:
Virtual machine languages are similar to native in that they are compiled. But the output is not hardware or platform specific. Instead the output is "virtual" machine code that must be converted at runtime to the native machine code for the platform where your code is running. The benefit is the developer compiles once and releases a single binary, but it can run on multiple platforms. This category includes Java and C#.
Interpreted Languages:
Interpreted languages (often times called scripted languages) are not compiled. Instead at runtime a program called the interpreter converts the code from human-readable to machine code. Interpreted languages have the benefit of not needing the slow compilation process and can be quickly changed or tweaked. This category includes Python, Perl, PHP, Javascript, Ruby, and many more.
So how do you pick a language? What is the best programming language? Well, the answer is the right tool for the right job. All languages have pros and cons, so picking the best language requires an understanding of those.
Skipping assembly, because it's not really general purpose in today's world, let's talk about interpreted languages first. I might take a lot of flak for this, but I don't consider interpreted languages to have much use outside of academia. Interpreted languages are perfect for learning the basics of programming. Because these languages don't require the developer to think about things like variable types, memory management, strings, etc. they allow the person to focus on learning the basics of programming. After all, pilots don't fly a 747 as their first plane, they start on small propeller planes. To me the only use for interpreted languages is when used as a scripting language to speed up tasks and eliminate human errors. For example, say an IT person needs to create a new user account, add a machine to the domain, and assign that user to the machine. This is a perfect task for a scripting language.
But languages like Javascript, Python, PHP, and Ruby are some of the most popular programming languages, so what's wrong with these languages? The problem is speed and efficiency, or lack thereof. Because these languages are interpreted at runtime there are significantly slower than other languages. A recent comparison found these languages can be as much as 400x slower than a natively compiled program. Probably a good rule of thumb is expect between 10x and 100x slower performance compared to natively programs. That is a huge price to pay. I'm dumbfounded that so many server applications are running in languages like Javascript. That's like entering a car race with a bus.
Ok, so that leaves us natively and virtually compiled programs. Here too native programs have the performance advantage, although it's much less pronounced. A recent study found that on average C/C++ outperforms Java/C# by 20%. On the flip side, Java/C# can be faster and easier to develop in compared to C/C++. For many software companies, their highest cost is developers' salaries. So picking Java or C# may result in quicker development times which results in lower development costs. This all assumes your application is not performance critical (which most client/desktop applications aren't).
However, there is another side to the equation which developers rarely consider. If your application runs on the server side, that extra 20% performance increase by going with C/C++ translates directly into 20% less electricity used by the servers. It also means less electricity for cooling the server room which saves even more money. When you start talking about applications that run on servers, suddenly the hardware for those servers, electricity used to run those servers, and the cooling costs for the servers outweighs development costs. So in cases like this a native language is probably your best choice.
There is another benefit to native languages - extended battery life. In that same study above, they found that C/C++ programs ran for approx. 20% longer on a given battery charge compared Java/C#. So anyone developing applications that will run on a laptop, tablet, or phone should seriously consider a native language.
It is true that C/C++ is not the king it once was. However, when you group C/C++ together it's still the number 1 programming language ahead of Java. Also, any programming field where you need performance (e.g. video games) then C/C++ is the language of choice. Yet another example is operating systems. Every major operating system in existence is written in C - which includes Windows, Linux, Mac, Unix. Even "mobile" operating systems like Android are built on top of Linux which is written in C.
So without a doubt C/C++ has a place in the modern world. I think it's unfortunate that so many developers have gotten caught up in the virtual and interpreted language hype and forgotten about the power of a native programming language. That said, recently there has been a resurgence in native programming languages driven largely by mobile devices with their relatively low resources and battery power, they are the perfect platform for a native programming language.
Subscribe to:
Posts (Atom)