Return to SSS Online home page
SSS Online is Your SS, RF & Wireless E-zine!

Topical Menus:

   SSS Online Ezine
   Spread Spectrum
   RF Topics
   Wireless Topics
   Design Topics
   Tech Notes & Tips
   Design Tools
   Software Downloads
   Reference Material
   Ham Topics
   Fun & Games
   Assorted Topics
   Community Topics
   Site Info

This site is managed by: Visit Pegasus Technologies
Pegasus Menu
Contact Us



Search site
Search Web
Leave a Comment

Sign our Guestbook

Visit our Sponsors:

Topical Menus:
Spread Spectrum Scene Online

Read the Newest Issue of SSS Online!

Volume 7 - Number 2 -- Spring 2001

March 16, 2001

Inside This Issue:

Webmaster's Note: Report on Update Progress
Around the Circuit
  Review of Xemics Chip Lineup
  NTIA Releases Two More UWB Studies
Prototyping With Surface Mount Components
An Overview of the Universal Serial Bus (USB) (Part II)
FCC Considerations for Spread Spectrum Systems

Review our Previous Issues

SSS is proud to present our Seventh Online issue.

We are now soliciting ideas and articles for our eighth issue, which is tentatively scheduled for mid-June 2001. Please send your comments and suggestions to:

Webmaster's Note: Update on Website Changes
By Karen Edwards

At the end of January, we launched our new navigation system, which included a complete update of the site's organization and format. The home page now has more room for hot news, and links to 16 separate topical menu pages, each of which lists all the pages assigned to that topic. Each topical section has its own "look", but they all share common navigation features. We have finished updating the sections on SS Topics, RF Topics, Wireless Topics, Tech Notes & Tips, and Pegasus Technologies. We are well along on the Ezine and Site Information sections, and hope to declare victory on them shortly. All the remaining sections have some pages completed, but not all -- we'll keep working on the technical sections first, and leave the links, assorted topics, and community topics for last.

We've made a lot of progress on updating the site since our last issue of SSS Online - we've now revised about 200 pages and added some 40 new ones. There are still over 100 pages that haven't been changed yet -- some of these we intend to "kill" and others will be updated as we get to them. However, we've been able to reduce our "not found" rate from nearly 20% to less than 4%. This is still higher than we'd like, but we're making headway!

Some of the more important new features we've added during the last few months are:

  • A Change Directory, which summarizes important changes in bullet form, and provides a table of all changed pages, categorized as "major" or "minor">. We also have added a page for archived changes older than 3 months.

  • Updated Table of Contents, Site Map, Navigation Page, and Welcome pages to help you find your way around easier.

  • We've begun moving articles out of old issues of SSS Online into new or existing pages pertaining to that subject area, so you can find them without having to resort to a site search. This will take a while for the older issues -- but last issue's articles are already done!

We hope you like our new look, and agree with us that it's easier to find information on the site than ever before! We appreciate any comments you may have about the site, and we love to hear from you about new ideas and suggestions -- please drop us a line!

Return to Contents

Around the Circuit

Review of Xemics Chip Lineup

Are you looking for a short range RF transceiver IC? I suggest that you give a close look at the Xemics product line. Editor's note 11/26/08: Semtech bought out Xemics. The link above will take you to the Semtech site. They still make the XE1200 family chips.

Xemics is a spin-off company from that formidable technology powerhouse CSEM in Switzerland. They specialize in low current consumption RF and microcontroller ICs and are starting to have quite an impact on these markets in the US.

Their present offering in the RF chip lineup is the XE1201, a zero-IF FM transceiver that operates in the 300MHz to 500MHz band. It has an innovative receive clock generation circuit so that the received data is presented to your microcontroller with a synchronous clock. This eliminates the need for the designer to perform clock generation in firmware or hardware.

For those of you in the US, they have recently added an applications engineer that specializes in the RF product line. The support is absolutely tops!

Their microcontroller line is very interesting too. They have some of the lowest current consumption micros out there. Operating on voltages down to 2.4V, they consume 300 microamps per MIPS! They also have a US-based applications engineer dedicated to this line.

