Monday, January 23, 2012

Falcon Project

Sorry for the lack of updates here, folks. I've been very busy with a project which is big enough to have it's own blog, restoring my Mutoh Falcon Outdoor 48. I'll update this with interesting projects from time to time, but for now, my main focus is getting this thing working.

Check out all the posts and tons of photos over at

Wednesday, November 23, 2011

Battling tftpd

*Update!* If you are using this to actually host configs for IP phones that will be used on a live network, I strongly suggest using atftpd instead.
Atftp does not have these odd file permission issues that plain tftpd does (i.e. once a file is created (such as a log file from a phone) by tftpd, it cannot be overwritten for some crazy reason.) Most IP phones store their configurations on the server, and if they cannot write them down after the first time, users (and you!) will not be happy!

Alright so this new job has got me documenting everything the minute I do it, so that I know what the hell to do the next time something happens.

So, this time? It's something I'm doing for myself.

Installing at tftp server in Ubuntu.

I know it sounds stupid, but every tutorial is from 2005 and none of them work on the current version of Ubuntu nowadays. If you want a working tftp server, here's how you do it:

Install the tftpd program. This will also install xinetd, which is how it's started. inetd starts xinetd, who then starts tftpd. I know, dumb, but that's how it works.

$ sudo apt-get install tftpd

Next, we need to set up the file that xinetd will read when it starts tftpd.

$ sudo nano /etc/xinetd.d/tftp

Put this stuff inside it:

service tftp
socket_type = dgram
protocol = udp
wait = yes
user = (change this to your username)
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
per_source = 11
cps = 100 2
disable = no

Now, we need to make a directory that this thing will use to put/get files out of. It's commonly right in the root.

$ sudo mkdir /tftpboot

Make that directory readable/writable by your user

$ sudo chown youruser:youruser /tftpboot

$ sudo chmod -R 777 /tftpboot
(this step is required, so that new files created are able to be overwritten.)
Now things should be cooking. Let's try starting tftp.

$ sudo service xinetd restart
* Stopping internet superserver xinetd                                  [ OK ]
* Starting internet superserver xinetd                                   [ OK ] 

If things are NOT ok, then you need to check the logs. Xinetd dumps it's goodies in the syslog (/var/log/syslog). Tail that logfile (tail -f /var/log/syslog) in another console/terminal while you restart and you'll see what's going on.
In my case, I didn't have the user specified correctly, in which case xinetd just doesn't start tftpd.

Now, you should have tftpd running. Look for the open port on the machine, owned by xinetd. This process will be run by the system, so use lsof to check:

$ sudo lsof -i | grep tftp

You should get a line back like the following:
xinetd      942     root    5u  IPv4 5132137      0t0  UDP *:tftp

This means you're up and running! Try pointing something at your tftp server and see if you can get/put files. (Cisco switches, IP phones, etc)

If it fails, check the permissions of your chosen directory, and check syslog for errors. I've seen it noted that adding -v to the options in the tftp file (server_args = -v -s /tftpboot) will make it more verbose, but all I get with that is lines in syslog saying "invalid argument - ?"

Friday, August 26, 2011

Playing with Fritzing

So I've been looking at various chips to use for memory, and they all seem to be pretty much the same, so I decided to take one and start designing for it. I started playing around in Fritzing, making a simple schematic with just the micro and the SRAM to see how the software works.

Here's my schematic, autorouted by Fritzing. If I try and autoroute with that last R/W- CE line, it will crash the software. Maybe I can send that in...

This is just the 6802 Microprocessor and an Alliance Memory AS6C6264A 8Kx8Bit SRAM. Not all necessary lines are connected, the CS line goes through a decoder chip which isn't on here yet, and the power/grounds aren't wired up either.

This worked out pretty well, but I was really interested in trying out the PCB designer part, because I've tried a few before, and while they're interesting, they all have their quirks. Fritzing is no different, but there are a few little things that help. One in particular is the shift-click on bendpoints on traces.. It lines the trace bendpoint up in an intuitive way, though it does require a bit of getting used to in order to make things work the way you want. The autorouter leaves much to be desired, but it's still an alpha piece of software, so I decided to route by hand to see what I could do. Here's the result:

