Thursday, February 2, 2017

I'm expanding!

By this I mean I'm expanding the scope of this blog, not my waistline.

Rather than being solely about my exploration of the Intel 4004 CPU and peripherals, I'm going to include some of my other electronic tinkerings. I'll be tagging the i4004 stuff with an appropriate label, my work with KiCad with another, etc.

I expect this will mean more frequent updating, though as a hobby it will still be dependent on what I find time to work on.

Wednesday, February 1, 2017

A very tight fit

I spent a few hours hunting around for a socket that would accept a row of pins on 2.0 mm centers. There are quite a few of them, but most are designed to accept small square pins, perhaps as wide as 0.66 mm. The pins on the Vacuum Fluorescent Display are 0.7 ±0.12 mm wide and only 0.18 mm thick. This would be trivial if I wanted to solder it directly to a PCB, but I'm not in a position to know what I need in the way of a final PCB yet, and I don't want to risk damaging the VFD by trying to removing it from a PCB.

I think I finally found one possibility: the Mill-Max 8114 series. This is a single-contact pin receptacle able to accept a pin up to 0.86 mm wide, while only being 1.65 mm wide itself. That would leave a 0.35 mm gap between pins. Not terribly wide, but wide enough to fit some sort of insulator between, if need be, to maintain spacing. Maybe a bit of heat-shrink tubing over each one? I'd hope that the centering action of the VFD's pins would make this unnecessary.

A second option is to simply solder some wires to the pins and plug them into the solderless breadboard for testing. The only bit that seems critical is the pin is connected to an on-display oscillator, which requires an RC circuit that needs to be connected close to the pin. For this I'd simply solder the resistor and capacitor directly to the oscillator pin.

Sunday, January 29, 2017

Memory is the second thing to go

It's said that as we age, your memory is the second thing to go. And I don't remember what the first one was...

Since I have new incentive to learn to use the KiCad electronic design suite, I thought I should start with a small project. Something worth doing, but small enough that I can focus on the tool rather than the project. Also something that wouldn't cost much to re-spin if I screwed it up.

One of the first that came to mind is a test board to drive the Noritake-Itron DS2029H Vacuum Fluorescent Display (VFD). The connections to this display are a row of flat fingers along the top edge, kinda like an integrated circuit, as you can see in this photo:

I'd just plug this thing into my solderless breadboard except for one thing: the fingers have a 2.00mm pitch, not the 2.54mm pitch of my breadboard. Bummer.

I'm weighing two options for PCBs. I could make a board that mates with these fingers and connects them to pins on 2.54mm (0.1 inch) centers. Then I could wire test circuits on a solderless breadboard. The other is a complete VFD test board supporting a PIC, a USB serial interface, and the 5V-to-36V boost regulator needed to drive the VFD anode. Right now I'm leaning toward the latter.

How does the title of this posting figure into this? Keep reading...

Thursday, January 26, 2017

Major changes in Eagle licensing

When I started to do PCB layout back in 2000, I looked at a number of CAD packages. As a hobbyist I tend to favor open-source products. First I looked at the gEDA suite but it looked like a collection of un-related tools that could be forced to work together. Then I looked at KiCad, but at the time it was lacking many essential functions. Eventually I found CadSoft's Eagle.

Like several other commercial PCB CAD packages, Eagle offered a "freeware" version intended for hobbyists. All of these are crippled in some way to prevent them being used for commercial purposes, but while most limited the number of holes or devices, Eagle limited only the size of the board to 100mm x 80mm and the number of layers to two. The project I wanted to do at the time was a very small 2-layer board but had a lot of holes, so this was a good fit. When that project appeared to be destined for commercial production I spent $50 to obtain the smallest commercial license for V4. I continued to use the freeware V4 and V5 for hobby projects for several years.

When I started the 4004 replica I immediately realized that making 2-layer 100mm x 80mm boards wouldn't work. Again I looked around at other products, but discovered that Eagle V6 offered a non-commercial hobbyist license that would give me 6 layers, 100mm x 160mm dimensions, and multiple schematic sheets of a size large enough for the 4004 schematic. That seemed to work well, so I spent the $160 to get it.

A few years back Farnell bought CadSoft. The initial V7.0 release had a wacko licensing scheme that had all the Eagle users upset. Eventually the outcry forced Farnell to return to the previous licensing scheme. I was content with my perpetual V6 hobbyist license, but decided to buy the V7 upgrade to get the bugfixes. All was good until this summer, when AutoDesk bought Eagle from Farnell. AutoDesk promised expanded investment that would bring all sorts of enhancements, and even promised a better pricing structure.