On the drawing board and scheduled for release later this year is the XE1202 transceiver IC. This chip will operate all the way from 433 MHz to 928 MHz using its integrated synthesizer.

NTIA releases two new reports on UWB.

On March 9, NTIA released the following reports: (1)"Assessment of Compatibility between Ultrawideband (UWB) Systems and Global Positioning Systems (GPS) Receivers," and (2)"Measurements to Determine Potential Interference to GPS Receivers from Ultrawideband Transmission Systems." The reports have also been filed with the FCC for inclusion in the public record in their ongoing UWB proceeding, Docket Number 98-153. The two reports are available in several formats at the following two URLs:

Check out our UWB page for more information!

Return to Contents

Prototyping With Surface Mount Components -- By Jim Pearce

Many engineers express dismay at having to build a breadboard using components that are only available in surface mount (SM) packages. Others will go to great lengths to acquire parts in through-hole versions for their prototypes and then use the SM versions for the production board.

By necessity, I have become very proficient at building prototypes using SM discrete components and integrated circuits. There is one possible disadvantage that I should point out up front: your first prototype must be an actual printed circuit board. I don't find this to be a major problem since I used to go directly from schematic to printed circuit boards even back in the through-hole days.

I find that there are many advantages to doing the initial boards using SM components:

  1. The prototype board is the same physical size as the ultimate product. Since the board itself must be considered a component for many RF boards, this is absolutely necessary.

  2. The surface mount components are physically smaller than their through-hole equivalents, so they are less affected by parasitic effects.

  3. It is easier to change out resistors and capacitors to try different values. You don't have to get solder out of a plated-through hole. Simply bring the hot air soldering hand piece up to the part that you want to remove, grasp the part with tweezers, and lift it off.

  4. You can try different values of discrete components rapidly without solder at all. Just lay the part across the pads and apply a small pressure with your tweezers in the middle of the part so you don't contact either end of the part. Observe the 'scope, meter, or whatever instrument you're using for the change in circuit behavior, and go on to the next value.

  5. The board lasts through more component changes than a through-hole board. I have had through-hole pads lift and break after just one unsoldering operation. This rarely happens with a SM board, though pads with no connections to help dissipate heat will occasionally lift off the board with little provocation!

While a megabuck SM repair station is not necessary (I have gotten along just fine without one), there are a few bench tools that are essential for SM prototyping. They are listed below, roughly in order of importance.

  1. Stereo Microscope. Anyone who is doing serious SM work must have a good stereo microscope for soldering, desoldering, inspection, or probing operations. When selecting a microscope, be sure to pay particular attention to the working distance -- the clearance between the microscope objective lens and the item that it is focused on. I once worked with an otherwise fabulous microscope that had only two inches of working distance. Boy, was it ever easy to burn the plastic ring light on that microscope with a soldering iron! A negative power lens will increase working distance more than it will decrease the magnification. Scienscope supplies reasonably priced stereo microscopes.

