Saturday, May 12. 2018
Power Op-amps Rock - Driving A YIG Oscillator
High on the list of things I need to write up is my radar-building saga; suffice for now to say that I’m (now) using a tiny yttrium iron garnet in a magnetic field as my viola to generate the signal for my frequency modulated continuous wave radar.
As fancy as it sounds, a Stellex YIG oscillator unit (mounted yttrium garnet, heater, tune and modulation coils) can be found on ebay for around $20. I got a Stellex 6755 job that does 8-10 ghz. In short, all one needs to do is apply heater voltage to the thing to get it generating rf, and adjust the frequency by changing the current in the two tuning coils. It puts out +16 dBm, respectable.
Flash back to radar - the goal is to generate a frequency-sweeping rf signal that moves as linearly as possible. First, we need to generate that sawtooth pattern to modulate our YIG. I played with several analog sawtooth producing circuits but couldn’t find one that generated a perfectly linear ramp, and I really don’t want to have to sample the modulation signal to (try to) correct the nonlinearity in software later. Not feeling like pulling out a microcontroller for the task, I threw together this guy from things I had on hand:
A TTL oscillator is cleaned up and complemented by two schmitt trigger inverters a la 74HC14. On the rising edge, a 74LS191 4-bit counter latches its incremented value, and on the falling edge, the DAC samples the value and produces the specified current. Eventually I'll replace the counter with an FPGA so I can do arbitrary waveforms (hint, a triangle wave lets you deduce both range distance and doppler shift at the same time in an FM CW radar), but for now the modulator is at least aesthetically pleasing.
While the DAC in fact outputs its value in the form of current, not voltage, the current range (max 10mA) is far below what is needed to tune and modulate the YIG (around 250 mA). Alas. Thus, we use the resistor network specified in the DAC’s datasheet to convert our current source (hopefully very linearly) into a voltage signal with which we will… drive a power op-amp setup to convert voltage signals to current.
One of my new favorite parts I happened to find in my ICs bin is the L272, a dual op-amp beast that can source or sink 1A continuously. Rather than using a (regular old) op amp to drive the gate of a mosfet or BJT as is common, this beast of an op amp means we can drive the tuning coil(s) of the YIG directly.
Unfortunatly, the huge current capability comes at a cost: the L272 has a slew rate of 1 V/uS and a unity gain bandwidth of 350 kHz, far below what would be required to follow my above modulator signal with the 5 MHz clock on it. Drat. This limits the sweep rate and thus TX bandwidth of the radar considerably, but at least doesn’t suffer the oscillation problems with transistor-driver circuits that limit max slew rate and bandwidth there, too.
In any event, we use a 10 ohm resistor on the negative side of the tuning coil to generate a voltage signal (hopefully very) linearly related to the current drawn,and use the op amp to compare this voltage with the “requested” voltage, adjusting its voltage output until the current monitor’s voltage matches.
So! It works. It even turns out YIG sources tune down in frequency faster than they tune up, thus helping us match the output to the sawtooth modulation signal exactly. More to come on the radar front...
As fancy as it sounds, a Stellex YIG oscillator unit (mounted yttrium garnet, heater, tune and modulation coils) can be found on ebay for around $20. I got a Stellex 6755 job that does 8-10 ghz. In short, all one needs to do is apply heater voltage to the thing to get it generating rf, and adjust the frequency by changing the current in the two tuning coils. It puts out +16 dBm, respectable.
Flash back to radar - the goal is to generate a frequency-sweeping rf signal that moves as linearly as possible. First, we need to generate that sawtooth pattern to modulate our YIG. I played with several analog sawtooth producing circuits but couldn’t find one that generated a perfectly linear ramp, and I really don’t want to have to sample the modulation signal to (try to) correct the nonlinearity in software later. Not feeling like pulling out a microcontroller for the task, I threw together this guy from things I had on hand:
A TTL oscillator is cleaned up and complemented by two schmitt trigger inverters a la 74HC14. On the rising edge, a 74LS191 4-bit counter latches its incremented value, and on the falling edge, the DAC samples the value and produces the specified current. Eventually I'll replace the counter with an FPGA so I can do arbitrary waveforms (hint, a triangle wave lets you deduce both range distance and doppler shift at the same time in an FM CW radar), but for now the modulator is at least aesthetically pleasing.
While the DAC in fact outputs its value in the form of current, not voltage, the current range (max 10mA) is far below what is needed to tune and modulate the YIG (around 250 mA). Alas. Thus, we use the resistor network specified in the DAC’s datasheet to convert our current source (hopefully very linearly) into a voltage signal with which we will… drive a power op-amp setup to convert voltage signals to current.
One of my new favorite parts I happened to find in my ICs bin is the L272, a dual op-amp beast that can source or sink 1A continuously. Rather than using a (regular old) op amp to drive the gate of a mosfet or BJT as is common, this beast of an op amp means we can drive the tuning coil(s) of the YIG directly.
Unfortunatly, the huge current capability comes at a cost: the L272 has a slew rate of 1 V/uS and a unity gain bandwidth of 350 kHz, far below what would be required to follow my above modulator signal with the 5 MHz clock on it. Drat. This limits the sweep rate and thus TX bandwidth of the radar considerably, but at least doesn’t suffer the oscillation problems with transistor-driver circuits that limit max slew rate and bandwidth there, too.
In any event, we use a 10 ohm resistor on the negative side of the tuning coil to generate a voltage signal (hopefully very) linearly related to the current drawn,and use the op amp to compare this voltage with the “requested” voltage, adjusting its voltage output until the current monitor’s voltage matches.
So! It works. It even turns out YIG sources tune down in frequency faster than they tune up, thus helping us match the output to the sawtooth modulation signal exactly. More to come on the radar front...
Saturday, February 4. 2017
Showing Off: Compressor and Turbine Blade Designs
I've spent way too much time in the last few months rebuilding my CNC mill with ballscrews, 4th axis, other upgrades, but I'm finally back in business
and ready to cut some sweet parts. I'll do a long post about the jet projects in progress, here's a sneak preview.
In about a page of Common Lisp, I nab the XY values for a NACA 2408 airfoil, scale it progressively from root to tip, twist it 25 degrees, and generate G-code to cut it using either the 4th axis or vertically top-down (or detecting that your blade profile can't be milled top-down).
Oh, and also serve up an HTTP interface to view the shape updates in real time using visjs.
More to come...
and ready to cut some sweet parts. I'll do a long post about the jet projects in progress, here's a sneak preview.
In about a page of Common Lisp, I nab the XY values for a NACA 2408 airfoil, scale it progressively from root to tip, twist it 25 degrees, and generate G-code to cut it using either the 4th axis or vertically top-down (or detecting that your blade profile can't be milled top-down).
Oh, and also serve up an HTTP interface to view the shape updates in real time using visjs.
More to come...
Friday, December 16. 2016
Circling back: Altera Quartus 12.1 on Ubuntu
Thursday, May 29. 2014
Radseed: A Kernel Module for Real Randomness
Wednesday, May 14. 2014
Interfacing Cirrus Logic Audio ADCs
I've been considering ideas for audio gear of various sorts over the past few months, and decided a good starting place would be a solid ADC interface from which I could prototype concepts. Lots of companies make audio converters, but I settled on two models from Cirrus Logic: the CS5361 and CS5340. They are, respectively, balanced and unbalanced two-channel 24-bit 192 khz high dynamic range delta-sigma oversampling devices.
I started by laying out a super-simple protoboard for the CS5361. Since I wanted this to be quick and easy to cut on the CNC mill, the board is single-sided with the bare minimum of filtering, and without standard mixed signal board design concepts like separate analog and digital ground planes. While this will negatively affect the noise figure a bit, I wanted to get the device up and running with the minimum investment of time in case my assumptions regarding its usage and support were incorrect.
By the time I had finished the layout and cut the board, the samples order had arrived! Soldering was quick though a tad arduous - I need to use a larger 1206 footprint next time.
My ugly solder job notwithstanding, I plugged the unit into a breadboard, wired up an oscillator, config pins, and the logic analyzer, and was immediately rewarded with correct operation:
In short, by simply applying power, config pin states, and a master clock, the device will shift out ADC values (in 2's compliment form) msb-first on the falling edge of SCLK (ie, we sample on the rising edge):
The only other line we need to worry about is LRCK, which indicates the channel being sent - you can see here that we get a left sample, then a right sample, then repeat:
With the hardware working, I set about writing the Verilog modules to nab samples from the ADC and send them off via USB (using an FT245R FIFO interface I have on hand). The code is extremely simple: on the rising edge of SCLK, samples are shifted into an 8-bit register - the size of the data bus on the USB interface. Every 8 bits, that register is strobed into the FT245R and the process repeats.
Byte alignment is provided by LRCK: on a start or reset condition from the USB host, the FPGA waits for a rising edge of LRCK before beginning the sampling and transmission of samples. This allows the client end to interpret the data stream without framing bytes: incoming data is simply shifted into 3-byte (24-bit) samples, left then right, and processed as desired.
The code was quick to write and simulate with my favorite tools, iVerilog and GTKWave. I implemented a quick CS5361 module whose left and right channels count up and down (respectively) so as to simulate the rest of the pieces. Unfortunately I spent almost as much time debugging the code in hardware with the logic analyzer as I did writing the code, as Quartus (the Altera design software) is rather inconsistent in its handling of constants and register widths. (note: always read every line of output from the Altera synthesis toolchain - one can easily spend 4 hours trying to debug a problem that makes no sense only to find that the synthesis tool decided a constant was the wrong size and used zero instead)
In any event, I did manage to squash the few Quartus oddities that had caused the hardware to operate differently from the simulated code, and verified that the USB interface looked correct using the logic analyzer. Time for more spaghetti:
Time to test it out. In its current state, the FPGA will assert a reset condition on any received byte from the FIFO buffer. So, we will send a reset byte then read 24 samples of 6 bytes (3 for each channel):
root@ichor ~ # echo -n 0 > /dev/ttyUSB0 && dd if=/dev/ttyUSB0 count=24 bs=6 2>/dev/null | hexdump
0000000 3238 a13f 4a68 a650 0344 bd41 6632 ceaa
0000010 78f2 28f8 9764 19ca 7185 45b4 6bfd eabf
0000020 9825 8050 65e5 6122 3adc 0830 28f0 9dfc
0000030 d026 746a e2c0 befa 57dc 1fa4 4225 7b82
0000040 a61b ed00 2320 d641 e111 b648 a2f3 8d3a
0000050 bdfb afb6 1287 5963 ff57 9c8e 63a1 3971
0000060 4bfe ac6e 5081 9fae 2b0d 5c4c 6eaa 26b7
0000070 164b 6093 8378 96d8 138c 160e e661 a81b
0000080 81bc bdae 530b ec79 3537 6ada b0cc 4773
0000090
Success! With that working, the next steps are to implement the CS5340 and add proper dynamic configuration loading. From there, I am hoping to implement ADAT input and output and a simple device driver to interface the kernel audio subsystem.
I've put the code, board design, and a bit of documentation on GitHub: jackcarrozzo/cs_adcs.
I started by laying out a super-simple protoboard for the CS5361. Since I wanted this to be quick and easy to cut on the CNC mill, the board is single-sided with the bare minimum of filtering, and without standard mixed signal board design concepts like separate analog and digital ground planes. While this will negatively affect the noise figure a bit, I wanted to get the device up and running with the minimum investment of time in case my assumptions regarding its usage and support were incorrect.
By the time I had finished the layout and cut the board, the samples order had arrived! Soldering was quick though a tad arduous - I need to use a larger 1206 footprint next time.
My ugly solder job notwithstanding, I plugged the unit into a breadboard, wired up an oscillator, config pins, and the logic analyzer, and was immediately rewarded with correct operation:
In short, by simply applying power, config pin states, and a master clock, the device will shift out ADC values (in 2's compliment form) msb-first on the falling edge of SCLK (ie, we sample on the rising edge):
The only other line we need to worry about is LRCK, which indicates the channel being sent - you can see here that we get a left sample, then a right sample, then repeat:
With the hardware working, I set about writing the Verilog modules to nab samples from the ADC and send them off via USB (using an FT245R FIFO interface I have on hand). The code is extremely simple: on the rising edge of SCLK, samples are shifted into an 8-bit register - the size of the data bus on the USB interface. Every 8 bits, that register is strobed into the FT245R and the process repeats.
Byte alignment is provided by LRCK: on a start or reset condition from the USB host, the FPGA waits for a rising edge of LRCK before beginning the sampling and transmission of samples. This allows the client end to interpret the data stream without framing bytes: incoming data is simply shifted into 3-byte (24-bit) samples, left then right, and processed as desired.
The code was quick to write and simulate with my favorite tools, iVerilog and GTKWave. I implemented a quick CS5361 module whose left and right channels count up and down (respectively) so as to simulate the rest of the pieces. Unfortunately I spent almost as much time debugging the code in hardware with the logic analyzer as I did writing the code, as Quartus (the Altera design software) is rather inconsistent in its handling of constants and register widths. (note: always read every line of output from the Altera synthesis toolchain - one can easily spend 4 hours trying to debug a problem that makes no sense only to find that the synthesis tool decided a constant was the wrong size and used zero instead)
In any event, I did manage to squash the few Quartus oddities that had caused the hardware to operate differently from the simulated code, and verified that the USB interface looked correct using the logic analyzer. Time for more spaghetti:
Time to test it out. In its current state, the FPGA will assert a reset condition on any received byte from the FIFO buffer. So, we will send a reset byte then read 24 samples of 6 bytes (3 for each channel):
root@ichor ~ # echo -n 0 > /dev/ttyUSB0 && dd if=/dev/ttyUSB0 count=24 bs=6 2>/dev/null | hexdump
0000000 3238 a13f 4a68 a650 0344 bd41 6632 ceaa
0000010 78f2 28f8 9764 19ca 7185 45b4 6bfd eabf
0000020 9825 8050 65e5 6122 3adc 0830 28f0 9dfc
0000030 d026 746a e2c0 befa 57dc 1fa4 4225 7b82
0000040 a61b ed00 2320 d641 e111 b648 a2f3 8d3a
0000050 bdfb afb6 1287 5963 ff57 9c8e 63a1 3971
0000060 4bfe ac6e 5081 9fae 2b0d 5c4c 6eaa 26b7
0000070 164b 6093 8378 96d8 138c 160e e661 a81b
0000080 81bc bdae 530b ec79 3537 6ada b0cc 4773
0000090
Success! With that working, the next steps are to implement the CS5340 and add proper dynamic configuration loading. From there, I am hoping to implement ADAT input and output and a simple device driver to interface the kernel audio subsystem.
I've put the code, board design, and a bit of documentation on GitHub: jackcarrozzo/cs_adcs.
Monday, April 21. 2014
Adventures in Linux on Sun Netra T1
Thursday, March 13. 2014
rsyslog Remote Logging
Tuesday, February 25. 2014
FPGA Dual DAC Board for QAM Synthesis
Building on the simplicity and success of my DAC board paired with my FPGA dev boards, today I threw together a board with an Altera Cyclone II, two DAC9000Es, an FT245R, and supporting periphery. I'll need to check it with fresh eyes tomorrow to ensure I haven't made any mistakes, but with luck I can submit the design tomorrow evening and have the boards next week.
My DAC+FPGA pair has proved extremely useful for transmitting test signals of various sorts, taking I+Q via USB and generating the output signal in code. But, at 160 MS/s, its max frequency is quite limited. This new board has two of the same DACs, however each will simply generate the I or Q signal alone which will then be combined with an LO in a dedicated QAM modulator chip. This allows for carrier frequencies limited only by the abilities of the QAM modulator chosen, and at 160 MS/s the usable Tx bandwidth will be huge.
I've chosen to terminate the DACs in SMA connectors and leave the modulator off the board entirely, as I'd like to evaluate a few different chips. Unfortunately this board will be too large for me to mill at home at the moment, but I can still quickly mill test boards for QAM modulators in about an hour.
My DAC+FPGA pair has proved extremely useful for transmitting test signals of various sorts, taking I+Q via USB and generating the output signal in code. But, at 160 MS/s, its max frequency is quite limited. This new board has two of the same DACs, however each will simply generate the I or Q signal alone which will then be combined with an LO in a dedicated QAM modulator chip. This allows for carrier frequencies limited only by the abilities of the QAM modulator chosen, and at 160 MS/s the usable Tx bandwidth will be huge.
I've chosen to terminate the DACs in SMA connectors and leave the modulator off the board entirely, as I'd like to evaluate a few different chips. Unfortunately this board will be too large for me to mill at home at the moment, but I can still quickly mill test boards for QAM modulators in about an hour.
Thursday, February 20. 2014
WWVB Receiver and Testing Transmitter
As I've been making steady progress on my Z80 computer, I've put a lot of thought into something to actually do with it when it's done. As tempting as it is to load up CP/M, add a video interface, and use it as my main machine, I think porting Firefox is too ambitious. For now, I've decided to add some more 7-segment displays and an RF front end to decode the WWVB time signal from an atomic clock in Colorado and hang it on the wall. If I'm still feeling ambitious, I'll add an Ethernet controller and write a driver and NTP daemon for it. Of course, this means I need a working receiver front end for 60kHz.
The WWVB signal is quite simple as far as decoding goes: the carrier has "full power" and "low power" states. The transmitter drops the carrier by 17 dB at the start of each second, and the length of time before it returns provides a single trinary value: Mark (0.8s), Not Set (0.2s), or Set (0.5s). A single digital line that goes low or high to follow the transmitter power state is quite easy to achieve with a fully analog circuit: after a bandpass to select only the 60kHz carrier, we send the signal into two peak detectors - one with a long time constant (low pass filter) to track the average signal power over several seconds, and one with a shorter time constant to track the per-second changes. Passing these two signals to a comparator, we get our nice single-bit TTL indicator of the current signal state. Plus, the longer time constant peak detector acts as an auto gain control, so no alignment is required.
While I will make my own receiver as described above for the final version, I ordered a SYM-RFT module for testing. It includes an LED to indicate received carrier status and outputs the inverted carrier power state compared to the average carrier power. I quickly breadboarded it up to an FT245R USB chip and wrote a few lines of C to poll the power status and measure the length of state changes. Unfortunately, New England being quite far from Colorado, the signal is below the noise floor and has thus far been highly unreliable. The module simply flashes chaotically in the presence of any electronic noise like my monitors, and does nothing in isolation.
I built the above two-stage preamp from two 2N3904's to attach to the 60kHz antenna that came with the SYM-RFT module to see if I could see any carrier on the oscilloscope. While I did get all sorts of noise and impulses, there was very little if any energy at 60kHz. Drat.
Luckily, I have the tools on hand to recreate the signal so I can at least test my receiver and code. I pulled out the FPGA RF DAC board I put together a while back, and a page of Verilog later I had a compliant WWVB transmitter:
After a small battle with PLLs to get a slow enough clock for 60khz, both the SYM-RFT and my USB worked fine.
jackc@ichor ~/Projects/wwvb_usb $ sudo ./wwvb
MARK : 950 ms
NOT SET : 239 ms
SET : 503 ms
NOT SET : 194 ms
SET : 581 ms
MARK : 991 ms
^Cjackc@ichor ~/Projects/wwvb_usb $
The WWVB signal is quite simple as far as decoding goes: the carrier has "full power" and "low power" states. The transmitter drops the carrier by 17 dB at the start of each second, and the length of time before it returns provides a single trinary value: Mark (0.8s), Not Set (0.2s), or Set (0.5s). A single digital line that goes low or high to follow the transmitter power state is quite easy to achieve with a fully analog circuit: after a bandpass to select only the 60kHz carrier, we send the signal into two peak detectors - one with a long time constant (low pass filter) to track the average signal power over several seconds, and one with a shorter time constant to track the per-second changes. Passing these two signals to a comparator, we get our nice single-bit TTL indicator of the current signal state. Plus, the longer time constant peak detector acts as an auto gain control, so no alignment is required.
While I will make my own receiver as described above for the final version, I ordered a SYM-RFT module for testing. It includes an LED to indicate received carrier status and outputs the inverted carrier power state compared to the average carrier power. I quickly breadboarded it up to an FT245R USB chip and wrote a few lines of C to poll the power status and measure the length of state changes. Unfortunately, New England being quite far from Colorado, the signal is below the noise floor and has thus far been highly unreliable. The module simply flashes chaotically in the presence of any electronic noise like my monitors, and does nothing in isolation.
I built the above two-stage preamp from two 2N3904's to attach to the 60kHz antenna that came with the SYM-RFT module to see if I could see any carrier on the oscilloscope. While I did get all sorts of noise and impulses, there was very little if any energy at 60kHz. Drat.
Luckily, I have the tools on hand to recreate the signal so I can at least test my receiver and code. I pulled out the FPGA RF DAC board I put together a while back, and a page of Verilog later I had a compliant WWVB transmitter:
After a small battle with PLLs to get a slow enough clock for 60khz, both the SYM-RFT and my USB worked fine.
jackc@ichor ~/Projects/wwvb_usb $ sudo ./wwvb
MARK : 950 ms
NOT SET : 239 ms
SET : 503 ms
NOT SET : 194 ms
SET : 581 ms
MARK : 991 ms
^Cjackc@ichor ~/Projects/wwvb_usb $
Tuesday, February 11. 2014
Z80 Proto Coming Along Nicely
I've rebuilt my previous Z80 computer and have been adding several peripherals of late. I think that ultimatly, after I decide the final design, I'll rebuild the whole thing to look pretty and be better laid out for higher clock speeds, but for now I'm continuing to prototype here.
As it stands, I have the following systems configured:
CPU: Z80A - While I have some later devices with more features and faster clocks on hand, I'm testing base functionality with a run-of-the-mill original.
Flash: W29C020 - Boot ROM. The device is 256 kB, but I'm only using 32k (memory map is split between RAM and ROM). Technically I could enable write functionality to the flash, but haven't done so thus far as I haven't needed it.
SRAM: W24257AK - 32k. Haven't implemented any MMU or paging, but it would be trivial to do so in the future if need be.
Address Decoding and Glue: 74LS138, 74LS32, 74LS04 - Some people use PLAs or GALs to do this in a single device, but I have an attachment 7400 series logic.
General Purpose IO: 8255A - Provides three 8-bit ports per chip. Right now ports A and B are tied to 7-segment displays via 74LS244 octal buffers. Rather than use 7447 7-segment decoders to save 4 bits, I connected the displays directly so that I can display the A-F characters correctly via a map in ROM. This has been quite helpful while writing the BIOS.
Timing: Z8430APS CTC - This guy provides four counter channels with a handy list of prescalers and vectored interrupt features. Right now the BIOS configures channel 0 to send an interrupt every 10ms for polling routines, and channel 1 to provide a compatible baud rate clock to the DART.
Async Serial: Z8470APS DART - Contains a whole slew of serial comm features. Currently the BIOS configures channel A for 9600 8N1 and transmits debugging information through it.
System Clock: 10MHz Osc + 74LS163 Counter - The 4-bit counter provides clocks at 5, 2.5, 1.25, and 0.625 MHz, selectable via pin header. The 555 in the upper-left corner provides a 10kHz clock signal for visual debugging also, but at this point the BIOS is far too long to sit around waiting for it to boot at that clock speed.
Reset Controller: Analog! - At power on, a 1uF capacitor is slowly filled through a 1Mohm resistor to Vcc. When its voltage exceeds that set be a voltage divider (1/2 Vcc here), a comparator (TLC3702) releases the RESET_ assertion. A switch between ground and the capacitor provides another way to trigger a reset.
So far so good! Hopefully I don't jinx myself here, but I haven't made a single wiring mistake yet. I have the logic analyzer sitting here ready, but every time I've added a new chip the unit has just booted right up and worked flawlessly - I can't believe it, given the sheer number of connections.
By the way, I forked the assembler and fixed a few tiny things. Check it out on GitHub: z80asm. Also, I've spent a good bit of time writing emulations of the 8255, CTC, and DART in C as well as fixing the interrupt handling in my fork of z80sim: see my fork here. The file containing the my chip emulations is io.c (a work in progress at the time of writing).
As it stands, I have the following systems configured:
CPU: Z80A - While I have some later devices with more features and faster clocks on hand, I'm testing base functionality with a run-of-the-mill original.
Flash: W29C020 - Boot ROM. The device is 256 kB, but I'm only using 32k (memory map is split between RAM and ROM). Technically I could enable write functionality to the flash, but haven't done so thus far as I haven't needed it.
SRAM: W24257AK - 32k. Haven't implemented any MMU or paging, but it would be trivial to do so in the future if need be.
Address Decoding and Glue: 74LS138, 74LS32, 74LS04 - Some people use PLAs or GALs to do this in a single device, but I have an attachment 7400 series logic.
General Purpose IO: 8255A - Provides three 8-bit ports per chip. Right now ports A and B are tied to 7-segment displays via 74LS244 octal buffers. Rather than use 7447 7-segment decoders to save 4 bits, I connected the displays directly so that I can display the A-F characters correctly via a map in ROM. This has been quite helpful while writing the BIOS.
Timing: Z8430APS CTC - This guy provides four counter channels with a handy list of prescalers and vectored interrupt features. Right now the BIOS configures channel 0 to send an interrupt every 10ms for polling routines, and channel 1 to provide a compatible baud rate clock to the DART.
Async Serial: Z8470APS DART - Contains a whole slew of serial comm features. Currently the BIOS configures channel A for 9600 8N1 and transmits debugging information through it.
System Clock: 10MHz Osc + 74LS163 Counter - The 4-bit counter provides clocks at 5, 2.5, 1.25, and 0.625 MHz, selectable via pin header. The 555 in the upper-left corner provides a 10kHz clock signal for visual debugging also, but at this point the BIOS is far too long to sit around waiting for it to boot at that clock speed.
Reset Controller: Analog! - At power on, a 1uF capacitor is slowly filled through a 1Mohm resistor to Vcc. When its voltage exceeds that set be a voltage divider (1/2 Vcc here), a comparator (TLC3702) releases the RESET_ assertion. A switch between ground and the capacitor provides another way to trigger a reset.
So far so good! Hopefully I don't jinx myself here, but I haven't made a single wiring mistake yet. I have the logic analyzer sitting here ready, but every time I've added a new chip the unit has just booted right up and worked flawlessly - I can't believe it, given the sheer number of connections.
By the way, I forked the assembler and fixed a few tiny things. Check it out on GitHub: z80asm. Also, I've spent a good bit of time writing emulations of the 8255, CTC, and DART in C as well as fixing the interrupt handling in my fork of z80sim: see my fork here. The file containing the my chip emulations is io.c (a work in progress at the time of writing).
Tuesday, January 14. 2014
Z80 Computer and Assembler Adventures
I recently pulled out the Z80 project computer I built several years ago in the hopes of adding some hardware and features to it, but was sad to find that it didn't want to operate in the slightest. A quick connection of the logic analyzer showed that the CPU was not fetching instructions. Hrm. I needed to determine if my delicate, hand-wired little computer was at fault somewhere, or if the CPU itself was upset.
First, I breadboarded the following setup to test the Z80. Since the opcode for the NOP instruction is 0x00, setting the data bus to zeros and providing correct external state causes the chip to simply count up the address bus when clocked. I pulled the data bus to 0s with 1k resistors since the chip is in an undefined state before reset and could attempt to write to the bus - bad news if you're tied to a rail. I then set WAIT_, INT_, NMI_, and BUSREQ_, leaving just a RESET_ and a clock source to add.
I really like the simplicity of Z80: not only can I run the chip with only four pullups and no external components, but it will run with clock speeds all the way down to DC. That means you can single step your computer with a debounced push button as your clock - try that on a modern CPU! For this particular exercise, I rigged a 555 timer to generate a 10hz clock - slow enough to watch the address bus with LEDs.
At the moment of truth, I got... nothing. The chip was tri-stating the address bus and not responding to RESET_. Unfortunately this meant I needed to dig deep into the depths to locate my box of Z80 items that I hadn't seen since college. However, not only did I find the box I was looking for quite quickly, I found a downright awesome pile of parts in there! I recalled that I had 3 extra Z80s and two 82C55's, but in reality I owned 16 Z80s of different vintages and speed grades, a few different types of 82C55, and an awesome pile of Z84 family peripheral controllers. I was very pleased.
Back at my desk, I tested all 17 CPUs (the one that was in my computer, plus the 16 extra ones I had). It turns out that all of my spares are in perfect working condition, and the one in the computer was in fact dead as a door nail. Good to know!
Next, I put a working CPU back in the computer, then wrote, assembled (using z80asm-1.2), and burned the following test program into flash:
LD A,0x80 ; 1000 0000 - tell the 82C55 to set all ports to outputs
OUT (3),A ; 0x03 is the control word address
LD A,1 ; set one bit that we will rotate in the loop
loop: OUT (0),A ; put the word out on port A of the 82C55
NOP
RLCA ; left-rotate reg A
JP loop
Sure enough, it worked great in hardware. Unfortunately, I decided to test the code in an emulator before running the hardware, and ended up spending many hours debugging and rewriting the emulator's memory loading functionality to be properly endian-safe and to autodetect binary blob types, but I'll leave that rant for another time. In any event, this was a great refresher in Z80 architecture and assembly as well as the interworkings of the emulator. Now that my Z80 computer is working, I have no excuse not to add more cool things to the project...
First, I breadboarded the following setup to test the Z80. Since the opcode for the NOP instruction is 0x00, setting the data bus to zeros and providing correct external state causes the chip to simply count up the address bus when clocked. I pulled the data bus to 0s with 1k resistors since the chip is in an undefined state before reset and could attempt to write to the bus - bad news if you're tied to a rail. I then set WAIT_, INT_, NMI_, and BUSREQ_, leaving just a RESET_ and a clock source to add.
I really like the simplicity of Z80: not only can I run the chip with only four pullups and no external components, but it will run with clock speeds all the way down to DC. That means you can single step your computer with a debounced push button as your clock - try that on a modern CPU! For this particular exercise, I rigged a 555 timer to generate a 10hz clock - slow enough to watch the address bus with LEDs.
At the moment of truth, I got... nothing. The chip was tri-stating the address bus and not responding to RESET_. Unfortunately this meant I needed to dig deep into the depths to locate my box of Z80 items that I hadn't seen since college. However, not only did I find the box I was looking for quite quickly, I found a downright awesome pile of parts in there! I recalled that I had 3 extra Z80s and two 82C55's, but in reality I owned 16 Z80s of different vintages and speed grades, a few different types of 82C55, and an awesome pile of Z84 family peripheral controllers. I was very pleased.
Back at my desk, I tested all 17 CPUs (the one that was in my computer, plus the 16 extra ones I had). It turns out that all of my spares are in perfect working condition, and the one in the computer was in fact dead as a door nail. Good to know!
Next, I put a working CPU back in the computer, then wrote, assembled (using z80asm-1.2), and burned the following test program into flash:
LD A,0x80 ; 1000 0000 - tell the 82C55 to set all ports to outputs
OUT (3),A ; 0x03 is the control word address
LD A,1 ; set one bit that we will rotate in the loop
loop: OUT (0),A ; put the word out on port A of the 82C55
NOP
RLCA ; left-rotate reg A
JP loop
Sure enough, it worked great in hardware. Unfortunately, I decided to test the code in an emulator before running the hardware, and ended up spending many hours debugging and rewriting the emulator's memory loading functionality to be properly endian-safe and to autodetect binary blob types, but I'll leave that rant for another time. In any event, this was a great refresher in Z80 architecture and assembly as well as the interworkings of the emulator. Now that my Z80 computer is working, I have no excuse not to add more cool things to the project...
Monday, November 18. 2013
Vectorplot
Since I don't own a vector analyzer, I've been working on a software implementation for the RTL SDR in flat C (using libusb1) and X11 so I can test my FPGA QAM code. It actually turned out to be much simpler than expected, and is working well thus far.
Right now it plots raw I and Q values on the plane as well as calculated FFT data. Since I haven't implemented clock recovery yet, signals appear as a circle (recall that for a frequency difference of N hz between the incoming signal and the sampling frequency, an N hz rotation around the IQ plane results - thus even a difference of a few hz is too quick to see anything but a circle). That shouldn't be very hard, and at that point it will become fully usable as a vector analyzer.
Code is here: https://github.com/jackcarrozzo/vectorplot.
Right now it plots raw I and Q values on the plane as well as calculated FFT data. Since I haven't implemented clock recovery yet, signals appear as a circle (recall that for a frequency difference of N hz between the incoming signal and the sampling frequency, an N hz rotation around the IQ plane results - thus even a difference of a few hz is too quick to see anything but a circle). That shouldn't be very hard, and at that point it will become fully usable as a vector analyzer.
Code is here: https://github.com/jackcarrozzo/vectorplot.
Saturday, October 26. 2013
Canon Video Comparison: T3i (600d) vs 7d
Tuesday, October 22. 2013
Gyro-Stabilized DSLR Platform
I finally had time to put together one axis of my DSLR gyro frame today, and I am quite pleased with the results. The frame is big and heavy as it was originally intended to be a fixed-mount azimuth-altitude star and satellite rig for taking long exposures of planets and orbiting things, but it happened to be a good test bed for my gyro code. It's rock solid thus far:
Hopefully I will find time to build another axis soon so I can really see how solid both my math and my sensor are. I have a huge list of epic features to add to the project, too. I'm hoping I can get it solid enough to film with a 300mm lens and not need post-process stabilization.
Hopefully I will find time to build another axis soon so I can really see how solid both my math and my sensor are. I have a huge list of epic features to add to the project, too. I'm hoping I can get it solid enough to film with a 300mm lens and not need post-process stabilization.
Wednesday, August 21. 2013
Geiger Counter
I haven't done a whole lot of analog or power supply design, so I thought it'd be an interesting project to build a simple Geiger counter. In theory, their operation is very simple: provide ~500 vdc to the tube, and incoming particles will ionize the gas inside long enough to change the impedance of the tube, which we measure with a high-pass filter.
To create 500 volts from a 9v input (I'd like it to be portable), I used a 555 timer at 1khz to gate two 2n222 NPN transistors ground-side switching the input to the transformer. I tried a few HV transformers I had in the junk bin, but nothing was quite right, so I ordered a few CTX110607-R's which performed splendidly.
From the output of the transformer, we go through two stages of voltage doubler (the last one acting as a rectifier and low pass filter), and voltage regulation is provided by two 200v zeniers and one 100v zenier.
The signal is separated from the HV rails by a 50pf capacitor, which then goes to a comparator with one more filter between its two stages. This let me use a fast high-pass and a peak detector, as opposed to a single slow-enough-to-see-and-hear high-pass filter.
After I confirmed my design with the mess on my desk, I soldered up a final version:
To create 500 volts from a 9v input (I'd like it to be portable), I used a 555 timer at 1khz to gate two 2n222 NPN transistors ground-side switching the input to the transformer. I tried a few HV transformers I had in the junk bin, but nothing was quite right, so I ordered a few CTX110607-R's which performed splendidly.
From the output of the transformer, we go through two stages of voltage doubler (the last one acting as a rectifier and low pass filter), and voltage regulation is provided by two 200v zeniers and one 100v zenier.
The signal is separated from the HV rails by a 50pf capacitor, which then goes to a comparator with one more filter between its two stages. This let me use a fast high-pass and a peak detector, as opposed to a single slow-enough-to-see-and-hear high-pass filter.
After I confirmed my design with the mess on my desk, I soldered up a final version:
Saturday, July 20. 2013
Sunset Jump
Tuesday, June 4. 2013
FPGA QAM Generation
I recently drew up a board to connect a fast DAC to FPGA dev boards for the purpose of RF generation. I chose the DAC900E from TI as it's fast (165MS/s), pretty accurate (10-bit), and extremely easy to interface (latches values in on clock edges, doesn't require any setup or external stuff).
Normally I'd cut a simple one-layer board like this on my CNC mill, but I wanted to try a low cost hobbyist PCB fab I read about via Sparkfun. The did take a very long while, but came out beautifully. Also, when the boards finally arrived, I was pleased I had picked a DAC with so few external requirements to solder. The resistors are there to prevent an output buffer short in case I soldered badly, by the way - I don't own a hot air rework setup.
Right off the bat, I was pleased to see that my sine-generation test code worked great at various frequencies and bit depths (aliasing visible in the 2nd pic, its harmonics in the 3rd):
With a bit more hacking, I got the FT245R interface to work such that I send I and Q values via USB, the output value is calculated from an LUT (I originally was doing the math out, but hardware multiply is very slow), and sent to the DAC. In these pics, you can see that I was generating a 500-hz tone over an AM carrier at 9.375 MHz (the 3rd image is the AM-demodulated signal shown on the spectrum analyzer).
My code is on Github here. It's by no means robust or feature-rich, but it does work well in my opinion. When I have time, I'd like to see how far I can take this design. Assuming I don't find any unforseen roadblocks, the next step will be to make a board with two DAC900Es for I and Q generation that feed into a GHz-range QAM modulator that takes its carrier from a PLL on the FPGA, which will theoretically give me full TX control over a wide range of freqs.
Normally I'd cut a simple one-layer board like this on my CNC mill, but I wanted to try a low cost hobbyist PCB fab I read about via Sparkfun. The did take a very long while, but came out beautifully. Also, when the boards finally arrived, I was pleased I had picked a DAC with so few external requirements to solder. The resistors are there to prevent an output buffer short in case I soldered badly, by the way - I don't own a hot air rework setup.
Right off the bat, I was pleased to see that my sine-generation test code worked great at various frequencies and bit depths (aliasing visible in the 2nd pic, its harmonics in the 3rd):
With a bit more hacking, I got the FT245R interface to work such that I send I and Q values via USB, the output value is calculated from an LUT (I originally was doing the math out, but hardware multiply is very slow), and sent to the DAC. In these pics, you can see that I was generating a 500-hz tone over an AM carrier at 9.375 MHz (the 3rd image is the AM-demodulated signal shown on the spectrum analyzer).
My code is on Github here. It's by no means robust or feature-rich, but it does work well in my opinion. When I have time, I'd like to see how far I can take this design. Assuming I don't find any unforseen roadblocks, the next step will be to make a board with two DAC900Es for I and Q generation that feed into a GHz-range QAM modulator that takes its carrier from a PLL on the FPGA, which will theoretically give me full TX control over a wide range of freqs.
Monday, March 25. 2013
Altera Quartus 12.1SP1 on Ubuntu 12.04 x86_64
Wednesday, February 20. 2013
All-Analog HF Transmitter
I'm going to Puerto Rico soon, and it just so happens we're staying on a beach facing the continental US. Since we won't have internet nor cell service while there, I thought it'd be fun to send tweets via HF as it would be a good excuse to building some simple analog radios. If I use slow synchronous CW driven and detected by FTDI dev boards and a few lines of C, all I need to do is hack up the radios themselves.
Starting at the TX end, I nabbed a gross piece of PCB from the pile and went to town dead-bugging the transmit chain. Yes, it looks like crap, but if it works as planned I'll design a proper board and cut it on the CNC mill. First I added the crystal oscillator, then its output buffer:
Nice! We can see from the spectrum analyzer that we are indeed getting waves, albeit with some fairly serious harmonics. Now to add a low pass filter:
In the first image, you can see that I added connectors between the previous stage's output and the filter's input so I can sweep the filter independently. In the next image, you can see the filter's response on the spectrum analyzer with the tracking generator providing a flat source. Finally, the last image shows our frequency response of the whole system (osc, buffer driver, and filter) - the filter successfully brought the first harmonic down to -54 dBc. Time to add another gain stage and filter:
In the first pic, I'm again using the tracking generator to sweep only the response of this amplifier and filter (note that I removed the BNC connector I tacked onto the input of the first filter, and connected it directly to the output of the osc buffer). In the second, the whole chain is hooked up end-to-end. It's putting out 27 dBm (1/2W) at ~7.2 MHz, but the last amplifier transistor get warm quickly - looks like I'm going to need to replace that with something beefier.
Update: Unfortunately I got wicked busy with work prior to leaving for PR and wasn't able to finish this. I do hope to pick it up again soon...
Starting at the TX end, I nabbed a gross piece of PCB from the pile and went to town dead-bugging the transmit chain. Yes, it looks like crap, but if it works as planned I'll design a proper board and cut it on the CNC mill. First I added the crystal oscillator, then its output buffer:
Nice! We can see from the spectrum analyzer that we are indeed getting waves, albeit with some fairly serious harmonics. Now to add a low pass filter:
In the first image, you can see that I added connectors between the previous stage's output and the filter's input so I can sweep the filter independently. In the next image, you can see the filter's response on the spectrum analyzer with the tracking generator providing a flat source. Finally, the last image shows our frequency response of the whole system (osc, buffer driver, and filter) - the filter successfully brought the first harmonic down to -54 dBc. Time to add another gain stage and filter:
In the first pic, I'm again using the tracking generator to sweep only the response of this amplifier and filter (note that I removed the BNC connector I tacked onto the input of the first filter, and connected it directly to the output of the osc buffer). In the second, the whole chain is hooked up end-to-end. It's putting out 27 dBm (1/2W) at ~7.2 MHz, but the last amplifier transistor get warm quickly - looks like I'm going to need to replace that with something beefier.
Update: Unfortunately I got wicked busy with work prior to leaving for PR and wasn't able to finish this. I do hope to pick it up again soon...
Wednesday, February 13. 2013
Exhaust Turbine Attempt
A few years ago, I built a gas turbine engine from an old car turbocharger with my friends Chris and Ken. Chris happens to work for a jet manufacturer for a living, so he knows a great deal about such topics. Chris and I have been plotting for some time to design a very simple two-stage axial flow single combustor engine, and the biggest thing holding us back is the ability to actually create the parts we design.
I spent some time playing with Aluminium (6061-T6) on my lathe to see if I could make a simple exhaust turbine wheel by separating a disk into fins and twisting them then sanding the edges into a semi-airfoil shape. First I roughed out the general shape I was going for, and drilled the hole through the center (my lathe bed isn't long enough to do so).
I then made the finish cuts to the exterior and with the boring bar to the interior to get the shape and approximate surface finish I was looking for.
Unfortunately, as I feared, the metal was too brittle to make the bend, and several fins broke off.
Oh well, at least now I know that method won't work...
I spent some time playing with Aluminium (6061-T6) on my lathe to see if I could make a simple exhaust turbine wheel by separating a disk into fins and twisting them then sanding the edges into a semi-airfoil shape. First I roughed out the general shape I was going for, and drilled the hole through the center (my lathe bed isn't long enough to do so).
I then made the finish cuts to the exterior and with the boring bar to the interior to get the shape and approximate surface finish I was looking for.
Unfortunately, as I feared, the metal was too brittle to make the bend, and several fins broke off.
Oh well, at least now I know that method won't work...
Email me:
jack {@} crepinc.com
Recent Projects:
Analog HF Transmitter
Audi ECU Reverse Engineering
Dual DAC QAM Modulator
FPGA QAM Modulator
Geiger Counter
Gyro-Stabilized DSLR Platform
Hybrid Rocket Engines
Turbocharger Controller
WWVB Rx and Tx
Older Projects:
Balancing Bot
Capacitor Array
CNC Mill
DCIR Renderer
Electric Gokart
Hovercraft
Low Alt. Temp. Model
Shopping Cart Locker
Trebuchet
My Twitter occasionally shows projects I'm working on.
My GitHub has code from a few projects on it.
jack {@} crepinc.com
Recent Projects:
Analog HF Transmitter
Audi ECU Reverse Engineering
Dual DAC QAM Modulator
FPGA QAM Modulator
Geiger Counter
Gyro-Stabilized DSLR Platform
Hybrid Rocket Engines
Turbocharger Controller
WWVB Rx and Tx
Older Projects:
Balancing Bot
Capacitor Array
CNC Mill
DCIR Renderer
Electric Gokart
Hovercraft
Low Alt. Temp. Model
Shopping Cart Locker
Trebuchet
My Twitter occasionally shows projects I'm working on.
My GitHub has code from a few projects on it.