Beware of people who promise to "make things great", because it means they think what exists is bad. AutoDesk's "better pricing structure" changes the perpetual license to a subscription license, meaning that you have to keep paying or the product stops working. It's "better" because if you only need the product for a month you only have to pay for a month. But then if you want to go back to a project after the end of that month, you have to pay for another month. Of course you can pay for longer-term subscriptions and get better pricing, but when the subscription runs out, poof!

As anyone who has followed this blog knows, I'll work on a project for a weekend and then it may be weeks or months before I work on it again. A subscription license is a non-starter for me and folks like me. Further, the hobbyist license I have seems to have disappeared. For me to use Eagle V8 on my 4- or 6-layer boards I'd need to buy the "Professional" package at $65/mo or $500/yr. I have seen discussions where AutoDesk has talked about expanding the "Standard" package to 4 layers, but that wouldn't help with my 6-layer ID and ALU boards, and it'd still be $15/mo or $100/yr. That's not going to happen.

Thus my involvement with Eagle has nearly reached its end. My license for Eagle V7 has no termination date, and AutoDesk can't change that retroactively. I will continue to use Eagle for the 4004 boards, as most of them have already been started and there's no reason to change horses in mid-stream. But I won't be upgrading to V8, which means no bugfixes and no support for new OS releases.

What will I use in the future? KiCad has come a long way in the last 17 years, and it continues to improve. The PCB I'll need to make to fit into the shell of the P170-DH calculator is larger than the 100mm x 160mm limits of my Eagle hobbyist license, so I'd long planned to use KiCad for that. The changes in Eagle licensing simply means that instead of that being a one-off use I won't be going back to Eagle for future projects. Instead I'll focus on learning to use KiCad as well as I have Eagle.

Monday, December 19, 2016

More on the M-32TL printer

The last couple of weekends I've stolen a few hours here and there to put my logic analyzer on the M-32TL printer in the Canon P170-DH calculator I've chosen as a keyboard and printer interface to my 4004 CPU reconstruction.

Here you can see the USB logic analyzer pod on the left, and the under side of the calculator on the right. The printer is visible in the upper right corner.

This printer can print in either black (blue-ish, anyway) or red. I previously linked to a web page by Arne Rossius with his analysis of the similar M-31A printer, but of course it gave no hints as to how the shift to red worked. By recording the signals received from the position sensor and the signals driving the motor and solenoid, I've been able to get a better idea how this printer works.

Although I found the pinout to be the same as described in the M-31A, I disagree with Arne's description of the function of the position sensor signals.

1Solenoid -
2Solenoid +
3Motor +
4Motor -
5Solenoid index
6Rotation index
7Sensor common
8Character index

In the P170-DH, pins 2 (Solenoid +) and 3 (Motor +) are connected to the unregulated positive supply, which seems to provide a bit under 8 VDC. Pin 7 (Sensor common) is connected to ground, while pins 5, 6, and 8 are pulled to a logic "high" through resistors and debounced with an RC network. When a sensor contact connects with the conductive pattern etched on the sensor disc it pulls the logic input low.

Here's where my analysis differs: When pin 8 goes low, the printer wheels are approaching the next character. If pin 6 is also low it's the first character in the sequence given below, else it's the next one in the sequence. If this character is to be printed the solenoid is activated when pin 5 next goes low and remains activated until pin 5 goes low again.

Why not just use pin 5 to determine the character position? It appears from the signal recordings that while the character is being printed the wheels stop moving briefly. During this time pin 5 often generates several erratic low indications, while pin 8 never does. I suspect the contact for pin 5 is just on the edge of the conductor pattern on the sensor disc and any movement of the disc causes the contact to make and break. This would result in printing errors.

It also appears that this printer can print from the "Symbols" wheel in the right-most two columns, rather than only one. I haven't seen this calculator do it yet, but the second character printed thus far has always been index 10, which is a space. There's definitely enough of a gap between the right most symbol and the first number for one if not two more characters.

Wheel Character Printed
Symbols + × ÷ Δ G M C = (space) % (red)
Numbers 0 1 2 3 4 5 6 7 8 9 , #

The third character appears to be the key to the color shift. If the number portion is to be printed in black, the third character is index 10 (a space). But if the number is to be printed in red, the third character is index 13; this also prints as a space, but all following characters are printed using the red number wheel.

