New Raspberry Pi Model B+

The Raspberry Pi foundation announced what it calls “an evolution” of the Raspberry Pi SBC. Compared to the previous model, the new Raspberry Pi Model B+ has more GPIO, and more USB ports. In addition, it uses Micro SD memory cards and improved power consumption.

Source: Raspberry Pi Foundation

Source: Raspberry Pi Foundation

 

The GPIO header is now 40 pins, with the same pinout for the first 26 pins as the Model B. The B+ also has four USB 2.0 ports (compared to two on the Model B) and better hotplug and overcurrent behavior. In place of the old friction-fit SD card socket is a better push-push micro SD version.

In line with today’s electronic concepts, the new board also lowers power consumption. By replacing linear regulators with switching ones, the power requirements are reduced by between 0.5 W and 1 W. The audio circuit incorporates a dedicated low-noise power supply, enabling better audio applications.

The new board is well organized. The USB connectors are aligned with the board edge, and the composite video now has a 3.5-mm jack. The corners are rounded with four squarely placed mounting holes.

The Raspberry Pi Model B+ uses the same BCM2835 application processor as the Model B. It runs the same software and still has 512-MB RAM.

If you want to adapt a current project to the new platform, be sure to study the new GPIO pins and mechanical specs. To ensure continuity of supply for industrial customers, the Model B will be kept in production for as long as there’s demand for it.

At $35, the new model B+ is the same price as the older model B and is already available from Farnell/element14/Newark and RS/Allied Components.

[Source: www.raspberrypi.org]

Nesit

NESIT wants to create, educate, and foster learning in the fields of various technological and other disciplines. They reap the benefits of productivity through volunteer collaboration.

Location 290 Pratt St., Meriden CT 06450
Members 30
Website nesit.org

Read about what Vice President Will Genovese has to say about NESIT.
Tell us about your meeting space!

NESIT meets in a 4000 square feet office that takes place in The Meriden Enterprise Center. A large office and manufacturing building that is home to over 60 businesses.

What tools do you have in your space? 

Soldering stations, oscilloscope, 3-D printer, woodshop, cnc, and a data center.

Are there any tools your group really wants or needs?

A lasercutter would be a nice addition to our arsenal.

What sort of embedded tech does your Hackerspace work with?

We work with PIC, Arduino, and Raspberry Pi, and many more.
In fact one of our recent projects was a DIY PIC Programmer.

Can you tell us about some of your group’s recent tech projects?

1012388_631853183518705_1732534179_n

One of the group’s first tech projects was the “MAME,” a full-size gaming arcade. The project was going well until there was a break in at the location and they lost some equipment; the MAME was put on the backburner.  After they moved to their new location and gained a new member, an art teacher named John, the project garnered interest again. He came up with the design for it. Afterwords it was painted, they got a coin mechanism, speakers were hooked up, and the software was installed and configured. IT was finally finished.

Click here if you want to check it out.

What’s the craziest project you’ve completed?

At the moment we have not yet completed projects I would categorize as “crazy.”

Read more about NESIT on their website. 

Show us your hackerspace! Tell us about your group! Where does your group design, hack, create, program, debug, and innovate? Do you work in a 20′ × 20′ space in an old warehouse? Do you share a small space in a university lab? Do you meet at a local coffee shop or bar? What sort of electronics projects do you work on? Submit your hackerspace and we might feature you on our website!

Linux System Configuration (Part 1)

In Circuit Cellar’s June issue, Bob Japenga, in his Embedded in Thin Slices column, launches a series of articles on Linux system configuration. Part 1 of the series focuses on configuring the Linux kernel. “Linux kernels have hundreds of parameters you can configure for your specific application,” he says.

Linux system configurationPart 1 is meant to help designers of embedded systems plan ahead. “Many of the options I discuss cost little in terms of memory and real-time usage,” Japenga says in Part 1. “This article will examine the kinds of features that can be configured to help you think about these things during your system design. At a minimum, it is important for you to know what features you have configured if you are using an off-the-shelf Linux kernel or a Linux kernel from a reference design. Of course, as always, I’ll examine this only in thin slices.”