Sciencescope Microscope

  1. Good tweezers. Tweezers are next on my list since they are the tool that you will handle most. I prefer foam cushioned stainless steel tweezers with curved tips like the Erem 7SA. A good pair of tweezers will make your life much easier!

  1. Hot air soldering iron. A hot air soldering iron is useful both for initial soldering and for desoldering. My choice of hot air tools is the Edsyn 971HA. It is one of the less expensive units but is still quite capable. In fact, it has some features (possibly unintended) that make it easier to use than most hot air soldering tools. The most important of these is that the air tubing from the base to the handpiece is flexible and runs at a position where you can squeeze off the air flow with your index finger while moving the iron near to the component that you wish to work on. This prevents blowing off dozens of components while getting everything arranged under the microscope! This soldering station is intended for operation with compressed air and it comes with air handling hookups. I don't have shop air, but rather than pay hundreds of dollars more for a unit with a built in pump I went to WalMart and bought the largest aquarium air pump they had in stock. With very simple and reversible modifications, the soldering iron works quite nicely with this air source. I recommend Howard Electronics as a source for microscopes and soldering supplies.

  1. Stainless steel shim pin lifter. The quickest and least damage-prone method of unsoldering large surface mount integrated circuits is to use a stainless steel shim in an exacto-knife handle. Carefully slide the shim under the pins of the IC while heating with the hot air soldering iron, and they pop right off. I have desoldered many .5mm pitch QFP parts using this technique, and have been able to reuse the parts and have not damaged any of the pads on the board. This method is also quite rapid. A 48 pin part might be removed in as little as 30 seconds. And it doesn't require expensive, complicated special purpose hot air nozzles. This technique is championed by Edsyn, who include a roll of stainless shim stock with their soldering irons. I've not seen this method described anywhere else.

  2. Fine tipped soldering iron. I use a contact (traditional) soldering iron for most initial board building. A well-tinned very narrow tip is a must. Any manufacturer's iron will do but the smaller and lighter hand pieces are very nice for big jobs.  You might try the Edsyn 951SX:

  1. Flux pin. After swapping many components to find the correct values, it's inevitable that the solder on the board will become grainy and laced with impurities. I like to use a Kester low-solids flux pin to clean the board up and make better solder joints. With one of these pins you simply touch the contaminated solder and gently reheat the area with the hot air soldering iron (being careful not to blow parts away), and the solder gets bright and shiny as if by magic. Better still, with a low-solids pin, you don't even have to wash the flux off afterwards.

    Several years ago, many of the no-clean fluxes were useful only for digital circuits since they had relatively high conductivity and would interfere with the operation of any high impedence analog circuits. With the new low-solids, no-clean fluxes that are out now, I have not run across this problem.

In conclusion, I have found that the proper tools make prototyping with surface mount components easier and faster than any of the traditional prototype methods. Certainly it is no longer an onerous task to be avoided at any cost!

Return to Contents

An Overview of the Universal Serial Bus (USB)
(Part II)

-- by Danny Simpson, Pegasus Technologies

The USB Seal

In Part I, we reviewed the history of USB, going over some of the communication advantages of USB over RS-232, and then touching on the various USB data transfer protocols. USB is a somewhat complex communications protocol but like many things, if you take it one step at a time, it can be digested. In this issue, we will recap some of the basics as well as get into more of the details involving the Windows drivers and their requirements. Also, we will go over some of the capabilities, shortcomings, and limitations of USB. Again, we are covering here the USB 1.x spec dealing with the low speed 1.5Mbps and high speed 12Mbps transfer rates. USB 2.0 devices (480Mbps rates) are not expected to have support from Windows until late 2001.

USB came into existence because of the need for interfacing a number of relatively fast peripherals to host systems such as a personal computers. Many peripherals must be installed inside the computer. In the past, just about the only way to add a new device to a computer was to turn off the power, remove the cover from the computer, find an empty PCI or ISA slot in which to install a 'printed circuit card', install the new card, replace the computer cover, turn the power back on, get the computer to install the driver(s) for the card, and hope that the computer system still works properly after your efforts. Many of today's computer systems only have 2 or 3 'spare' slots for new PC cards which can be a big limitation for some folks. Also, with PCI bus, there are limitations where some PC card slots share interrupts, and some card slots cannot be used with a PCI bus mastering card installed in them. As many PCI cards these days do have bus mastering built into them, these cards often will not work in those particular card slots. Theoretically, with USB you can install up to 127 different devices per USB port. Most PCs have 2 USB ports yielding up to 254 devices connected to a single PC! In reality, it can get a little sloppy on your desktop with this many USB devices, cables, and the hubs taking up room. Also, if you try this route you are probably going to run up against USB bandwidth limitations...

A USB industrial touchpad module fromCirque Manufacturing

You cannot connect two computers directly together for communications purposes using a USB connection. However, you can hook two computers together using a peripheral called a USB bridge, also known as a USB to USB adapter. USB is not intended to be used like a LAN, so if you need to connect up two or more PCs together, you need to use Ethernet or something equivalent. If you need to connect USB devices to a host farther away than the maximum cable length of 3 meters for low speed (1.5Mbps) USB or 5 meters for high speed (12Mbps) USB, you will need to use hubs to extend the connection distance up to a maximum of 25 meters (5 hubs maximum, with 5meter cables between each hub).

