# Si5351A Investigations Part 5

The Si5351 library for avr-gcc that I’ve been promising for the last four posts is finally in a state where I feel comfortable releasing it, so I’ve posted it on GitHub. I think that the documentation posted on the README file and inside the code should be enough to get you going, but if you run into problems, please comment here or file an issue on the GitHub repository.

At this point it is very basic, but it will generate frequencies from 1 to 150 MHz on any of the three outputs of the Si5351A, and you can do stuff like turn the clocks on and off and change the drive strengths of the output drivers. More features will be added as time goes on, with the priority on things which will be needed to make a functioning amateur radio transceiver.

I’d like to point out something interesting that I’ve discovered about the parts that I’ve been working with. I ordered my Si5351A parts from Mouser (P/N 634-SI5351A-B02075GT). I never had any luck communicating with them on the datasheet-specified I2C address of 0x60; instead they need to be addressed at 0x6F. Thanks to the Bus Pirate and its built-in I2C address space scan macro, that didn’t take me too long to figure out. I just chalked it up to yet another datasheet error (the Si5351 is riddled with problems), but it turns out that I may actually have some defective or custom parts which shouldn’t have made it out to Mouser.

Over the last few days, I have been corresponding via email with Ian K3IMW, who has been having a horrible time getting his Si5351 to work. After he described his symptoms to me, I suggested that he try address 0x6F, and sure enough, that worked. What confounded him was that another ham he was in correspondence with was able to talk to the Si5351 using address 0x60. It turns out that those parts that work on 0x60 were from Digi-Key and both Ian and I obtained our parts from Mouser. So, the theory is that perhaps some custom parts accidentally made it out the door to Mouser. I will try to contact Mouser in the next day or two and see if perhaps they can get it straightened out with Silicon Labs.

The moral of the story to to pay attention to where you got your parts from if you are having problems with the Si5351. Once I can get my hands on some of the same P/N from a different vendor and can confirm that it does indeed work on address 0x60, I will make the change in the library. In the meantime, you may need to change that value yourself in the si5351.h file in order to get it working.

# Hi Juno!

As a world-class procrastinator, I know I’m very late with this post only about 12 hours before the event. However, I still wanted to share it with you in the hopes that maybe it could help one person.

As you may have heard, the Juno spacecraft will be making a close approach to Earth on 9 October 2013 as it slingshots to gain energy for the trip to Jupiter. The investigators who are in charge of a radio receiver on the spacecraft wish to see if they can detect intelligent life on Earth who may be transmitting on the 10 meter band. Therefore, they are asking licensed radio amateurs to transmit a slow-speed CW “HI” signal to Juno during a window at Juno’s closest approach. The full details are on the Hi Juno page (due to the US government shutdown, the primary page is offline, but the event is still planned to take place).

In order to be able to take part in this event without having to be right at the transmitter (I have to take care of my two toddler boys during the specified time period), I wrote a program in Python which will automatically transmit at the appropriate time. You just need a PC synchronized to NTP time, a 10 meter CW transmitter, a serial port, and a keying interface (which I will describe shortly). I plan to execute the program on my shack PC via SSH and monitor my transmissions on a portable receiver to maintain control of the transmitter.

Here is the simple keying circuit I use to key my Icom IC-718. It should work with just about any grounded keying transmitter, but as usual your mileage may vary. I use a DB9 female jack for the serial port. The RTS line is used to turn on a 2N7000 MOSFET, which will ground the key line in order to transmit. You can use any key jack that is appropriate for your transmitter. I use this circuit with a USB-to-Serial adapter, and it still seems to work fine.

The actual Python program to control the serial port keyer is found here at GitHub. You will need to have the PySerial module installed on your system, in addition to the regular Python installation. I’ve tested it here, but please be sure to test it yourself on a dummy load before using it on the air (you will need to temporarily change the START_DATE variable to an earlier time in order to get the program to transmit). You will also need to change the DEVICE, BAUD, and CALLSIGN variables to values appropriate for you. Linux/OS X users would change DEVICE to whichever “/dev/tty*” port is appropriate, where the * is your port numbe. Windows users would use “COM*”, where * is the COM port number. Sorry that I can’t hold your hand through this, but it should be fairly simple to get running. Linux and OS X users may also have to execute the program under sudo in order to access the serial port.

