### Circuit Diagram:

Circuit Diagram

The biased signal generator signal is connected to AnalogIn 1 on the Tiva C which is pin PE_2. Signal Gen and Tiva C ground is common. The two 10k resistors from a voltage divider which will halve the 3v input to give a 1.5 v bias. The signal from the signal generator will be 3V peak to peak meaning that now the signal will vary from 0v to 3v using all of the ADCs available range. It’s probably a good idea to add a small capacitor in between the signal generator and the voltage divider to prevent the DC flowing through the signal gen. A 1Khz sample rate means that the highest frequency that we can reliably analyse is 500Hz. This comes from the the nyquist sampling theorem.

### Code:

The Energia IDE was used to write and compile the code which runs on the Tiva C. See below for the code:

The reason the code is so short is because all of the fft code is contained in fix_fft.h which is a c implementation on the fft which has been around for over two decades. It was first written by a person called Tom Roberts in 1989 and a google search of “fix_fft.c” will return many mirrors of this code available for download. the fix in “fix_fft.c” refers to the fact that it uses fixed point short integers as opposed to floating point numbers which will result in a loss of accuracy in the fft but a faster execution time.

Here is the python script used to plot the fft data:

```#python script to read 64 bytes of data from tiva C and plot them
#using pyQtGraph on a loop. As soon as 64 bytes arrive plot is updated

from pyqtgraph.Qt import QtGui, QtCore
import pyqtgraph as pg
import pyqtgraph.exporters
import numpy as np

import serial

ser = serial.Serial(
port='COM4',
baudrate=115200,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=1
)

ser.close()
ser.open()
print (ser.isOpen())

data = np.zeros(64)

app = QtGui.QApplication([])

p = pg.plot()
p.setWindowTitle('FFT')
p.setLabel('bottom', 'Index', units='B')
curve = p.plot()

def update():
global curve, data,
if(ser.readline() == b'*\n'):   # "*" indicates start of transmission from tiva c
for h in range(63):
try:
data[h] = int(ser.readline())  #get 64 bytes from tiva c and plot them
except:
pass
curve.setData(data)
app.processEvents()  ## force complete redraw for every plot

timer = QtCore.QTimer()
timer.timeout.connect(update)
timer.start(0)

## Start Qt event loop unless running in interactive mode.
if __name__ == '__main__':
import sys
if (sys.flags.interactive != 1) or not hasattr(QtCore, 'PYQT_VERSION'):
QtGui.QApplication.instance().exec_()
```

#### Displaying Inkscape images on the LEGO NXT brick with LeJOS

If you are new to using inkscape then maybe check out their tutorial page to get started drawing basic shapes.

This is what it looks like when you open up inkscape:

The default page size when Inkscape is started up is a4. To make our lives easier, we can change the page size to match the screen size on the lego NXT brick. The bricks LCD is 100×64 (100 pixels wide, 64 high). To change the page size click File > Document Properties. This will open up a new window. Under the ‘page’ tab enter the custom width and height as shown below. Check to make sure that the units are px and not something else like mm.

Now the page should look something like this:

Everything is now set up to start drawing so fill the page with whatever you want! Hopefully it’s better than what I did :

Before exporting the picture there is an important step to ensure that the image displays correctly on the NXT brick. The background colour of the image looks white but it is actually undefined or blank. This will cause it to be displayed as black on the NXT brick resulting in just a black square being displayed. To make the background white click File > Document Properties and once again a window will pop up. Under the page tab, click the rectangle beside “Background Colour” and under the RGB tab, make sure all values are 255.

We are now ready to export the image as a PNG file. To do this click File > Export PNG Image. To display this image on the NXT using lejos we first have to convert it to a format it can work with. Lejos comes with a tool called nxjimage. This is a little gui that will let you import an image and export it in the proper lejos format. The nxjimage tool can be found in the lejos installation directory in the bin folder.

This is what the nxjimage gui looks like:

To import the png file created in Inkscape click Image > Import Image. Then navigate to wherever you saved the file.
The export the file in the native lejos format click Image > Export LeJOS NXT Image File

Now to upload the image to the NXT brick. This can be done in terminal presuming you have lejos added to your path.
The following command can be used to upload the image. (the image name is test.lni)

Now all that’s needed is a LeJOS program that will run on the NXT and display the image file we just transferred. See below for some example code:

```//lejos program to display images stored on nxt brick
//will display image until button is pressed
//wattnotions 31/5/2015

import javax.microedition.lcdui.Font;
import javax.microedition.lcdui.Graphics;
import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.Sprite;
import lejos.nxt.*;

import lejos.nxt.Button;

import java.io.File;
import java.io.FileInputStream;

public class GraphicsSample {
final int DELAY = 4000;
Graphics g = new Graphics();
final int SW = LCD.SCREEN_WIDTH;
final int SH = LCD.SCREEN_HEIGHT;

void fileImage(String picname) throws Exception
{

Image img = Image.createImage(new FileInputStream(new File(picname)));
g.drawRegion(img, 0, 0, SW, SH, Sprite.TRANS_NONE, SW / 2, SH / 2, Graphics.HCENTER | Graphics.VCENTER);
Button.waitForAnyPress(DELAY);
}

public static void main(String[] args) throws Exception {

GraphicsSample sample = new GraphicsSample();
sample.fileImage("test.lni");
Button.waitForAnyPress();
}
}

```

This LeJOS program can be compiled using this command:

nxjc GraphicsSample.java

to upload it to the NXT:

nxj -r GraphicsSample

### Bonus Pics:

r2d2

dragon

#### sure electronics LED dot matrix HT1632c Energia example

32×8 LED dot matrix display

This LED array has been sitting in my room for months now so I decided to hook it up to an msp430g2553 and get it displaying stuff. I bought it from ebay from a chinese supplier called sure electronics. The array is controlled by a ht1632c led matrix driver chip and the interface required is clocked serial data which I wrote in software for the msp430. There are arduino libraries out there for interfacing with this driver chip and I used them as a reference when putting this together. Right now all I have working is initialising the driver chip and writing data to its ram to display various patterns. The leds are mapped directly to the ht1632c ram. i.e. if you write a ‘1’ to a certain memory address that led will come on and writing a ‘0’ will turn it off. The chip has some other cool features like 16 level PWM dimming also. Only 4 wires (plus Vcc and GND) are needed to interface with the led array. The four wires are DATA, WR(clock), CS (this pin is pulsed to switch between read,write and command modes on the ht1632c) and the RD pin which is the data out from the ht1632c. This data out could be the contents of the RAM so you could find out which leds are on. I didn’t use this pin at all so it’s really only 3 wires which is pretty handy. These LED array boards can be chained together up to a max of 4. Right now I only have one so the code written is meant to just control one chip. That being said it shouldn’t be too much hassle to get it working with several boards at once.

Here is the code I wrote using the Energia IDE :

If you connect the LED array using the same pins I’ve defined for DATA, WR and CS it should work right away displaying the twitter logo scrolling across the screen. Here is a picture of it displaying a speaker of some type:

led array displaying speaker

If you’re interested in displaying text then check out this really extensive arduino library for the ht1632c.

#### RoboSlam robot design disussion #2

The breadboard fits in sideways pretty well. The earlier version on the robot (ted gave me his) doesn’t have enough space to slide in the breadboard with the rangefinder attached. The updated version has enough space to slide the breadboard in and out with the rangefinder attached which would save the hassle of plugging it in through the window. Also, the rangefinder fits in the “third wheel” window quite nicely as it is. Let me know if you still want to design it with two holes for the rangefinder to look through and I will measure out the dimensions or we could leave it as is.

rangefinder fits through window quite nicely

The battery pack fits in behind the breadboard perfectly in this configuration and it balances out the weight. The downside with having the breadboard rotated is that the window is far less useful with only around half of the board accessible. Kevin mentioned that it would be preferable to mount the battery pack underneath the chassis. In this configuration the battery pack could be easily zip tied to the underside without getting in the way of the breadboard.

side view of the rangefinder and battery pack

here is a pic of the added holes to zip tie the battery pack to the underside of the chassis:

See below for a drawing with dimensions of where the holes/slots should go. The drawing is pretty unclear so just to clarify where the holes should go: to position the bottom two holes move 10mm in towards the centre of the bot from the bottom of the biggest slots. The top two holes are 15mm away from the nearest two sides. You could put slots in these positions instead of holes (slots might be better for zip ties) . A good slot size to use would be the same size as the ones used for the “third wheel”