When a device is added to a USB port, Windows on the PC side recognizes the connection and adds the proper previously installed driver to support the device. Many hardware devices that are plugged into the PC's USB port need to have a specialized driver written to support the device. Also, in some cases, specialized software applications will need to be supplied with the device to make it functional on the PC.

USB Driver Development

There are at least a couple of ways to get drivers that Windows can use for communications with a USB device: you can 'roll your own,'or you can make use of a set of USB drivers that the newer versions of Windows have included either on the Windows CD or that are available from resources such as those included in the Win DDK. Device descriptors inside each USB device contain information that Windows needs to know about the device before it can be used. Descriptors for a minimal device are mentioned below.

Windows Supplied Drivers

There is a set of drivers included in the newer versions of Windows that support certain devices called 'human interface devices' or HIDs. These devices include keyboards, mice, game controls, remote controls, and joysticks. In general, these devices don't require a great deal of data to be transferred to or from the host computer. The firmware inside these peripheral devices must support the Windows HID protocol if you want to use the existing HID drivers. The data that is transferred to and from these devices to the computer are called reports. Using HID, transactions can contain up to 64 bytes of data per transfer in high speed mode and 8 bytes of data in low speed mode using the HID drivers. Maximum speed of data transfer is also limited. A high speed device can only transfer 64K bytes per millisecond and a low speed device can only transfer 800 bytes per 10 milliseconds. Also, HID uses the control and interrupt pipes for data transfers (see our first article on USB for a discussion of this topic) which the USB protocol defines. As a result, HIDdoes not guarantee timely data transfer. If you need data to be delivered at a certain critical time, HID is probably not the way to go. As usual, the computer is the host and initiates all transfers. Even with these limitations, if you only require low volume data transfers, you can save a bit of time by using the Window HID-supplied drivers instead of writing your own software drivers.

A fairly rigid protocol must be adhered to when using the HID drivers with your device. Windows needs to determine which driver to load into memory to support a particular device that has been inserted into the USB port. It does this by issuing what is called a Get_Descriptor command to the device. What is returned to the PC host from the device is a block of information that tells the PC certain facts regarding its operation such as what class the device is, the number of logical interfaces it has, the size of its endpoints (data buffers), the vendor ID, product ID, and possibly serial number information. It is the class information that determines whether Windows can use its existing HID drivers.

After the Windows device drivers have been installed and the devices are connected to the host's USB port, Windows uses the Windows Device Manager to determine which USB driver to use with which device. It makes this decision based on a user-supplied .INF file that contains information such as manufacturer and product data, if the device is a non-HID device. If it is a HID device, it will use the .INF file named hiddev.inf for information on the device. This file also contains information that will be added to the registry once the device has initially been installed in Windows. Windows then uses data from all the .INF files (located in the \Windows\INF directory which is normally hidden) to catalog the data into two files named drvdata.bin and drvidx.bin for quick access to the proper .INF files to retrieve data for a particular device. If you do change the data inside an .INF file, you must go through a specific procedure to get Windows to change the entry for the device in the registry by using the Device Manager or else the changes will not be made when you expected them to. An .INF file has a format similar to the familiar .INI file.

User Supplied Drivers

If you cannot live with the limitations that the Windows HID driver imposes on you, you will need to write your own Windows drivers to communicate with your USB device. This can get quite involved and you may need to have access to several additional tools.

As discussed in the previous article, you will need to determine your devices' data transfer requirements -- such as which data transfer formats that you require for its use. You can have one or more of these data transfer formats identified in your device. Control mode is needed as a minimum for all USB devices for the query and setup of your device with Windows. If any of the following modes are required, Control mode also needs to be included. If data accuracy is important, you will need to use bulk mode, but you will need to give up guaranteed timing of data delivery as USB tends to give bulk mode its lowest priority. Bulk mode transfer is only available in high speed mode and includes error checking. If guaranteed timing of data delivery is more important than data accuracy, then you need to use isochronous mode of transfer. Isochronous mode transfer is also only available in high speed mode. You need to sacrifice one primary need for the other in these cases, i.e., transfer rate verses accuracy. If you need to be 'serviced' from the host at irregular intervals, you can use interrupt mode where the host will query you at regular intervals to see if you have an 'interrupt' pending to the host. You cannot interrupt a host in the usual sense, as it needs to ask you if you have anything pending. The host initiates almost all transfers except for remote wakeup.

