Tag Archives: raspberrypi

ITEAD PN532 NFC Module and RaspberryPi via I2C and Java

In my last post I explained how I got the ITEAD PN532 NFC Module up and running with a RaspberryPi by using plain Java code with pi4j and SPI as an interface for communication.

However, for a different idea, I needed the SPI interface to be available completely, and that meant that I must somehow change the implementation for the NFC module. One option is to use I2C as an interface and to adapt the hardware and the software to use it instead.

The ITEAD PN532 NFC Module, has only the SPI pins connected at the RaspberryPi connector. I believe this is some compromise that the guys at ITEAD must have did. However, the PN532 supports SPI, I2C and Serial, and all these interfaces can be accessed through the other connector, having in mind that they share the same pins.

In order to achieve I2C communication with a RaspberryPi, the following steps need to be made:

1. Change the switches on the NFC module to indicate that I2C will be used: SET0 set to H and SET1 set to L.

2. The I2C pins need to be rewired manually to the I2C pins of the RaspberryPi connector. My gruesome workaround is this:

itead back rewire

3. The SPI pins of the RaspberryPi connector are still conected to the same shared pins, and with the rewiring, the I2C and SPI are interconnected and they won’t be functioning properly. To avoid this, the SPI pins need to be removed. Again, my workaround by cutting the 5 pins from the connector:

itead front rewire

As of now, the device is ready to work with I2C. In order to test it, you can use the libnfc as described in this ITEAD studio blogpost. (see from number 8 onward).

The final step was to make all this functioning with Java code. For that, I extended my library by porting the elechouse PN532 implementation for I2C to Java with pi4j. After some struggle with the proper API usage, the implementation got quite clean. It is already added in the same project at GitHub.

As of this point, since I got everything working, my idea is to resume with this projec, port the whole PN532 implementation to Java, and making the API more clear to use. That I will cover in a future blog post.

NFC with RaspberryPi and Java

For a presentation I did, I needed to come up with a neat example of directly connecting a RaspberryPi with some add-on device. The ITEAD PN532 NFC Module looked perfect for this case, and I started working with it. My end goal was to operate it with Java code.

RaspberryPi with ITEAD PN532 NFC Module
RaspberryPi with ITEAD PN532 NFC Module

The ITEAD blog has a nice example plus a library done in C for interfacing the NFC Module.  It uses the SPI interface and operates on a low level by using the WiringPi library.

The pi4j library is a JNI to the WiringPi C library, so in basic terms it should be able to do the same thing.

I started by porting an Arduino code first (github link) and using the Serial interface for communication, but I failed. Then I started porting the ITEAD provided library and used the SPI interface as in the original code. After some struggle, I managed to devise some working code: https://github.com/hsilomedus/raspi-pn532


  • there are two interface implementations: PN532Spi and PN532Serial. The second one is marked as @Deprecated because it’s not functioning for some reasons
  • the SPI implementation at the moment can only get the firmware version and read the passive target id of an NFC tag. Hopefully I’ll implement the other functions soon.
  • before using the SPI interface, make sure that it is enabled. See the notes in the ITEAD blogpost and in the github repo readme.
  • when starting the example, execute java with sudo in order pi4j to work properly.

Overclocking the Raspberry Pi with OpenELEC

The Raspberry Pi, if limited only to rendering HD videos, handles the job quite nice. The hardware accelerated video playback makes things run smooth.

However, if you’re using some software like xbmc, or the complete solution with OpenELEC, then the navigation and everything else can get sloppy.

A nice way to speed things up there, and make the navigation smoother, is to overclock the Pi.

Along with some new firmware versions, the configuration file comes with some suggestion presets as options for boosting the Pi. With them, the arm, core and the memory frequency can be increased, and also the overvolt option.

Increasing the frequency or the overvolt parameters will inevitably increase the thermal output of the device. Now this can still be in acceptable limits, but if the pi is being used a lot in a prolonged period, it can become either unstable or freeze.
To be on the safe side, I recommend that you purchase some thermal sinks and stick them to the important chips on the board. I bought these from dx.com, and they are working just fine.

RasPi_sinksThe easiest way to do the overclock is to use your PC. Insert the SD card in the SD card reader, and open it to view its contents. Find the file named ‘config.txt’ and open it with a text editor.

Somewhere in it, you can find the following lines (or similar):

The Modest, Medium, High and Turbo are the suggested presets which, allegedly, have been tested. In order to use one, uncomment the four overclocking values, and insert the ones from the preset. I jumped directly to the last one, so my config at the end looked like this:

Note 1: the sdram_freq have been said that should be configured to 600 for the Turbo mode. Some users have reported SDcard corruption when said to be 500. I haven’t tested this out yet.
Note 2: leave the force_turbo=0. This means that the device will dynamically increase and decrease the frequency based on the load. This can prolong your Pi’s life, and will probably prevent some corruptions happening. Forcing the turbo mode uses the overclocked values as constants, but also voids your hardware warranty.

After editing the config.txt file, save it, and put the SD card back to the Pi and boot it. The system should now run with the changed settings.

Since the force_turbo option remains zero, the CPU frequency changes, and some tools will still report the same 700MHz. If you make some heavier load, this will change though. After some playing around, I snapped this:

RasPi_openelec_clockedAfter the overclocking, I got some very noticeable improvements in the xbmc navigation. Stuff started to move smoother. It’s still not perfect, but it’s much more manageable now.

Also, the thermal sinks seem to be really needed. The one on the cpu seems was quite hot after having the Pi run for about three hours.

pi4jmultimeter: Raspberry Pi + Arduino + d3js electrical multimeter