Printing of a line is completed by activating the solenoid for much longer than a single character time while printing the final character. In my tests the P170-DH asserted the solenoid for just under 24ms.

At some point I'll want to disconnect this printer from the calculator board so I can test it with a PIC as a driver. The reason I haven't done so yet is I'm not sure I've learned all I can before I start disassembling it. I do have a second P170-DH, but I'd rather not have to open that one up unless I need to.

Sunday, November 27, 2016

Tweaking the FDV301N Spice model: Cgs

To improve my Spice model of the FDV301N MOSFET I need to understand a little more about how they work. A lot of the dynamic behavior can be modeled as three capacitors: Cgs, Cgd, and Cds. The complexity, as seen in the model provided by Fairchild (diagrammed in the previous post), comes from the fact that the value of Cgd changes as Vgd changes. This post focuses on measuring and modeling the simplest of these: Cgs, the capacitor between the Gate and the Source.

To make life more fun, the data sheet doesn't give the value of Cgs. They give three other values, Ciss, Coss, and Crss:

My research says that Cgs can be calculated as Cgs = Ciss - Crss, so Cgs for the FDV301N should be 8.2pF. The updated Spice model Fairchild provides models Cgs as 8.5pF, which seems close enough. But how do you compare this against the real device?

As a MOSFET is driven on with a constant-current source, its gate voltage does not rise linearly. As the drawing on the right (from ON Semiconductor publication AND9083/D) shows, Vgs behavior can be characterized in three phases. In phase A (red), the gate current is charging Cgs, but Vds has not begun changing. In phase B (blue), the transistor begins to conduct and Vds begins to drop, which means the voltage across Cgd is also changing. With the gate current being consumed charging Cgd, Vgs does not change. In phase C (green), Vds has reached its minimum (or near enough to it) and the gate current goes toward charging both Cgd and Cgs.

Long ago I created an LTspice model of a chain of FDV301N inverters for simulation testing. To this I added 10pF capacitors between the gates and ground to represent my oscilloscope probes. I also replaced the U2 device, which used the Fairchild Spice model, with the X2 device, which is based on my sub-schematic version of this same model.

How can we use this to determine whether the model's Cgs matches that of a real FDV301N? Let's look at the behavior of X1 in our inverter chain. If we pretend that the load resistor of the previous inverter (R1) is a constant-current source, we can calculate the charge and the lumped capacitance of C2 and Cgs of X1. Okay, so a resistor makes a lousy constant-current source, but the first 1V rise of an RC circuit being driven to 5V is a reasonable first approximation.

I ran a simulation, probed the S1, S2, and S3 nets, and zoomed into the area where S1 rises, S2 falls, and eventually S3 rises. Here's what it looked like:

It's hard to judge from just the graph, but the time from when S1 begins to rise until S2 begins to fall is about 88ns. This is the phase which represents Cgs charging. If our model is correct, we should see the same behavior on the breadboard:

Well, what a surprise! The simulation matches the model. This suggests that the simulation models Phase A pretty well. What happens after that, in Phase B, is not so good, but that's fodder for another post.

Monday, November 21, 2016

Another attempt at simulation

I really haven't been in the mood to finish any of the PCB layouts, but I didn't want to let this project languish untouched. One of the items on my list has been to get valid simulation results so I can predict whether my choice of pull-up resistors is valid.

In the interim there's been an update to the published Spice model for the FDV301N MOSFET. One of the changes was to change the Cgs value from 78pf to 8.5pf, which makes much more sense to me. I re-ran the simulation from June 2012, and found the new model reduced the per-stage propagation delay from about 200ns to 105ns. This is an improvement, but still longer than the 70ns or so I'm seeing on the breadboard when the effects of the scope probe loading is factored out.

I'm still comparing the simulation results with the actual tracings to understand what needs tweaking to make the simulation more accurate. To make it easier to understand this rather complex model I drew the FDV301N model using the LTspice schematic capture:

The resulting netlist differs from the original model only in comments and minor formatting; otherwise it's identical right down to the net names. I no longer wonder why simulations using this model are so slow.

In the process I think I've discovered an error: the negative output of the EDB voltage source is connected to net 0 (ground), which makes no sense given that the positive output is connected via diode D to the FET's drain pin.  It seems to me that only things related to the temperature input (net 50) should be referenced to ground. I don't think this is affecting the test simulations, since all the Source pins (net 30) are connected to ground, but it would affect some of my real circuits.