Windows drivers typically 'isolate' applications from the details of the physical and logical aspects of the data transfer protocols. Much of the handshaking used is not seen by the application program, and neither is the structure of the packets and error checking. Drivers are seen as 'layered' between the hardware and the application program. You can use existing Windows drivers and write a mini-driver which adds to the capabilities of the existing driver. There is also a generic driver that is available called bulkusb.sys that can be used as a starting point for performing bulk mode transfers. Windows allows drivers greater privilege than applications programs by letting them have unrestricted access to system resources using IRPs (I/O request packets) to communicate with the lower level Windows USB drivers. Applications, which use the Win API to communicate with Windows, run in user mode while the drivers can run in kernel mode.

Communication Modes

There is a strict structure when using USB as a communications medium. After a device has been detected by the host, its device descriptors have been read, and it has been enumerated and assigned a handle by Windows, then an adherence to the set mode of communication mode must be kept. The control mode is the initial point of contact between the host and the connected device. Control mode in addition may be used for very limited user data volume between the host and the device. It is here where the host determines the device's setup such as communications modes, IDs, and general configuration. Control mode is the most complex mode of the four communication modes and has quite a bit of overhead on top the actual data transfers. There are many packets of data initiated by the host in this mode to the device and also packets of data are sent back by the device in response to the host. There are also several stages of communication such as Setup, Data, and Status stages, all which are structured. There are a total of eleven different USB standard requests in control mode where the host can set or get various parameters from the device. The USB standard also allows vendors to define their own additional requests in addition to the eleven provided.

The other three communication modes are generally used for user data transfer between the host and the host's connected devices. The basic 'gives' and 'takes' between these different modes has already been discussed above. Obviously, if you are using a custom Windows driver to communicate with a device, the device's firmware must be written to support the communication modes of the driver. It is imperative that good documentation be kept to document the different communication modes or the software and firmware development could get pretty 'outta whack' especially when working in a larger team project. The USB bus drivers that come with Windows are based on the WDM (Win32) drivers, and drivers written for your device should also be written based on the same WDM model. Remember, there are 'layers' of these drivers communicating with each other as well as the 'top' layer driver communicating with the application and the 'bottom' layer driver communicating with the USB hardware itself. Each driver has a limited set of tasks that it performs in conjunction with other drivers that also have assigned tasks.

Also remember that hubs need to be involved in the communication chain. They also have their internal firmware 'smarts' to make various decisions such as when to disconnect a downstream device that is not behaving properly. There is a hub driver within Windows that is used in the above-mentioned 'layers' that does the direct communication with the downstream hubs and also handles the enumeration. The USB bus-class driver assumes the responsibility of hub driver and the host-controller driver. It is this host-controller driver that does the direct communication with the hardware. You can see how the different tasks that are defined in the USB protocol are assigned the different tasks. When an application closes or no longer needs a USB device, it closes the device's Windows assigned handle to free up limited system resources -- which is imperative in Windows applications.


