2010-01-23
MCU Controlled Super-regeneration with Quartz Oscillators
It is often said that you can not super-regenerate crystal oscillators. In fact you can, but because of their high Q the quench frequencies needed are too low to carry high bandwidth signals like voice. There is nothing stopping the principle being used for lower bandwidth data transmission. The circuits here are inspired by Burkhard Kainka's ISM-band implementation of a simple xtal-based transceivers. I took the same basic Pierce oscillator topology and improved the software to support asynchronous byte-coded data transmission at a low baud rate. My example application is simply toggling a LED on and off by remote control, but the devices, especially their simplicity and symmetry as true transceivers, offer many other possible applications.
The Basic Transceiver
Like most RF oscillators, the Pierce oscillator start-up time is influenced by the initial conditions of the resonator. Tiny fluctuations in the signal sloshing backwards and forwards in the resonator are amplified during the oscillator start-up. Stronger initial signal conditions mean the oscillator signal grows to a particular amplitude faster than weaker ones. By timing this time-to-amplitude-X delay one can measure the applied RF signal energy in the resonator at the start of the oscillation, essentially sampling the initial resonator conditions.
To play with this idea I built a Pierce oscillator configuration basically identical to Burkhard's, but instead of a MCU I simply shunted the storage cap after the diode with a MOSFET. (The true brillance of Burkhard's design is in this dual-purpose port where a pull-down can halt the oscillator or a logic level measurement can detect the onset of oscillation before saturation.) The MOSFET gate was driven with a low-frequency variable duty-cycle square wave with my signal generator. This lash-up let me measure the properties of the oscillator; the average start-up time from thermal noise, the residual decay time before another cycle could be attempted, the effect on the start-up time of applied "forcing" signals from a similar Pierce oscillator or RF signal generator, and the effect of different xtal frequencies.
I picked 14.31818 MHz crytals (because I have a huge quantity of them) and carried out most experiments at this frequency, but fundamental crystals from 4 MHz to 27 MHz were tried. Frequencies much below 8 MHz are difficult to work with, they have extended regeneration times, often exceeding 10 ms, also their very high Q makes the selectivity quite high which is not always desirable. The regeneration time drops linearly with the log of applied RF power. A simple circuit utilising a comparator and a one-shot hooked up to this kind of oscillator makes an excellent log signal-strength receiver with quite impressive dynamic range.
I soon ditched the analogue lash-up circuit and wrote some firmware for an Atmel ATtiny13 to control the oscillator. For testing purposes it sports an overflow LED (oscillator time-out), a carrier detect LED (signal threshold exceeded), and a PWM output for driving a 50 uA moving-coil received signal strength meter.
Making a Data Link
Once I had the MCU controlling the oscillator it was fairly trivial to turn the system into a remote-control data link. A simple asynchronous protocol was decided upon, 1 start bit, 8 data bits, no parity, no stop bit. The crystal properties limited sample rates to about 100 Hz, so 20 baud was selected for the symbol rate and simple on-off keying used as the modulation.
The Transmitter
The transmitter side is very simple. The code is "Software UART"-like. A timer running at the baud rate clocks a simple state machine that turns the oscillator on and off in the correct sequence.
Actually in the hardware the oscillator is keyed once per frame, and the power amplifier (added more recently) has its bias keyed at the data rate. This results in sufficient ASK modulation depth but the backwave suppression could be better - get too close to the RX with the unshielded TX and the carrier oscillator jams the RX. Keying the oscillator avoids the problem but causes a little FM chirping, decreasing the signal quality at long range. Circuit improvements would easily take care of this.
The Receiver
The receiver code is again very "Software UART"-like. A timer runs initially at 100 Hz looking for the edge of the start bit, once that has detected the timer is slowed to 20 Hz and the data clocked into a byte buffer. Once all data bits have been received the oscillator resumes 100 Hz sampling looking for the next start bit. For initial purposes the code byte 0x5A was selected as its upper and lower nibbles are complementary - intended perhaps later to implement parity checking of a nibble-wide control vector. Upon reception of a valid code byte the output pin is toggled.
The receiver hardware is simpler than the transmitter in this demo application. It lacks the power amplifier I added to the TX side to improve range. It would benefit from an isolating RF amplifier and/or better antenna impedance matching.
Here is what the TX keyline (green) and the RX control line (white) look like during transeption of a data frame.
This oscillogram clearly shows the fast sampling prior to the frame and the slower data sampling at the baud rate. Also one can see the longer time it takes the RX oscillator to start when the TX is not keyed. Here is a close-up of the start bit region that shows the details more clearly.
To make these measurements I changed the TX code to generate a stream of frames continuously instead of being triggered by a pin change interrupt (push button). The TX and RX were then hooked up to my Embest DSO2300 and the signals captured by triggering on the TX keyline.
Protocols
The protocol is in some sense arbitrary, additional framing and parity bits implemented with software changes could improve noise rejection with no transceiver hardware changes. The 0x5A pattern is yet to be accidentally generated by noise, but naive patterns like 0x00 would be easily subject to impulse noise without additional framing and parity. This is largely why I used a "RECS-80"-like protocol, however bi-phase coding would be more noise resistant, so something similar to RC-5 or RC-6 could be implemented with simple software changes.
Currently impulse noise also jams the receiver for a full frame period, which is fairly long and annoying at the current baud rate, requiring setting the noise margin of the data slicing threshold higher than is perhaps optimal. Bi-phase coding would allow early aborting of transient-induced frame starting. Even the current system could test the start bit sample (which is currently ignored) and transition back to idle if the start bit is too "short". Adding a framing error LED would be handy if such modifications were attempted.
The simple digital threshold data slicing technique is quite primitive and subject to noise. The data recovered by the transceiver detector is quite a few bits wide (ranging from 0 to several thousand). Likelyhood-style demodulators based on DSP analysis of this data stream could recover weak signals and would require none of the fragile hard-coded or reset-time measured threshold setting. The sampled data also gives you signal strength indication with a large dynamic range which might be useful.
Naturally using LC oscillators opens the possibility of much faster data rates.
While I dedicated each end of this xtal-based system to RX and TX the basic circuit is a bi-directional transceiver and could be augmented with a power amplifier and preselector/isolator amplifier also controlled by the MCU for high performance at the cost of a little more power and another pin. The bare 1 transistor circuit can be used in low performance applications, especially if some effort is made to match the antenna to the circuit. As a trivial "modem" for some kind of slow agent cooperating with a number of other agents the system is almost ideal. Some kind of broadcast media sharing protocol (CSMA or CSMA/CD) would be required. One is almost tempted to experiment with groups of these units to demonstrate emergent behaviour like those firefly synchronisation projects. Essentially the addition of only a few extra parts to your MCU lets it listen and talk RF at ~100 Hz and at the cost of one tri-state pin. Using Xtals eliminates alignment (as long as the xtals and their load environment are reasonably matched), making implementation very simple; Burkhard's idea is truly excellent and needs more investigation.
Notes
Frequency alignment is fairly critical because the receiver selectivity is quite high. I am working on a detailed investigation of the selectivity and sensitivity of these trivial transceivers to put numbers behind more general utilisation of the principle.
Matching the antenna to the circuit is quite important for best performance. I haven't spent a lot of effort on this yet, but at HF it is fairly challenging for compact antennas. Higher frequencies make loading of short monopoles more efficient and loop radiators more practical. More complicated transceiver architecture with preselection/isolation and power amplification would enable high performance long-distance communication.
Digital control of an RF oscillator like this has many, many uses. I have toyed with this idea for a while, and combined with larger MCUs with better timers and additional peripherals many different kinds of useful RF devices are possible. I have a book full of sketches for different applications once some more basic data has been collected.
I suspect a digital scheme like this would make full-duplex lock-step communication possible. This has interesting dynamics too, and recovers distance information as a side-effect. I have no idea how this kind of modulation would be classified, but it would be essentially a kind of time-domain technology while still being *fairly* narrow band. Interesting experiments remain in investigation of the temporal "sensitivity window" of the super-regenerative detector, instruments for this I have designed but contain some nasty technical challenges to implement.
For the simple envelope level detection and oscillator control scheme to work properly the DC collector bias on the oscillator (minus the diode drop) must be below the logic threshold of the MCU in question. I measured the threshold of the tiny13 inputs at ~2.3 volts with a 5 volt Vcc. The transistor biasing was changed to make oscillation envelope detection rapid and reliable. Biased such that the MCU pin is below logic-1 at the saturation envelope level or at logic-1 at the initial DC bias point would cause this simple scheme to fail. It is a good idea to retain some kind of annunciator for this kind of overflow/underflow condition or check for it at reset and flag it with a more general failure annunciator. Obviously splitting up the oscillator control and oscillation detection would simplify this, and may be needed for arbitrary oscillator topologies. Luckily the Pierce oscillator facilitates this trivial 1-pin interface for simple low-performance devices.
10 comments.
Attachments
| title | type | size |
|---|---|---|
| Oscillogram of Collector waveform vrs the Control Line. | image/jpeg | 69.027 kbytes |