Please let me know if you end up using this, and don’t forget to request a QSL from Juno!

# Fancier Minecraft Pi Game of Life

I spiffed up my last bit of Minecraft Pi Edition code by making the Game of Life fit into a smaller area of the world, making the world grid and live cells easier to see (by making dead cells Obsidian and live cells Diamond Blocks), and even adding a nifty little stepped wall around the playing field. In the two photos, you can see the new Game of Life as seen from the ground inside of the playing field and hovering above it. It runs a fair amount faster now that it’s only updating a 64×64 grid. Still not going to break any speed records (even from 1980) but it’s a bit more fun to play with now.

# pilife.py
#
# Jason Milldrum
# 18 Feb 2013
#
# www.nt7s.com/blog

import minecraft.minecraft as minecraft
import minecraft.block as block
import numpy
import random

mc = minecraft.Minecraft.create()

# World size in x and z axes
#worldSize = 64

# Bounds of x and z axes
negLimit = -32
posLimit = 31

# Bounds of y axis
yNegLimit = -64
yPosLimit = 64

# Y coord of Life world floor
worldFloor = 0

# Number of steps in the surrounding wall
maxWallHeight = 5

# Initialize the Life world
theWorld = numpy.zeros((posLimit - negLimit + 1, posLimit - negLimit + 1), dtype=numpy.bool)
theNextWorld = numpy.zeros((posLimit - negLimit + 1, posLimit - negLimit + 1), dtype=numpy.bool)
for x in range(posLimit - negLimit):
for y in range(posLimit - negLimit):
theWorld[x][y] = random.randint(0,1)

# Clear everything at the world surface and above inside the Life play area
mc.setBlocks(negLimit - (maxWallHeight * 2), worldFloor, negLimit - (maxWallHeight * 2), posLimit + (maxWallHeight * 2) - 1, yPosLimit, posLimit + (maxWallHeight * 2) - 1, block.AIR)

# Let's create stairsteps around the Life world

x = posLimit
stepHeight = worldFloor
# Up
while stepHeight <= maxWallHeight:
mc.setBlocks(x, worldFloor, negLimit - stepHeight - 1, x, stepHeight, posLimit + stepHeight, block.BEDROCK)
x += 1
stepHeight += 1
# Down
stepHeight = maxWallHeight
while stepHeight >= worldFloor:
mc.setBlocks(x, worldFloor, negLimit - stepHeight - 1, x, stepHeight, posLimit + stepHeight, block.BEDROCK)
x += 1
stepHeight -= 1

# Now the -x direction
x = negLimit - 1
stepHeight = worldFloor
# Up
while stepHeight <= maxWallHeight:
mc.setBlocks(x, worldFloor, negLimit - stepHeight - 1, x, stepHeight, posLimit + stepHeight, block.BEDROCK)
x -= 1
stepHeight += 1
# Down
stepHeight = maxWallHeight
while stepHeight >= worldFloor:
mc.setBlocks(x, worldFloor, negLimit - stepHeight - 1, x, stepHeight, posLimit + stepHeight, block.BEDROCK)
x -= 1
stepHeight -= 1

# Next the +z direction
z = posLimit
stepHeight = worldFloor
# Up
while stepHeight <= maxWallHeight:
mc.setBlocks(negLimit - stepHeight - 1, worldFloor, z, posLimit + stepHeight, stepHeight, z, block.BEDROCK)
z += 1
stepHeight += 1
# Down
stepHeight = maxWallHeight
while stepHeight >= worldFloor:
mc.setBlocks(negLimit - stepHeight - 1, worldFloor, z, posLimit + stepHeight, stepHeight, z, block.BEDROCK)
z += 1
stepHeight -= 1

# Finally the -z direction
z = negLimit - 1
stepHeight = worldFloor
# Up
while stepHeight <= maxWallHeight:
mc.setBlocks(negLimit - stepHeight - 1, worldFloor, z, posLimit + stepHeight, stepHeight, z, block.BEDROCK)
z -= 1
stepHeight += 1
# Down
stepHeight = maxWallHeight
while stepHeight >= worldFloor:
mc.setBlocks(negLimit - stepHeight - 1, worldFloor, z, posLimit + stepHeight, stepHeight, z, block.BEDROCK)
z -= 1
stepHeight -= 1