There are some software tools available from the Developer's section of the USB Implementer's Forum to help verify your software. USBComp.exe, available from [Editor's note 2/1/09: this utility is still available from], contains a series of several test programs that allow you to check out your device to see how it functions when connected to USB, whether you're using HID or your own Windows driver. This at present is only for computers running under Windows 2000. In particular, have a look at USBCheck which is included in USBComp.exe. There also are several USB protocol analyzers available which will allow you to see all traffic on the USB port. Using one of these is probably the best way to assist you in the development stages as well as thoroughly checking the operation of your device. As always, you can download the latest USB specs and current important documentation from

We have covered quite a bit regarding the basics of USB in these two articles. There are more details available at the USB Implementer's Forum web site that was mentioned above. Also, the web has many other resources to help educate you further on USB or provide USB development tools available for either lease or purchase. Be sure to check out SSS Online's USB page for more information and listings of some of these sites. At Pegasus / SSS-OnLine, we strive to help you with all your communication needs!

Return to Contents

FCC Considerations for Spread Spectrum Systems
-- By Jim Pearce, Director, Pegasus Technologies

Oftentimes, potential clients call me with a great idea for a spread spectrum system. It fills a market need, it's feasible from a technical standpoint, and it's just plain sexy. On further discussion, though, it becomes evident that the system as contemplated (or in some cases, as already designed and ready to go into production) will not pass FCC Part 15 certification. While FCC experimental rules will permit the initial design and prototyping of many of these systems, any systems that are to be manufactured for sale must be certified under FCC Rules.

47 CFR Part 15 deals with unlicensed RF devices. "Unintentional or intentional radiators" (i.e., radios, computers, or other emittors) that are to be manufactured for sale must either meet the requirements for this part, or must meet Part 2 requirements and their operation must be licensed. Part 15 is aimed at ensuring that unlicensed operation does not result in interference with other RF systems, and this means keeping transmitter power low. For this reason, external, stand-alone amplifiers of any kind are not permitted under Part 15. (You can download FCC's Part 15 rules directly from our FCC Rules page, or you can go straight to the FCC itself.)

Section 15.247 allows up to 1 watt of transmitter power for spread spectrum systems that operate in the 900 MHz, 2.4GHz, and 5.8GHz unlicensed bands. One watt is quite a bit of power, and this makes certification under this section an attractive target for new products that need up to a mile of range. In order to be certified under this section, however, a system must meet certain listed requirements, including a specification for processing gain for direct sequence spread spectrum data links.

A key point here: Both the transmitter and the receiver must exhibit processing gain to qualify as a spread spectrum system under section 15.247.

The FCC has issued several interpretations that touch on the necessity of a receiver to exhibit processing gain. It should be noted that these interpretations often do not have the original question included with them, just the FCC's response. Because of this, you must try to piece together the original question from the text of the FCC's answer quoted below (All added emphasis is my own):

This is to confirm our telecon of April 27 regarding the wireless personal locating system described in the referenced fax. Based on the information provided, it appears that your system fails to comply with the requirements of Section 15.247 of our Rules. As explained in your fax, the normal measurement process performed by your system consists of three basic steps:
  • Step 1: The system "RDF" units transmit a standard direct sequence signal (with ASK-modulated enabling message) to the 'BT' units. It does not appear that the 'BTs' correlate the received spread spectrum signal and, therefore, they do not demonstrate processing gain as required by Section 15.247(e). Since we view a spread spectrum system as a transmitter and the associated receiver with which it is communicating, the 'BT' receivers must display the required processing gain.

  • Step 2: Operating under the provisions of Section 15.249, the desired 'BT' shifts the frequency of the incoming 'RDF' signal and transmits it back to the 'RDFs' with an ASK-modulated acknowledgement message. This is acceptable operation under 15.249.

  • Step 3: The 'RDFs' transmit a spread spectrum signal to the 'BTs' for 130 ms. The 'RDF' receivers despread the signal returning from the desired 'BT' and determine ranging information by calculating the time delay between the outgoing and returning PN sequences in the spread spectrum signal. This aspect of system operation fails to comply with the definition of a spread spectrum system contained in Part 2 of our Rules. Under this definition, only 'a portion of the information being conveyed by the system may be contained in the spreading function.' As described, all of the information being conveyed in this step of the location process is contained in the spreading function. Based on the above, your system is not acceptable for authorization under Part 15 of our Rules.
The FCC seems pretty firm on this issue, and even though they are charged with supporting innovation they do not use this mandate as a method to get around the Section 15.247 requirements. They want systems to meet both the letter and the spirit of the regulations, as discussed in the following interpretation:

This is in response to the referenced fax regarding [petitioner's] gas and electric meter modules. You indicate that these transmitter modules are currently authorized under Section 15.231, and inquire about the possibility of approving them as spread spectrum devices under Section 15.247. We have examined the technical information you provided to support your request, and find that there is insufficient justification for authorizing the referenced equipment under 15.247. Although the subject modules demonstrate frequency agility by successively transmitting redundant meter data on a series of 8 frequencies, they fail to comply with the requirement of Section 15.247(a)(1)(i) which mandates a minimum of 50 hopping channels. Additionally, the associated system receivers do not comply with the synchronized hopping requirement of 15.247(a)(1). In place of synchronized frequency shifting receivers, the ... system utilizes a bank of 48 fixed-tuned receivers to cover the operating frequency band. In your fax, you acknowledge that an individual module does not comply with the r equirements of Section 15.247, but that when viewed as a system consisting of thousands of devices, the "spirit" of the law is met. Unfortunately, our rules do not provide latitude for approaching authorization of these modules from this perspective.

From this it is evident that any system where the receiver does not exhibit processing gain will have a difficult time overcoming the FCC part 15.247 certification hurdle. Another FCC interpretation that addresses this point is the following discussion on spread spectrum repeaters:

An application for a repeater that consisted of a RX front-end, down-converter, up-converter, amp and antenna (port), retransmitting at spread spectrum power levels was denied.

While such devices may be authorized under licensed Rules Parts (formerly Type Acceptance), they cannot be authorized under Part 15. As a part of a licensed system, they would only receive signals licensed to operate on certain specific frequencies. A Part 15 repeated such as this one, however, could receive, amplify and retransmit ANY incoming signal (the [Xxx] device, operated in the 2.45 GHz band, so it could, in theory, have received and retransmitted emissions from a microwave oven).

We have authorized repeaters under Part 15 where they demodulated the incoming signal in order to determine if it was 'valid', I.e., it came from a specific device with which the repeater was designed to operate. In these cases, we list the FCC ID of the transmitter with which the repeater operates on the Grant.

In the [XXX] case, the difference is that it does not demodulate the incoming signal in order to identify its source. This cannot be allowed under Part 15. The actual Rule Part for the denial was 15.247(e), which requires that a direct sequence receiver realize at least 10 dB processing gain. The receiver portion of the [Xxx] repeater realizes no Gp, as it does not correlate or demod. If the device had been designed to operate with a hopper, Section 15.247(a)(1) would have been cited, which requires that a frequency hopping receiver have an input bandwidth matching the transmitter bandwidth, and have the ability to hop in sequence with the transmitted signal.

We will only grant a spread spectrum repeater (or any Part 15 repeater) if it has the ability to determine the source and validity of the incoming signal, and only retransmits signals from a specific transmitter, which is listed on its grant.

I have had occasion to discuss this issue with an FCC representative in the Office of Engineering and Technology. Without identifying the client or the actual application, I explained the basic operation of a client's proposed system and asked him to comment on it from a certification point of view.

The fellow said that there would be no problem certifying the system as long as it demodulates the signal and then retransmits the digital stream. I asked if operation without the demodulation would be certifiable. He confirmed that since it would not exhibit processing gain it would not meet the requirements of 15.247(e) and would not be certified.

If a system can't be certified under section 15.247, there are some other options to consider. These include:
  • Designing the system so that both the transmitter and the receiver exhibit the required processing gain;

  • Designing the system so that it will meet FCC part 15.249 (with its power limitation of approximately 1 mW);

  • abandoning the 2.4 GHz band in favor of a band that allows more leeway for innovative concepts, such as the 5 GHz NII bands;

  • Petitioning for an exception (although these are hardly ever granted); or

  • petitioning for a rule change - but don't hold your breath while waiting for this to happen.
As you can see from the discussion above, it is very important to consider FCC issues at the very start of a design project. These issues can have a very major impact on the entire concept of the design, and early consideration is vital to avoid wasted time and money designing a system that can't be certified for sale.

Return to Contents

Contents SS Glossary Pegasus Tech Navigation Home

  Tel: 865-717-9339   ||   FAX: 865-717-9904    ||   E-Mail:
This site © 1995-2009 by SSS Online, Inc. All rights reserved.
Revised February 2, 2009