In the following excerpt from Part 1, Japenga explains why it’s important to be able to configure the kernel. (You can read the full article in the June issue, available online for single-issue purchase or membership download.)

Why Configure the Kernel?
Certainly if you are designing a board from scratch you will need to know how to configure and build the Linux kernel. However, most of us don’t build a system from scratch. If we are building our own board, we still use some sort of reference design provided by the microprocessor manufacturer. My company thinks these are awesome. The reference designs usually come with a prebuilt kernel and file system.

Even if you use a reference design, you almost always change something. You use different memory chips, physical layers (PHY), or real-time clocks (RTCs). In those cases, you need to configure the kernel to add support for these hardware devices. If you are fortunate enough to use the same hardware, the reference design’s kernel may have unnecessary features and you are trying to reduce the memory footprint (which is needed not just because of your on-board memory but also because of the over-the-air costs of updating, as I mentioned in the introduction). Or, the reference design’s kernel may not have all of the software features you want.

For example, imagine you are using an off-the-shelf Linux board (e.g., a Raspberry Pi or BeagleBoard.org’s BeagleBone). It comes with everything you need, right? Not necessarily. As with the reference design, it may use too many resources and you want to trim it, or it may not have some features you want. So, whether you are using a reference design or an off-the-shelf single-board computer (SBC), you need to be able to configure the kernel.

Linux Kernel Configuration
Many things about the Linux kernel can be tweaked in real time. (This is the subject of a future article series.) However, some options (e.g., handling Sleep mode and support for new hardware) require a separate compilation and kernel build. The Linux kernel is written in the C programming language, which supports code that can be conditionally compiled into the software through what is called a preprocessor #define

A #define is associated with each configurable feature. Configuring the kernel involves selecting the features you want with the associated #define, recompiling, and rebuilding the kernel.

Okay, I said I wasn’t going to tell you how to configure the Linux kernel, but here is a thin slice: One file contains all the #defines. Certainly, one could edit that file. But the classic way is to invoke menuconfig. Generally you would use the make ARCH=arm menuconfig command to identify the specific architecture.

There are other ways to configure the kernel—such as xconfig (QT based), gconfig (GTK+ based), and nconfig (ncurses based)—that are graphical and purport to be a little more user-friendly. We have not found anything unfriendly with using the classical method. In fact, since it is terminal-based, it works well when we remotely log in to the device.

Photo 1—This opening screen includes well-grouped options for easy menu navigation.

Photo 1—This opening screen includes well-grouped options for easy menu navigation.

Photo 1 shows the opening screen for one of our configurations. The options are reasonably well grouped to enable you to navigate the menus. Most importantly, the mutual dependencies of the #defines are built into the tool. Thus if you choose a feature that requires another to be enabled, that feature will also automatically be selected.

In addition to the out-of-the-box version, you can easily tailor all the configuration tools if you are adding your own drivers or drivers you obtain from a chip supplier. This means you can create your own unique menus and help system. It is so simple that I will leave it to you to find out how to do this. The structure is defined as Kconfig, for kernel configuration.

HackRVA: They provide the tools, you provide the enthusiasm

HackRVA Sign4HackRVA is a Richmond-based makerspace. They like to take things apart, put them back together, figure out how they work, and create new things. Their mission? To learn and make stuff sharing tools and knowledge in technology; including Arduino, Makerbot, Linux, and the Open Source movement.

Aaron Nipper will tell us a little more.

Location 1600 Roseneath Road, Suite E, Richmond, VA 23230
Members 65
Website www.hackrva.org

What’s your meeting space like? 

Our space is about 2,000 square feet. We have an AV and general meeting area, a tech lab, and a fab lab.

What’s in your “toolbox”?

  • Two 3D printers
  • Laser cutter
  • Lots of soldering stations
  • O-scopes
  • Hand and power tools
  • A computer lab

Are there any tools your group really wants or needs?

A CNC Router — like a shopbot. Can’t wait to build that first wiki-house!

Arduino, Raspberry Pi, embedded security… which embedded technologies does your group work with most frequently? 