It's not too bad, yeah, I might not be able to fit a 16 mil trace between those pads, but I was getting a little impatient after things kept crashing and I wanted to get this blog post up. I just did a quick bit of hand-routing to make this work, which it seems to quite decently. Vias work, the way they should after you figure them out, and it's something I've been able to quickly pick up and run with.

One lesson I've come back to: Save often!

I'm going to keep going in Fritzing I think, laying out the schematic mainly and building parts I need, then I'll work on getting the traces all worked out on the schematic. I'm going to keep posting progress pictures, though this weekend will be a bit busy, going to see what I can get done.

Saturday, August 20, 2011

Starting out

Okay. So for this Type 'n Talk thing to work, I need to design a schematic. Then I can lay out a board, then get it made, populate it, etc..

Decided to give Fritzing a go. It's an interesting, relatively new electronics design software that's open-source and seems fairly friendly. I don't think it has an autorouter, but that's no problem, I can lay out the traces myself; there's not too many of them on this board. I'm combining  components too, so that should reduce part count and traces even further.

So, to give you an idea of what I need to do, I need to take this schematic, and create my own with new parts that I can actually get, and make it actually work.

The first thing I decided to tackle is the ICs. I don't know what a lot of these ICs are, I've never used them before. A lot of electronics veterans may know about them from seeing or using them in the past, but I'm new to this game. What's a 2114? a 6802? a 7442? Well, they used to be some industry standard parts. Every manufacturer made their own version of them, and they would prefix them with their specific letters to denote they made it.

This gets technical. I start explaining memory storage and how these chips work. If you don't want to know about that, you can skip.

If this gets a little 'teachy', it's because I just learned this stuff. It's really cool. This explanation may help someone else who would like to understand how this memory works.

Well, the chips I started out with are 2114's. They are 1024x4 bit memory modules. Here's the 1979 datasheet.
What does that mean? In these chips, memory is organized into groups. You'll usually see this type of notation such as 1024x4, 512Mx8, etc. This is basically how many 'cells' of how many bits the memory chip can hold.

Let's take the 1024x4 as an example. This means that there are 1,024 cells of 4 bits each. Imagine your house has 1,024 rooms in a grid, like an office. Each room has 4 light switches. You can go to any room, and turn on or off the switches, in any pattern you like. This is how memory is stored. Each 'switch' is a bit, and each 'room' is a cell. So, total, since each room has 4 switches, and there are 1,024 rooms, you can have a total of 4,096  switch positions, or 'bits' of information stored.

Now, how do you tell which room to go in?
The chip has row decoders, and column decoders. Basically,  they use binary to specify which row, and which column to enable, depending on how those pins are toggled, and what binary coded numbers are produced by toggling them.
For example, if we had row pins set to 1,0 and column pins set to 0,0 that would tell the chip to look in Row 2, and Column 0, and either read or write to that spot.
Reading and writing is easy, if you want to write, you set your row and column pins to the cell or 'room' you want to write to, then set the 4 inputs to the 1 or 0 bits you want to write, and toggle the write enable line to the write position, which will write the data into those bits or 'switches'. If you want to read it back, simply set the row and column pins as before, and then leave the write enable to read position. The contents of that cell will appear on the data lines.

Ok, back to our regularly scheduled program...

So, my dilemma is that the 2114's are no longer made. They haven't been made for years, and for good reason. Memory technology has come a long, long way since then and we have faster, bigger, lower power memory chips now. 2114's were about $10 apiece when they were originally made, and you can get ten times that much memory now for the same price. Luckily though, while the newer chips can store more things, they also work the same was as the old ones!

So let's look at a new SRAM chip from a common manufacturer, Cypress Semiconductor. It's model CY7C185.
This chip has 8Kx8, or 8192x8. Looking back at how we broke down the 1024x4, this means that this chip has 8192 cells (or 'words' as they are called in the industry) of 8-bits each. This means that the new Cypress chip can hold 65,536 bits of data. That's 16 times more data than the old 2114 chip, and they only cost about $2 per chip! The new one also reads almost three times faster than the old chip, and it uses about 4 times less power!

