Altera EPM3256A CPLD Breakout

A few months ago I received my newly designed breakout boards from Laen's OSH Park PCB service and finally had time to assemble my new boards. Stepping up from my original EPM3032A board I went to the EPM3256A here in its final assembled form:

With this new board I only broke out about 100 or so pins of the 208 pin package, this will be more than enough for the projects I have planned with it. I added a few features to it including an on-board socketed crystal with options for 3.3v or 5v operation. I also have options to route the clock to the global clock input or a specified general purpose io pin depending on the application.

A couple nice features about the MAX3000 series specifically to the EPM3256A:

- 3.3v and 5v compatibility. Makes interfacing existing logic very easy.
- 256 macrocells available. Small compared to modern FPGAs, but is enough to be very useful.
- 158 Usable i/o pins.

I will be posting some projects based on this board very soon.

New Spectrum Analyzer: Anritsu MT8801C

The Spectrum Analyzer is by far the most important piece of gear for any RF design work, unfortunately spectrum analyzers are also one of the most costly pieces of gear you can buy (A VNA is right up there too, but that's a different post). I have had access to spectrum analyzers at a few previous jobs which is great whenever you need to test your latest RF design. The problem is when you are at home working at your own bench at 2am,  it's annoying to not be able to have access to this gear all of the time. Buying an analyzer is ideal, but costly. Anything new is pretty much out of the question, so the usual source of eBay is the place to go. Both Tektronix and HP/Agilent have some amazing pieces of gear for an 'affordable' amount (the Tek 49N series and HP 85NN series come to mind), the problem is any of these models can easily cost over $1000 in good working condition. The other issue with this equipment (like all older gear) is their age. Since most were used in a production or lab environment, they have been powered on for 8 hours a day for years. This can result in some crt burn in, the devices being way out of calibration, instabilities and other problems as most of the equipment in this class is 15+ years old (note that makes it affordable). I have had a good run with all my HP / Tek gear as this equipment is really built extremely well. As an example, my HP8614A signal generator was built in the 1960s and still works perfect today. So what happens if you want a spectrum analyzer but don't want to spend $1000+? As I found, there are a few options:

1. Buy a really old analyzer. Some of the older HP models will go for under $500. Keep in mind that these models usually have a max frequency range of no more than a few hundred Mhz.

2. Buy a lesser known brand. There are a handful of analyzers by Chinese companies that go for cheap. They may be perfectly fine, I just prefer to go with a good established brand if I'm going to invest in one.

3. Watch local auctions. There are a ton of company liquidation auction houses such as Dovebid that sell off large companies test equipment assets. These are great places to pick up gear. The issue with this is that there is no guarantee that the gear works (no one tests it) and if it is a valuable piece it will most likely get bid up pretty high. Packing and shipping can cost hundreds of dollars as well if you are not able to pick up the gear locally.

4. My favorite option. Buy gear whose primary purpose is not a spectrum analyzer, but has an analyzer hiding inside it. A lot of communication analyzers and cell phone test sets have an available spectrum analyzer option. I will look up unusual gear on eBay that seems to be selling for cheap and read the product literature on them. You will be surprised on what you will find. I have purchased both of my spectrum analyzers this way.

My first spectrum analyzer that I bought a few years ago is an HP8922H GSM test set. It is designed to replicate a GSM cell station to test GSM cell phones. It also has a bunch of options included one of which is option 006, a 10Mhz to 1Ghz spectrum Analyzer. You can find these for around $500 or less. Now 1Ghz is great, but you eventually reach the limits of what you can do with it. One of my current projects is building a hydrogen line radio telescope which at 1420Mhz is outside of my analyzers reach. I needed something to at least 2Ghz at this point to test my down converter so I began my search again.

While recently looking at more gear that was available I came across an Anritsu MT8801C radio communication analyzer. Not being familiar with Anritsu as most of my gear is HP/ Agilent and Tektronix, I did a bit of research into this particular model and discovered that not only was it an amazing piece of gear, but much like my HP8922H, it has an option for a 300Khz to 3Ghz spectrum analyzer (Option 07):

Being a communications analyzer it has a bunch of other nice features such as a 300Khz to 3Ghz RF frequency generator, and an RF power meter:

 

 

Here is a full span of 300Khz to 3Ghz to my outside wideband antenna:

A couple nice things about this analyzer is that it has a large LCD screen, is capable of displaying a full frequency span, it has a resolution of 1Hz, and a very fast interface. I checked its calibrated accuracy with my HP 8656B RF generator and it was spot on which made me very happy as well:

The additional 3dBm loss above is from the mini-circuits splitter I was using between the generator and analyzer.

Included with this unit was a nice shielded RF test chamber for no extra cost. I can only guess what this had cost new:

 

It will be a great tool for testing devices within a completely shielded environment from external interference.

 

So all said and done this complete setup cost less than $600. Quite a steal considering new this was a $30K+ piece of gear. With that being said I'm finally excited to test my down converter further and also get my RF front end for my radio telescope underway.

21cm Line Downconverter Testing

This project is the heterodyning downconverter I have designed and assembled for radio astronomy purposes. It will be used to convert 1420Mhz Hydrogen Line reception from my 10' dish and feedhorn / LNA assembly down to a more manageable frequency of 100Mhz or so. It consists of a mini-circuits mixer along with a Z-Comm VCO for the LO. This particular VCO has a frequency range of 850Mhz to 1600Mhz, ideally covering the 1420Mhz band. A few mini-circuits low noise mmics are used for amplification along with a mini-circuits low pass filter to filter out the original LO and source frequencies.

Last week after returning from vacation I received my downconverter boards and started assembly. Here is the final assembled downconverter ready for testing:



This downconverter as I began testing has excellent performance. I need to do some further testing and measuring to calculate its noise and gain, but I have been very pleased so far. Because of the flexibility of the VCO, I have had some fun during testing downconverting and also upconverting various frequencies around, the following video show upconversion of FM bands to 900Mhz:

PIC18F C18 Implemented I2C Slave Communication

So after many hours of wasted time I was able to successfully implement an I2C slave device on a PIC18F25K20. What seemed to be a simple task to implement as PIC18F device as an I2C slave ended up being a significant amount of work. This was not because I2C is a complex protocol (it's not), but a combination of attempting to use the built in Microchp C18 compiler I2C libraries for a slave device along with trying to save time by not fully reading the datasheets. This ended up wasting a lot of time. Much searching for the issue turned up with lots of results of people with the same issue, but often as you find in forums, no one had an actual answer to why it wasn't working ( as in no one could get it working! ). My intention here is to clear up this issue and explain what you must do to make a PIC18 work as an I2C slave device. This will not be an I2C tutorial, a good understanding of I2C along with an understanding of the Microchip PIC18 series and C18 libraries will make things more clear.

Using Microchips C18 compiler with the C18 libraries has been very straightforward when using a PIC18F series microcontroller as an I2C master device. If you wanted to write a single byte of data to a slave device with an address of say 0xB0, it can be implemented in the following way:


OpenI2C( MASTER, SLEW_OFF);
SSPADD = 0x27; //SSPADD Baud Register used to calculate I2C clock speed in MASTER mode (in this case 100Khz)

StartI2C();
IdleI2C();
putcI2C( 0xB0 ); //send address
IdleI2C();
putcI2C( databyte ); //send data
IdleI2C();
StopI2C();


This code is simply placing the target device address onto the I2C bus, the upper seven bits of this byte contain the devices address with the lsb bit indicating whether the op will begin a read(0) or a write(1). The data byte is then sent following the address. A standard I2C diagram will explain this the most clearly including the Ack and NAck data.



While still in master mode, reading data from an I2C device can be easily done as well. The following code can be used to read two bytes of data from an I2C slave device from a PIC18 micro operating in master mode:


StartI2C(); // Start condition
IdleI2C();
WriteI2C( 0xB0 ); // addresses the chip with a read bit
IdleI2C();
inbit = ReadI2C(); // read the value from the RTC and store in result
IdleI2C();
AckI2C();
IdleI2C();
inbit2 = ReadI2C(); // read the value from the RTC and store in result
IdleI2C();
NotAckI2C();
IdleI2C();
StopI2C(); // Stop condition I2C on bus


This is also clarified by looking at I2C timing:



Now things become tricky when you want to use two PIC18F devices where one is a master device while the other is a slave. Utilizing the I2C libraries, you would think that implementing something like this on the Slave device would work:


OpenI2C( SLAVE_7, SLEW_OFF);
SSPADD = 0xB0; //SSPADD contains I2C device address in SLAVE mode

while ( !DataRdyI2C() )
{
addr = ReadI2C();
AckI2C();
IdleI2C();
data = ReadI2C();
NAckI2C();
IdleI2C();
}


What the above is attempting to do is wait until the SSPBUF register contains address data, when it does read the byte, acknowledge, wait until the next byte, read that byte, then NAck the data. Of course any data that appears on the bus will not be accepted by the specific PIC at all, so if SSPBUF does ever contain data it will be destined for this device. Another important note is the SSPBUF register will contain the address that is sent upon first byte received. The ReadI2C() function will clear this buffer so even if we have no need for the data, it still must be read.

Now you can play with this code all you want adjusting timing, Ack and NAck sequencing, delays, etc... but ultimately it will not do what you would like it to do / think it should do. Why? Looking into the C18 I2C libraries themselves you will see that some of the functions will only work in MASTER mode, or put simply they were not designed to be used in SLAVE mode. This is where most of my time was wasted.

The solution? Read the datasheet and application notes, one particular app note in particular AN734 will tell you everything you need to know. I would recommend reading AN734 fully if you really want to understand slave communication on a PIC18F. Instead of attempting to modify the C18 I2C predefined functions I decided to implement my own at the register level. Here are the important registers and bits within the PIC18F25K20 (among others) you need to be aware of:


SSPBUF : Serial TX/RX data buffer.
PIR1bits.SSPIF : Interrupt flag bit. This will be 1 when data is received into SSPBUF
SSPSTATbits.BF : SSPBUF buffer full status bit. 1 = full, 0 = empty.
SSPSTATbits.D_A : Data / Address bit. When receiving it indicates what the data received was. 0 = address, 1 = data.


With the above data you can easily implement I2C slave data reception, so here is how. There are two ways you can handle data received. If you code timing is critical, the best and preferred method will be to implement an ISR and place the code within it. If the timing on your device is not as critical you can implement the code in a separate function or within your main loops themselves. Implementation will be up to you.

If you are looking for an interrupt, your ISR will be ran when PIR1bits.SSPIF == 1. Alternately you can look for a few thing to be true while would indicate that a first address byte has been received. Checking for the following will guarantee this case:

if ( PIR1bits.SSPIF == 1 && SSPSTATbits.BF == 1 && SSPSTATbits.D_A == 0 )

With this you are checking to see that an interrupt has been received, SSPBUF is indeed full, and SSPBUF contains an address (not data).
From there you will need to immediately clear the interrupt flag.

PIR1bits.SSPIF = 0;

Then read the byte in SSPBUF

addr = SSPBUF;

Note that the addr byte may not need to be read at all so you can skip this read if not necessary, but be sure to then clear the SSPBUF BF bit. If this is not cleared the next byte sent will cause an SSP overflow resulting in a NAck condition. Reading SSPBUF automatically clears the BF bit.

SSPSTATbits.BF = 0;

Now that the data has been read and/or the BF bit has been cleared you can prepare to receive the data. Depending on the speed of your I2C bus, the speed of your microntrollers, etc the data byte may have already arrived. Before reading SSPBUF blindly as we don't exactly know what is there, we can perform the following check:

if ( PIR1bits.SSPIF == 0 && SSPSTATbits.BF == 0 && SSPSTATbits.D_A == 1 )

This checks to see if an interrupt has been received, SSPBUF is indeed full again, and SSPBUF contains data (not an address). If all checks out we can then read the data byte:

data = SSPBUF;

Now that we have our data we have to do some further housekeeping:

PIR1bits.SSPIF = 0; //clear interrupt
SSPSTATbits.D_A = 0; //set D_A bit to 0 so that we can check if the subsequent byte is more data.

If you wish to receive more than a single byte of data you can then loop through the checks again waiting for each additional byte of data. If you continue to have trouble receiving data from the master, try adding a delay between the first address byte and data byte to be sent on the master. If you are still seeing issues, slow your I2C bus speeds down so you can more clearly see what is going on. A logic analyzer can also instantly show you what is going on with your data. Remember to also watch timing. I was using a 100Khz SCL in the above examples which is slow enough to keep things under control. If you are using a 400Khz SCL (or faster) be sure to enable clock stretching to keep things manageable. Without clock stretching, your ISR may not have enough time to read SSPBUF before the master sends another byte of data.

ALTERA EPM3032A CPLD Breakout Board

Recently I came across a large quantity of NetApp DS14 Filers that were being disposed of which are basically Fiber Channel shelves full of FC drives. While a few of these ended up in my basement 48U rack for FC attached storage, the rest I scavenged as many parts from as possible. These shelves have removable modules depending on the interfaces required. On these modules two parts caught my eye:



Two ALTERA CPLDs from the Max 3000 family. An EPM3256A and an EPM3032A. While I was excited about both devices, the EPM3032A I was initially more excited for as it is a more manageable package size.

After removing about 10 or so of these CPLDs from the boards I went ahead and designed a simple breakout board in Eagle. All 44 pins are broken out and I included an onboard 3.3V regulator along with a JTAG connector. Upon receiving the boards I threw one together, wrote a simple 4 bit counter in VHDL in Quartus II and downloaded to the CPLD via JTAG to see it worked perfectly.



The EPM3032A is not a large CPLD, with only 32 macrocells it's by no means a device for large scale logic implementations. The 4 bit counter ended up using 4 macrocells or 13% of the usable space in the CPLD, but it is perfect when you need a small custom logic device where many individual chips would be required. I'll be working on a breakout for the more powerful EPM3256A soon.

XBee Based Datacenter Temperature Monitoring Network

Temperature monitoring and control is extremely crucial for any datacenter. I work for a hosting company who has several thousand servers running producing enormous mounts of heat. To battle the BTU output of these servers you must have hundreds of tons of cooling running all the time to keep everything operating under control. Monitoring the datacenters temperature is important in more ways than you think. In the event of a cooling failure, servers will begin to overheat extremely quickly, this in turn causes them to raise the speed of their internal fans to full speed to combat the internal heat. For one server this may not be so bad, but when 1000+ servers do it your total power consumption increases drastically. This can then cause circuits to draw more current which in turn heats them up further increasing the overall temperature in the facility. Servers CPUs will then begin to be throttled by the bios to cool them down which can hurt websites performance. Datacenters internally can actually reach high enough temperatures over 100 degrees Fahrenheit were circuit breakers begin to trip and large 150KVA+ UPS battery backup systems can actually fail from the high temperatures and the increased load they are seeing. Thermal expansion can also come into play causing wire lugs to come loose on UPS inputs and transformers further causing points of failure.

All of this is why reliable temperature monitoring is so crucial. Being able to monitor temperatures throughout a facility can keep you ahead of any potential failure. Commercial temperature monitoring systems are available, but they are extremely expensive and limited on their placement. If you have a 10,000+ square foot facility, monitoring the temperature everywhere could be extremely expensive and difficult to implement. So for all these reasons I wanted to design a system that was very inexpensive and easy to implement anywhere you needed it. Specifically I wanted to not only monitor ambient air in both hot and cold aisles, but also be able to monitor temperatures inside circuit panels and PDUs. Being able to measure a increase in temperature within the circuit panel or PDU itself could indicate a potential failure way ahead of time allowing it to be addressed before it causes a dangerous situation.

My solution was to build a simple temperature monitoring network that was ideal for a datacenter environment. When beginning the design process I came up with the following requirements that it needed to meet:

1.Inexpensive. Commercial temperature monitoring systems are very expensive. I wanted my sensors to be inexpensive enough where you could place them in locations that you would not normally be able to place a temperature sensor because of cost reasons.
2.Wireless. Most existing temperature systems are wired, which is silly in my opinion based on the inexpensiveness of existing XBee based wireless modules. This saves the need of having to run additional wires to each sensor and increases placement flexibility.
3.Easily expandable. I wanted to make sure that I could add additional sensors into the system at any time without hitting any limits on the amount of sensors, within reason.
4.Reliable. Previous systems I used were dumb in the fact that the sensors would sometimes have errors collecting data. This would in turn wake me up at 4am telling me the datacenter was at 150+ degrees Fahrenheit, then instantly back to 70 degrees. This was just annoying.

This is the design of my first three prototype sensors I made:




Each sensor is based on a PIC 18F25K20 microcontroller driven by a 16Mhz oscillator. An XBee module provides the wireless connectivity while a TI TMP100 I2C based temperature sensor monitors the current temperature condition. The TMP100 is one of my favorite chips, it is inexpensive, has 12 bit resolution, and has a wide temperature range. Now I know I could have easily made these much smaller by using all smd based components The PIC I chose is way overkill for the job anyway, but I had a large quantity of these in my parts bin left over from previous designs so I used them as I hate having parts sit around unused.

The software on the PIC simply reads the temperature from the TMP100 every 60 seconds and sends the temp along with a unique device ID to the XBee. The data it sends is also encrypted to prevent anyone from injecting rogue temperature data into my monitoring network. If someone really wanted to they could probably crack the encryption over time. I guess if they just really want to wake me up at night I'll have to implement even stronger encryption. ;)

The receiving end is PHP based. An Xbee / Max232 interface receives the data and sends it to /dev/ttyS0 on the receiving Linux based server. From there I decrypt and parse the received data and process it for errors. It is then checked for predefined temperature limits and emails the appropriate contacts if thresholds are reached. It is also stored into a database and sends a daily log of temperatures throughout the day.

The system is flexible as it allows me to add any additional sensors into the monitoring network at any time. I'm using 2.4Ghz based XBee's, but they are in sockets allowing me to replace them with the 900Mhz version in the event that a facility has a lot of walls blocking the 2.4Ghz signal.

So far the temperature sensors have been working very well, future plans include a modular temperature sensor board and a better (prettier) web interface to show the current facility conditions.

Verifying LMR-200 Coax Cable Loss

For years I have used RG-58 cable for my antenna systems, it is inexpensive, easy to work with, and for short runs it works just fine. Last year I started heavily receiving NOAA weather APT imagery using the same RG-58 cable. During this time, pass after satellite pass I noticed my images were not as pristine as they should be. The cable length I was using was just over 100' in length and looking at the loss of my RG-58 it's no surprise that I had such poor images. As a test I replaced all of the cable with a used length on Andrew LMR-400 cable which resulted in an instant improvement.

Now this past week I finally mounted a wide-band scanner antenna on my home and needed a 60' run of cable to reach my RF bench in the basement. Instead of going to my typical spool of RG-58, I wanted something better. LMR-400 was my first choice but is significantly more expensive than my free RG-58. Because of this and the fact that a smaller diameter cable would be better hidden on the outside of the house I chose LMR-200. I purchased 60' of Times Microwave LMR-200 (arguably the best cable you can buy).


With an attenuation of 9.9dB @ 900Mhz, it was significantly better than RG-58. This cable combined with quality Amphenol SMA connectors I was curious to see if the cable would measure up to it's spec sheet. Times Microwave rates it's LMR-200 at 9.9dBm of attenuation at 900Mhz over 100'. At my 60 feet I should only be seeing 5.94dBm of loss which is what I am looking to verify.

The test setup:


An HP 8656B signal generator would be the test source while the spectrum analyzer in my HP 8922H would be used to verify the attenuation of the cable. As a baseline test, I connected a small 1' high quality 50 ohm SMA cable with Amphenol connectors in between the signal generator and spectrum analyzer. Using a -50dBm baseline, the measured signal through the cable was -50.52dBm at 100Mhz. At 900Mhz, it was -51.65dBm, a good start. Now to place the 60' of LMR-200 inline. Unfortunately I did not have a male N to female SMA adapter so I could not test the cable directly inline. To make the test work I placed a mini-circuits ZFSC-2-5-S splitter inline of the cable.


According the the mini-circuits datasheet, at 100Mhz this splitter has a loss on each output of 3.25dBm. At ~900Mhz it has a loss of 3.57dBm, both of which will be compensated for in the results. So testing the 60' of LMR-200 through the splitter at 900Mhz yielded -59.95dBm:


Taking that result and subtracting the loss of the mini-circuits splitter you end up with -56.38dBm, and the difference of that from the original baseline of -50.52dBm at 900Mhz is -5.86dBm of loss at 900Mhz, which is under the spec sheet of -5.94dBm by .08dBm, a very good result indeed. I love it when numbers work out. As a final test I ran a sweep test on the 60' cable using an HP 8754A Vector Network Analyzer. As expected, the loss from 10Mhz to 1300Mhz exactly matched the expected attenuation in the datasheet:



I will be running this cable to my antenna tomorrow. :)