We use all that stuff. Arduino, R-Pi, whatever we can get our hands on! We’ve designed, from scratch, PCB Badges for RichSec security conference the last three years. Click here to learn more about the PCB Badges project.

What have you been working on lately?

For the past three years, we’ve designed those PCB badges for the RichSec security conference. Here’s another recent build where a member took a Power Wheels and made it Xbox controller driven. Check out the video below or click here to read more about that project.

Do you have any events or initiatives you’d like to tell us about? Where can we learn more about them?

You can learn more about us at hackrva.org. We host the Richmond Maker Guild, have regular Saturday Hackathons, as well as a Noise Night. Members are always coming up with creative events!

Any words of advice for fellow hackers?

My personal motto is fail often, teach others, and post to the web. All those things help me learn and think about projects better.

Want to know more about what HackRVA does? Check out their Facebook page and website.

Show us your hackerspace! Tell us about your group! Where does your group design, hack, create, program, debug, and innovate? Do you work in a 20′ × 20′ space in an old warehouse? Do you share a small space in a university lab? Do you meet a local coffee shop or bar? What sort of electronics projects do you work on? Submit your hackerspace and we might feature you on our website!

Build an Automated Vehicle Locator

Several things inspired Electrical and Computer Engineering Professor Chris Coulston and his team at Penn State Erie, The Behrend College, to create an online vehicle-tracking system. Mainly, the team wanted to increase ridership on a shuttle bus the local transit authority provided to serve the expanding campus. Not enough students were “on board,” in part because it was difficult to know when the bus would be arriving at each stop.

So Coulston’s team created a system in which a mobile GPS tracker on the bus communicates its location over a radio link to a base station. Students, professors, or anyone else carrying a smartphone can call up the bus tracker web page, find out the bus’ current location, and receive reliable estimates of the bus’ arrival time at each of its stops. Coulston, computer engineering student Daniel Hankewycz, and computer science student Austin Kelleher wrote an article about the system, which appears in our June issue.

Circuit Cellar recently asked Coulston if the system, implemented in the fall 2013 semester, had accomplished its goals and might be expanded.

“The bus tracker team is tracking usage of the web site using Google Analytics,” Coulston said. “The data reveals that we get on average 100 hits a day during cold weather and fewer on warmer days. Ridership has increased during this past year, helping assure the long-term presence of the shuttle on our campus.”

“Over winter break, shuttle service was increased to a distant location on campus,” he added. “In order to better track the location of the shuttle, a second base station was added. The additional base station required a significant rework of the software architecture. The result is that the software is more modular and can accept an arbitrary number of base stations. There are no plans at present to add a second bus—a good thing, because this change would require another significant rework of the software architecture.”

Initially, Coulston looked to other real-time vehicle trackers for inspiration: “There are a variety of live bus trackers that motivated my early ideas, including the University of Utah’s Live Tracker  and the Chicago Transit Authority’s CTA Bus Tracker. Given our single bus route on campus, I was motivated to keep the interface simple and clean to minimize the amount of time needed to figure out where the bus is and how long it’s going to take to get to my stop.”

The system, as it was originally implemented in August 2013, is fully described in the June issue, now available for single-issue purchase or membership download. The following article excerpt provides a broad overview and a description of the team’s hardware choices.

THE BIG PICTURE
Figure 1 shows the bus tracker’s hardware, which consists of three components: the user’s smartphone, the base station placed at a fixed location on campus, and the mobile tracker that rides around on the bus.

The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Figure 1: The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Early on, we decided against a cellular-based solution (think cell phone) as the mobile tracker. While this concept would have benefited from wide-ranging cellular coverage, it would have incurred monthly cellar network access fees. Figure 1 shows the final concept, which utilizes a 900-MHz radio link between the mobile tracker and the base station.

Figure 2 shows the software architecture running on the hardware from Figure 1. When the user’s smartphone loads the bus tracker webpage, the JavaScript on the page instructs the user’s web browser to use the Google Maps JavaScript API to load the campus map. The smartphone also makes an XMLHttpRequests request for a file on the server (stamp.txt) containing the bus’ current location and breadcrumb index.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