So the issue now is how to integrate this chip. Well, there's a reason I chose a x8 chip and not a x4 chip. See, the original circuit design combined two x4 chips into a single 'x8 chip'. Since all the row and column registers are tied together in the schematic, whatever row and column the microcontroller selects, is selected on both chips. Whenever the micro flips on the chip select, both chips are on. The Write Enable lines for both chips are also tied together, so the micro can't tell which chip it's writing to, so each time it writes, it writes in 8-bit blocks. If it only wrote 4 bits, both chips would still have their write lines turned on, so one chip would write garbage while the other one wrote good data! This means that they *have* to write all 8 bits at a time.

This makes it easy. It's already writing in 8-bit blocks, so just put in a chip that will handle 8 bits for each cell, instead of two chips with 4 bits each! For the row and column selectors, being that the new chip has more memory, it also has more pins for those selectors. However, since we're only going to be using the first 1024 cells (this is all the original memory chips could address, remember?), the cells above 1024 will simply go unused. No big loss, since the memory is so cheap. We will simply tie the other ends low so they are not used when selecting rows or columns.

Here's my diagram. The top drawing shows how the memory is organized now. Notice that the D0-D7 lines are split up evenly between the two chips. This is how they combine the two smaller chips into one big 'chip'.
The bottom diagram shows an example (using a different chip than I mentioned above) of how I could integrate a larger memory chip utilizing all 8 bits at once into something much larger.

So, that's about it so far. I'm starting work in Fritzing, going to have to add my own components in and such, and I'm still researching memory options. I'll post some WIP schematics soon!

Votrax Type 'n Talk

Well, I have decided that I'm going to be building a Votrax Type 'n Talk from scratch. Well, aside from the Votrax SC-01 chip, that is.

I used to play with one of these a long time ago; my dad bought one and I would play with it at an old IBM computer, sending it text and making it say things. They're fun boxes, and they are (relatively) good at reproducing speech. They were made by a company called Votrax, which was a division of Federal Screw Works, in Detroit, MI. There's a lot more on their history on Wikipedia, so if you'd like to learn more about the company and the various products they produced, as well as how their voice synthesis works, check out that article.

The synthesizer is a basic design, uses a simple Motorola 6802 CPU with a 4K ROM and 8192 Bits of memory.
A really awesome guy has taken several Votrax products and de-potted the ROM/CPU, dumped out the ROM and completely traced out the schematic on the board. His website is here:

Basically, my project is to take the schematic, and build a smaller, more modern version of the Type 'n Talk. Mine will have the same volume/frequency knobs, the same ROM, will operate the same way, with some improvements. Particularly, the updated version I'm building will have a USB port instead of a DB-25 serial, will do away with the baud rate switches (not necessary if I'm handling that internally) and will have a better power supply. Also, it'll have a smaller box, and more speaker outputs.
The difficult part is that the ROM has code in it that takes incoming ASCII text, interprets words into phoneme data, and feeds that into the SC-01 chip. The SC-01 is the actual Votrax chip that generates the speech from phonemes.

SO. I have the schematic, a list of parts, an SC-01, time, and the internet. LETS DO THIS.

Tuesday, March 15, 2011


Well while things are going decently on the bot, aside from having trouble getting the PLA to stick to the kapton (it doesn't seem to like it like ABS does), I'm having a bit of trouble with bed temperatures.

The temps on the bed have a large gradient from the center to the outside of the bed. The thermocouple that I have kapton taped an inch or so from the edge reads 65C while the center of the bed reads 100C. I've checked independently with a IR temperature gun, and it's showing me the same thing. The edges are staying way cooler than the center. This has caused some issues where the far side of a print will start to curl a little and the center will stay (while doing ABS at least). This issue is somewhat  understandable as the aluminum is very thin and because of that, acts like a heatsink in the open air; the edges dump their heat quickly while the center is trying hard to keep things warm. I need something with a better heat transferrance and capacity.

I had previously purchased a larger heater mat cause I intended to buy one of the beds, since they're made from almost 5mm thick aluminum. That'd have some serious heat transfer abilities.
Unfortunately, it's kind of pricy to get that shipped from europe here, especially with such a commodity material as metal. So I started looking around for places to get the bed from, as it's simply a 9"x9" sheet with some holes drilled in it. The little notch is optional for me as it isn't there for clearance, just as a hole for the extruder to dump test extrusions into.

However, I got to thinking. If aluminum is good, then copper must be better! It has almost twice the thermal conductivity of aluminum (Copper: ~ 385 W/m K, Aluminum: ~ 204.3 W/m K) and I can get it relatively easily (though not cheaply). I went to and purchased a 9" x 9" x 0.125" sheet of copper. It's nice because they will cut the sheet to your specs for you, and it can make things cheaper as well! It was about $70, so to bump things up to the $100 mark (where you get a discount) I added a couple pieces that my friend would need for his RepRap on there, as well as a version of the bed in 5mm thick aluminum, just in case the copper didn't work out.

The items came in today, and wow! The copper really is heavy. I hope that the steppers can drive this thing around. The Aluminum bed is also quite large.

I can't wait to get the new heater glued in so I can see how well the copper plate reacts to the temps, and if the temp gradient is the same.

Tuesday, March 1, 2011


Well, after much time not working on this thing, I have the time and drive to do it. So, got down to business.

The RepRap, when we last left it, was in a mostly working state. Aside from the temp controller. After chasing down the odd issues revolving around problems with it not able to hold temp correctly, I really got serious about looking for issues. I finally found a problem in the power signal coming from the supply. It appears that the cheap Chinese power supply we ordered was indeed cheap, but also noisy. As you can see in the following video, the oscilloscope shows huge spikes and changing noise on the line as the thermocouple turns on and off. I should mention that this reading is on the thermocouple itself, not on the output of the power supply, even. It was creating huge amounts of noise.

I had a 0-15VDC 40A capable power supply (yeah, big) hanging around, so I decided to give that a shot. Hooked it up and the noise was gone, and the temp controller is much more stable now. It still fluctuates a couple degrees between when the heater is on or off, but it's within the limits of the controller's abilities to hold it mostly stable, so I decided to just go ahead and proceed with getting it up and running.

To start, I got a copy of RepSnapper and compiled it, and gave it a test STL and after much playing around trying to get the machine actually talking, I finally got things moving, and made a test print. It's not much to look at, but it's a print.

After this, I began working on Skeinforge to get it to make a decent gcode file. I had issues getting the plastic to stick to the cold kapton and aluminum, so since I already had a heater mounted to the aluminum, I set up my other temp controller and an SSR to control the 110v going to the bed heater. It heats up in about 20 seconds. Things started sticking MUCH better after that.

Following getting things to stick, I tried a few calibration squares, then a ring from Thingiverse to see how good it was working. The calibration cubes are coming out mostly squared up nicely, though I'm having some issues with flow rate. I think I'm not putting enough pressure on the filament in the extruder and I'm having issues here and there with it stripping out occasionally, usually due to the FTDI cable not being hooked up when the stepper controllers are powered on. If the enable line floats and so does the input, the steppers will drive all crazy until they're pulled in a certain direction by the motherboard. Here's a video of building one of the rings:

Last night I tried printing a few more rings as well as an object someone in the lab had tried to make (a mixing paddle from a bread machine) and it did a decent job, albeit with flow problems again. I printed a pair of tweezers as well. So far, so good. A few pieces of the machine aren't tightened up properly and they're falling off, but I'm keeping it together. I'm going to build  my own small control board and mount for the Omron controllers, and finish getting the wiring cleaned up. I'm looking at making one of the new sexy Wade's derivatives that popped up on Thingiverse recently:
It's got better accessibility to the hobbing as well as a better gear ratio and smaller styling. I'm excited to start printing stuff on this thing! Hopefully the blog will be going a bit faster now that we've got some activity!