# Set the player right in the middle of the world
mc.player.setPos(0, worldFloor, 0)

# Main processing loop
while True:
# Display theWorld
for x in range(posLimit - negLimit):
for y in range(posLimit - negLimit):
if theWorld[x][y] == True:
mc.setBlock(x + negLimit, worldFloor, y + negLimit, block.DIAMOND_BLOCK)
else:
mc.setBlock(x + negLimit, worldFloor, y + negLimit, block.OBSIDIAN)

# Check number of neighbors alive
for x in range(posLimit - negLimit):
for y in range(posLimit - negLimit):

if x == 0:
xMinus = posLimit - negLimit
else:
xMinus = x - 1

if x == posLimit - negLimit:
xPlus = 0
else:
xPlus = x + 1

if y == 0:
yMinus = posLimit - negLimit
else:
yMinus = y - 1

if y == posLimit - negLimit:
yPlus = 0
else:
yPlus = y + 1

alive = 0

if theWorld[xPlus][yPlus]:
alive += 1
if theWorld[x][yPlus]:
alive += 1
if theWorld[xMinus][yPlus]:
alive += 1
if theWorld[xPlus][y]:
alive += 1
if theWorld[xMinus][y]:
alive += 1
if theWorld[xPlus][yMinus]:
alive += 1
if theWorld[x][yMinus]:
alive += 1
if theWorld[xMinus][yMinus]:
alive += 1

# Calculate which cells live and die in next generation
if theWorld[x][y] == False:
if alive == 3:
theNextWorld[x][y] = True
else:
if alive < 2:
theNextWorld[x][y] = False
elif alive > 3:
theNextWorld[x][y] = False
else:
theNextWorld[x][y] = True
# Copy array
theWorld = theNextWorld.copy()

# Conway’s Game of Life in Minecraft Pi Edition

Also known as “The slowest implementation of the Game of Life in 2013”. This is what happens when you have insomnia.

What I did was first clear out the entire world, then place a plane of glass across the entire world at y=1. The actual Life cells are Cobblestone blocks on the y=0 plane (the grid is on the Minecraft x-z axis). The Life grid is initialized with a random seed, then set off to work. This code for the Game of Life is about the dumbest and slowest implementation there is. I’ve done no optimization at this point. It only updates about one generation (over the entire world) every few minutes. But it does seem to work, as you can see above.

Next time I need a break from electronics, I’ll refine the code and post it again (or you can follow the Gist). It’s way too slow to run the entire world as a Life simulation, so I think I’ll just clear out a 64×64 space in the middle of the world and confine the world to that size, which should make things run about an order of magnitude faster, I would hope. I know, this is crap code, but I’m still trying to really get into the Python frame of mind and this was a quick hack any way.

I’ll let this thing run for a while and post a screenshot of the evolved world to Twitter and G+ later on. Also, thanks to the shoutout from the new http://mcpipy.wordpress.com/ blog!

# Exploring Minecraft Pi Edition

If you are a Raspberry Pi enthusiast, you may have seen that Minecraft Pi Edition was officially released yesterday. I don’t have the time to game like I used to, so I haven’t really played Minecraft, but this version looked intriguing since it’s free and it has an open API. So I downloaded it yesterday during a break when both of the boys were napping and give it a quick run. The performance of the game is surprisingly responsive, which shows that the GPU in the Pi is fairly capable, even if stock Raspian X Windows is slow.

With a bit of digging into the very sparse API docs included with the program, and a little Internet help, I was able to get a bit of code up and running. All it does is create a sphere 10 blocks away from the player’s location in the Z direction. Here’s the quick and dirty code:

You can see the results in this photo:

Pretty fun stuff, even if it’s very basic. I know that the hardcore MC fans have already been scripting some pretty fantastic stuff in the PC version. It should be interesting to see what people do with the Pi version.