This information along with data about the bus stops is used to position the bus icon on the map, determine the bus’ next stop, and predict the bus’ arrival time at each of the seven bus stops. The bus’ location contained in stamp.txt is generated by a GPS receiver (EM-408) in the form of an NMEA string. This string is sent to a microcontroller and then parsed. When the microcontroller receives a request for the bus’ location, it formats a message and sends it over the 900-MHz radio link. The base station compares the bus position against a canonical tour of campus (breadcrumb) and writes the best match to stamp.txt.

Early in the project development, we decided to collect the bus’ position and heading information at 2-s intervals during the bus’ campus tour. This collection of strings is called “breadcrumbs” because, like the breadcrumbs dropped by Hansel and Gretel in the eponymously named story, we hope they will help us find our way around campus. Figure 3 shows a set of breadcrumbs (b1 through b10), which were collected as the bus traveled out and back along the same road.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

The decision to collect breadcrumbs proved fortuitous as they serve an important role in each of the three hardware components shown in Figure 1.

MOBILE TRACKER
The bus houses the mobile tracker (see Photo 1). Figure 4 shows the schematic, which is deceptively simple. What you see is the third iteration of the mobile tracker hardware.

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

An important starting point in the design was how to step down the bus’ 12-V supply to the 5-V required by our circuit. In terms of hardware, the best decision we made was to abandon the idea of trying to integrate a 12-to-5-V converter onto the mobile tracker PCB. Instead we purchased a $40 CUI VYB15W-T DC-DC converter and fed the mobile tracker 5-V inputs…

We used Micrel’s MIC5205 regulator to step down the 5 V for the 3.3-V GPS receiver, which easily supplied its peak 80 mA. Since we ran a Digi International XTend radio at 5 V for the best range, we ended up with mixed voltage signals. We used a Texas Instruments TXS0102 bidirectional voltage-level translator, which handles voltage-interfacing duties between the 5-V radio and the 3.3-V microcontroller.

The mobile tracker unit

Photo 1: The mobile tracker unit

We selected Microchip Technology’s PIC18F26K22 because it has two hardware serial ports, enabling it to simultaneously communicate with the GPS module and the radio modem when the bus is traveling around campus. We placed two switches in front of the serial ports. One switch toggles between the GPS module and the Microchip Technology PICkit 3 programming pins, which are necessary to program the microcontroller. The second switch toggles between the radio and a header connected to a PC serial port (via a Future Technology Devices FT232 USB-to-serial bridge). This is useful when debugging at your desk. An RGB LED in a compact PLCC4 package provides state information about the mobile tracker.

The XTend RF modules are the big brothers to Digi International’s popular XBee series. These radios come with an impressive 1 W of transmitting power over a 900-MHz frequency, enabling ranges up to a mile in our heavily wooded campus environment. The radios use a standard serial interface requiring three connections: TX, RX, and ground. They are simple to set up. You just drop them into the Command mode, set the module’s source and destination addresses, store this configuration in flash memory, and exit. You never have to deal with them again. Any character sent to the radio appears on the destination modem’s RX line.

The GPS receiver utilizes the CSR SiRFstarIII chipset, which is configured to output a recommended minimum specific (RMC) string every 2 s…

The mobile tracker’s firmware listens for commands over the serial port and generates appropriate replies. Commands are issued by the developer or by the base station…

Burning breadcrumbs into the mobile tracker’s flash memory proved to be a good design decision. With this capability, the mobile tracker can generate a simulated tour of campus while sitting on the lab bench.

BASE STATION
The base station consists of an XTend RF module connected to a Raspberry Pi’s serial port (see Photo 2). The software running on the Raspberry Pi does everything from running an Nginx open-source web server to making requests for data from the mobile tracker.

From Figure 1, the only additional hardware associated with the base station is the 900-MHz XTend radio connected to the Raspberry Pi over a dedicated serial port on pins 8 (TX) and 10 (RX) of the Raspberry Pi’s GPIO header.

The only code that runs on the base station is the Python program, which periodically queries the mobile tracker to get the bus’ position and heading. The program starts by configuring the serial port in the common 9600,8,N,1 mode. Next, the program is put into an infinite loop to query the mobile tracker’s position every 2 s.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.