As a fun project and as an example for my recent talk at the Jazoon conference, I’ve made this device. I call it my pi4jmultimeter.

 What it does its some basic electrical multimeter features:

  • DC voltage measurement
  • AC waveline preview
  • AC spectrum analysis
  • Electrical resistance measurement

The device is a combination of a Raspberry Pi and an Arduino. The Arduino does the analog readings and uses Fast Fourier Transformation for producing the spectrum graph data. The Raspberry Pi hosts the main process and runs a lighttd web server. Both devices are connected with their extension headers (Raspberry Pi’s GPIO and Arduino’s Vin, GND and serial port pins) and have a paired serial port interface. The end result is visualized in a JavaScript web application which renders optimized d3js animated SVG graphs.

The Arduino loops a program which does simple analog reads on three inputs, periodical FFT and sends all this data to the Raspberry Pi via the serial interface. The Raspberry Pi, has a running Java8 SE Embedded process based on the pi4j and Java WebSocket libraries. It reads everything from the serial port with the help of the pi4j library, packs everything in a nice JSON format and broadcasts the data to every opened WebSocket connection by the use of the Java WebSocket library.

The whole source code with the build instructions can be found on GitHub: https://github.com/hsilomedus/pi4jmultimeter
The slides of my presentation are available at the jazoon guide webpage:  (or directly at slideshare)

The d3js graphs can be observed and used individually. All the graphs populated with some random data can be found here:


Media center with OpenELEC and RaspberryPi

For some time I’ve been trying to get some nice home media center setup. The conditions were simple: local storage (external hard drives), xbmc, HD output (720p) and smooth running xbmc instance.

I’ve tried three options: Jailbroken AppleTV2, full-fledged PC running Ubuntu and last but not least, Raspberry Pi with an OpenELEC image.

The AppleTV2 is a very neat device, compact, lovely remote, HDMI output, ethernet connection and low power consumption. The jailbraking procedure is a bit tricky, can fail for some times, but with properly following the instructions, you’ll get the job done. Xbmc runs quite smoothly, and the installation places it on the home menu. At first, the setup was nice, and the rendered videos seemed OK, but then the harsh truth came visible: the AppleTV2 has hardware support for decoding x264 videos, and that’s it. The performances with everything else were simply not acceptable: lags, cuts, freezes. Verdict: not for usage.

The PC option worked very as expected: dual core processor capable of processing HD videos of any kind, enough processing and networking power for smooth operation and communication, strong display card with digital output (DVI) and more than enough sockets for connecting external and internal storage. However, I struggled a lot with the fan noise, and after trying several (expensive) options, I gave up. No matter how quiet the fans are, the silent buzzing will start to get on your nerves, and will kill the experience you want. Verdict: smooth, but not neat.

The third option was very underrated at the beginning. The RaspberryPi with its very limited processing power, storage and memory seemed like very unsuitable device for the task. However, I did some research and gave it a try. The facts that made it look promising and started to change my initial impressions were:
– it has hardware support for decoding x264 and MPEG4 videos, the two most likely codecs used in today’s ripped movies and videos.
–  xbmc has an option for bypassing DTS and AAC audio to the TV via HDMI. This way, the RaspberryPi won’t bother with decoding the audio, and most of the digital TVs today on the market have this feature.
– the HDMI output is CEC capable, which means that if the TV is also suitable, you can control the device via your TV remote.
– external drives can be mounted via the USB ports. Not directly at least, but with a self-powered USB hub, there’s no problem.

So I purchased a RaspberryPi (Model B, rev. 2, about 65 euros with a case) and the fun has begun. On the search for ideal OS, I rejected the Raspbian Wheezy at the start because it’s too generic, and I started looking for specialized media center OS. The wiki on xbmc.org site has some detailed explanations. The options were Raspbmc, XBian and OpenELEC. After some searching, I got to the impression that OpenELEC is the one that is most accepted by the community so I gave it a try.

OpenELEC is a small linux distro that makes your computer/device a compact media center running xbmc. The best installation procedure I could find is: download an image from here and follow the instructions here. In simple terms, you need:
– RaspberryPi Model B rev.2
– HDMI cable, Ethernet connection
– nice TV
– around 1A 5V MicroUSB power source
– self-powered USB hub
– the OS image file (.img)
– image file to SD writing software (Win32 disk imager for example)
– SD card (preferably 8 GB, just in case)

Unpack, write, insert the SD card in the RaspberryPi, connect, plugin.

The first boot as I noticed is a bit slower than usual, but successful. After some time, I got the xbmc home screen. Now, the xbmc performance in terms of navigation, processing, etc… is … well, not good. It can be slow, laggy, but eventually it will do what you have requested, so have some patience. Take some time to finalize the configuration: audio bypass, CEC settings (for the TV remote), remote control (if you wan’t to control the xbmc from other devices and software like Constellation or Yatse, media content directories (plugin the external storage, OpenELEC mounts it automatically), movies search and cache, etc …

If you finished everything fine, you’ll have a compact and well connected media center which you can control via your remote or a phone/tablet in the same network. The video performance is excellent, and so far I haven’t run into any rendering issues in neither x264, DivX or Xvid movies in 720p. Supposedly it can render 1080p without issues, but I didn’t wan’t to challenge it to this level, and also, the difference when considered my TV size is not noticeable at all.

– use proper images, don’t take night builds since they will not update correctly.
– use a remoting device if possible. It makes the browsing and searching possible and tolerable , since the built one is quite slow.
– correct the CEC settings regarding turning on and off actions. Once you ‘turn off’ the device, you have to power off/on again in order to turn it back on.
– ALWAYS use self-powered USB hub, cause if the device draws too much current, it may burn the RaspberryPi.
– don’t use the BerryBoot option with OpenELEC. It’s just not good.