A few quick updates to the avs3a software that I’ve writting for the Avnet Spartan-3A Eval Kit (as mentioned in a previous post). First, many thanks to George Gallant from the Avnet Spartan-3A Eval Kit mailing list for rewriting the code to fix the horrible configuration time, as well as for the many error checking and usability improvements. Secondly, I’ve taken the latest version of George’s code revision and uploaded it to a new Google Code site, where it will now be hosted. Go there for the latest download of the project tarball or to check out your own copy from Subversion.

# Configuring the Avnet Spartan-3A Eval Board on Linux (Alpha)

As I mentioned on the Avnet Spartan-3A Eval Kit Google Group, I’ve created a C program that will allow you to configure the FPGA via your Linux box. I don’t have a lot of time to elaborate on how to use this program, but the basic steps are listed below. These instructions assume that you are at least moderately familiar with using the shell in your distribution and building a program from source code. This code is in an alpha state and I have only tested this on my Ubuntu Hardy Heron box, so your mileage may vary. I’m sure there’s much I can do to improve it (clean up, refactor, etc.), but it seems to do what it needs to for now.

Right now, the program is controlled by three command line switches. I’ve created these options with a mind for expansion in the future (at least the serial flash part). Here’s the help printout from the program:

Usage: avs3a [options] Options: -b, --bitstream=BITSTREAM Bitstream used to configure FPGA -p, --port=SERIAL-PORT Serial port connected to eval board -s, --slaveser Configure FPGA in Slave Serial mode
2. Unpack the archive in the location where you intend to use the program.
tar xzvf avs3a.tar.gz
3. Change to the avs3a directory.
cd avs3a
4. Build the program from source.
make all
5. Make sure that your eval board is plugged into a USB port.
6. If you don’t know the serial port of the eval board, then find it. I’m not sure what you will see, but on my Ubuntu Hardy box, my board enumerates as /dev/ttyACM0 or /dev/ttyACM1
dmesg | grep tty
7. Make sure you have a bitstream file to use.
8. Issue the command to program the board
./avs3a -s -p /dev/ttyACM0 -b sample_bitstream.bit

If you try this and find it useful, or find a problem with the program then please, please, let me know in the comments below (or e-mail me). Thank you for testing this!

Coding

# Learning DSP Concepts with BasicDSP

Completely by accident, I happened to stumble upon a program that gives you an easy way to learn DSP techniques by focusing on the underlying algorithms and not the hardware details. The program is called BasicDSP and is available as a Linux source tarball or Windows executable. BasicDSP was created by PA3FWM and PE1OIT as a tool to allow you to experiment with signal processing algorithms from basic building blocks such as filters and mixers, up to complete receiver systems in code. The program can take its input from a variety of sources, such as the soundcard, a file, or an internally generated signal. A simple scripting language is then used to manipulate the input data using a variety of DSP techniques (including some built-in functions). The resulting audio is them piped back out to the soundcard, as well as optional spectrum and oscilloscope displays.

The source tarball didn’t want to compile on my Ubuntu Hardy machine on the first try. It threw some cryptic errors about some of the wxWidget objects in the code. A bit of Googling and some lucky guessing enabled me to figure out that the code wanted to compile with wxWidgets 2.6, not the version 2.8 that is standard on Hardy. I forced the linker to use 2.6 and managed to get the code to compile (although it was still complaining about a few warnings). Once I got over that speed bump, the program seemed to work as advertised, with one exception. As you can see in the attached screenshot, something is seriously wrong with the spectrum display. For some reason, the program is drawing vertical lines across the entire spectrum where there should be nothing. Since I had access to the code, I thought that maybe I would give a shot a locating any glaring problems that might be causing this. I know a bit of C++, but have very little experience in coding for *nix machines, and know virtually nothing about wxWidgets. However, the code to draw the spectrum display seemed fairly obvious and I couldn’t find anything wrong with it. You can still see a signal on the display if you look hard enough, but its very difficult to tell with all of the offending vertical lines. My best guess is that something is wrong in the array which holds the FFT data plotted by the spectrum display, but that’s only a guess. I just don’t have the expertise or the proper tools to properly debug this type of problem.

Ignoring that flaw, this is otherwise a really neat program. The syntax is very simple and allows you to easily try different processing concepts in just a few lines of code. There are two special variables that get used in every script: in and out. The in variable represents the data flowing into BasicDSP from the chosen source, while out is the variable that you send your processed data to in order to output it to the speaker. The simplest script that you can write for BasicDSP is a passthrough function, where no processing of the data is performed:

out = in

In the above example, each sample is directly passed to the output. If you could not hear the output very well, you can amplify the signal by performing multiplication with a constant.

out = in * 100

By multiplying the sample by 100, you are increasing the signal level by 40 dB.
$$!20\ \log\ 100 = 40\ \text{dB}$$

There are four slider controls which are accessible via variable (slider1slider4). These allow you to dynamically alter variables in the script. For example, if you wanted to be able to change the signal level with a slider, it’s a simple as:

out = in * slider1

There are other special variables and functions included in the scripting language that help to enable common DSP tasks. These can all be put together to create simple circuit blocks like low-pass filters, up to more complex tasks like quadrature receivers. A basic direct conversion receiver can be put together quite simply using these functions. The following code (taken from a reprint of a SPRAT tutorial) implements the DC receiver in code by creating a sawtooth oscillator (in lines 2 & 3), mixing the input signal to baseband (just a simple multiplication at line 4), then sending the signal through two stages of low-pass filtering (lines 5 & 6).

1 2 3 4 5 6 7 samplerate = 48000 sawtooth = mod1(sawtooth+slider1) osc = sin1(sawtooth) mix = osc * in lpfa = lpfa + slider2*(mix-lpfa) lpfb = lpfb + slider2*(lpfa-lpfb) out = lpfb

There’s some more information on the program and some good example code on the website of PE1OIT. If you have even a small bit of interest in the inner workings of a SDR receiver, you owe it to yourself to download this software and try it out.

# Programming AVR Microcontrollers in Eclipse

Lately, I have been using my Ubuntu Hardy Heron box for coding and programming my AVR projects using the simple combination of gedit, the avr-gcc toolchain and the USBtinyISP. It’s a little bit of a pain to get set up correctly, but it works very well once it’s up and running. I’ve been pretty happy with editing code in gedit then compiling and programming the AVR via command line. It’s pretty easy to quickly make changes to the code and save the C file in gedit, then use the command history of the terminal to re-run make and avrdude.

However, I recently ran across this posting when browsing the AVR Freaks forum. The author kindly gives instructions on how to set up the Eclipse IDE for use in AVR development on the Ubuntu platform. This looked really promising, since I’ve always been a sucker for nice IDEs (yes, I know that probably lowers my geek cred a few notches). So I gave it a go and found that the instructions worked nearly flawlessly. The only hiccup I encountered was at the very end of the build process when Eclipse was waiting for the sudo password for avrdude (oddly enough, you have to run avrdude as root to access the USB programmer, unless you implement a little workaround that I’ll show you in a second). I didn’t see any way to enter the root password into a terminal, so I had to cancel the whole process.

A bit of thought and much more searching brought me to the answer to the problem. There is a way to get non-root access to the USBtinyISP. You have to create a udev rule to tell the kernel to change permissions on the USBtinyISP. The documentation on the ladyada website tells you to do this, but it only gives you half of the story. First of all, it doesn’t mention exactly where to place the new rule that you are creating. Her documentation stated that I needed to put the rule in a file in /etc/udev/rules.d/. The problem is that this doesn’t state whether I need to place the rule in an existing file or create a new one. After a bit of trial-and-error and yet some more Google searching, I found out that I needed to create a new file for the USBtinyISP. So a new file named 50-usbtinyisp.rules was created. The other problem is that the actual rule given on the ladyada site seems to have a typo in the MODE parameter. Comparing this rule to some other rule examples, it appears that the correct rule is:

SUBSYSTEM==”usb”, SYSFS{idVendor}==”1781″, SYSFS{idProduct}==”0c9f”, GROUP=”users”, MODE=”0666″

Once you get the udev rule set up correctly, you no longer need root to access the USBtinyISP, and the entire build process in Eclipse works flawlessly.

So far, using Eclipse as an AVR development platform has been a real pleasure. There’s a lot of nice little touches, like having quick access to all of the special function registers of each device and easy configuration of the build parameters via GUI. If you are like me and like the convenience that an IDE gives you, then the AVR/Eclipse environment is an excellent choice, and may even be better than WinAVR.