Recommended reading:

It is strongly recommended that you read the Version 2.0x User's guide before proceeding:  This explains some of the operation of the software's operation.

A brief description of the circuit:

Please refer to the FSK31 Exciter Schematic for the following description:

The oscillator:

Transistor Q1 is a typical crystal oscillator.  The raw data is applied to the frequency shift network through Ra.  The value of this resistor is not critical - 22k is a pretty good value.  Current through this resistor biases D1 into conduction when a high logic level appears at PB3, essentially shorting out Cp.  This causes a slight increase in capacitance (through Cs) in the feedback loop of the crystal oscillator, causing a slight change of capacitance at Cb and thus a slight frequency shift.  As it turns out, it is actually extremely easy to get the very slight (15.625 Hz) frequency shift required for FSK31:  Only a fraction of a pf change is required at Cb to effect the required shift and thus the capacitive divider consisting of Cs and Cp makes this job much easier.  Typically, Cs will be in the area of 3 to 10pf and Cp will be between 5 and 50pf:  More capacitance at Cs causes more shift, and more capacitance at Cp causes less shift.  It is recommended that the Cp have more capacitance than Cs for optimum stability.

Transistor Q2 is a buffer and the output of this circuit is suitable for driving TTL or CMOS gates.

The PIC's interface:

The serial port:

The serial port provides for remote control of the beacon transmitter, loading text into RAM or EEPROM, and enabling a standalone serially-initiated beacon mode.

The PIC is clocked at the NTSC colorburst frequency of 3.58 MHz.  Since we are using FSK31, we aren't even using the PWM output at PA3.  PB5 is grounded, enabling the use of the serial port at PB6.

The serial input data to the PIC (on pin PB6) is 1200 baud, 8 data bits, 1 (or 2) stop bits, and no parity.  Note that the PIC expects inverted serial data (i.e. the stop bit is a logical 0 or negative voltage.)  This may sound strange until one realizes that RS-232 ports output inverted data anyway - therefore, the PIC can be connected directly to an RS-232 port of a computer via resistor Rs.  For a more complete discussion of this interface, read about it here.

This resistor limits the current going into PB6:  For a bipolar RS-232 port with +-12 volt swing, Rs may be 10k.  If you are using this with a combination of devices - some of which have the full +-12 volt swing, or just a 0-5 volt swing (such as that being output the output pin of a host controller) then a 2.7k resistor is a good comprise.  Resistor Rs may be omitted if the host computer outputs a logic level and is operated from the same regulated supply as the PIC.  Finally, note that all of the B ports on the PIC have weak internal pullups - if one needs "normal" logic levels, the collector (or drain) of a transistor may be connected to PB6 without the need of a pullup.

It is important to note that while the PIC is transmitting, the serial port is "deaf" - that is, the PIC is busy sending data, so it doesn't "look" at the port.  If interfacing with a host processor is required, that processor may look at pin PB0 to determine when the serial port is active.  See below for more info on how these keying lines operate...

The Heartbeat signal:

A Heartbeat signal appears on pin PB7.  This pin pulses high to indicate the current state of the PIC as follows:

• During the first bit of a varicode character being transmitted (for 32 milliseconds)
• While the PIC is awaiting an input character.  It will flash approximately once per second for about 4 milliseconds.
• While an ASCII character is being received on the serial line (approximately 8 milliseconds.)

This signal may be disabled with a software command (using a Control-X - code 18h) or re-enabled (using a Control-W, code 17h) to reduce current consumption.  The heartbeat is enabled upon powerup, so for applications where power consumption is critical, the heartbeat jumper should be removed.

Transmitter keying lines:

There are two keying lines available from the PIC:  Pin PB0 goes high whenever a transmission is in progress.  This may be used to key a transmitter - or just the final amplifier stage.  In this application, Q3 is used to boost the current output capability of the PIC.

This line may also be monitored by a host processor to determine when the serial port is active:  When this pin is high, commands sent to the serial port will be ignored.

There is another keying line available:  PB1.  This is intended for keying an oscillator.  Since frequency stability is important in either PSK31 or FSK31, provisions have been made to power up the oscillator stage and allow the oscillator to stabilize somewhat.  In low-power operation, it may be important to be able to power up the oscillator stage without activating all stages of a transmitter.  This pin may be activated using the appropriate command (a Control-O, 0Fh) via the serial port.

Even if one does not require separate keying, it should be noted that pin PB1 will always go active when pin PB0 goes active.  In all cases, pin PB1 will go inactive when PB0 does (except in the serially-initiated beacon mode, of course.)

Miscellaneous notes:

• Pin PB4 controls which mode the PWM outputs.  For FSK31 operation the state of this pin is irrelevant - leaving it open will reduce current consumption by a very slight amount and will enable the "AM" mode, while grounding it selects the "Balanced Modulator" mode.
• Pin PB5 selects whether or not the serial port mode to be enabled:  Leaving it open enables the "Version 1.0 compatibility mode" where the EEPROM contents are repeated (without unkeying briefly - unlike the Serially-initiated beacon mode described below.)  Grounding this pin enables the serial port.
• During testing, I was curious about how low voltage the PIC and oscillator would function.  As it turns out, both the oscillator and the PIC would begin to work at voltage as low as 1.8 volts.  This is somewhat below the rated voltage of the PIC, so operation below 2 volts isn't guaranteed, of course.  The amount of frequency shift was also affected by the change in supply voltage - as was the oscillator's frequency.  The moral of this story?  If you want reliable, stable operation, then a regulated supply is a must - but it need not be a 5 volt supply.

As mentioned in the Version 2.0x User's guide it is possible to enter an unattended beacon mode via the serial port.  This mode, initiated by sending a Control-S (13h), simply repeats the EEPROM contents - with a break of approximately 1 second between transmissions.  In this mode, PB0 is unkeyed briefly between transmissions (but PB1 is not) allowing a host processor to determine when the serial port is available:  During this interval, a Control-T (14h) may be sent to exit the beacon mode.

When in the Serially-initiated beacon mode, the serial input (pin PB6) must be grounded for continuous operation.  If this pin is allowed to float or held in a high state the PIC will "unkey" pin PB0 and stop transmitting at the end of the current beacon cycle.  When in this state, pulling PB6 low for at least 1.5 seconds will start a beacon cycle:  This sort of signal may be provided by a simple timer (i.e. a 555) or a host computer.

"Where's the software for this?":

The source code for this is written in both C and assembly.  Go to the The Version 2.0x Source Code page for a description and a link to the actual source code.  Also highly recommended is reading the Version 2.0x User's guide.

A real-world implementation:

Ralph Wallio, W0RPK, flew a version of this FSK31 transmitter on an April 14, 2001 NSTAR flight (read about the flight and the "post mortem" here.)  The general idea was to provide an HF telemetry beacon to allow reception at farther distances.

The 10 meter FSK31 telemetry beacon flew on this flight, but the results were a mixed success:  Most obviously, one is at the mercy of 10 meter propagation - which can be fickle.  Another problem turned out to be frequency stability:  It is imperative that the transmitter remain stable throughout the transmission in order for data be properly decoded.  The latter problem was the most serious:  The transmitter drifted excessively during the course of the transmission, making tracking and demodulation nearly impossible.  The suspected culprit(s) are probably some combination of thermal instability due to thermal conduction and radiation (heat dissipation by convection nearly ceases at high altitudes due to the rarefied air), possibly inadequate buffering between the final and oscillator stages, and possibly the 10 meter antenna's impedance changing due to antenna movement.

Was this flight a failure?  Because one often learns more from a "failure" than a success, I would say no.  The entire purpose of flying the beacon was to test a concept and discern any difficulties:  Since both of these goals were accomplished, it was a success in that regard.

(I'd like to thank Ralph and others mentioned on the above linked page.  It was Ralph in particular who goaded me into developing the "Version 2.0" software with specific provisions for allowing telemetry operation.)

References:

For additional links/information on PSK31, MedFER, and LowFER operation, refer to those at the bottom of the PSK MedFER page.

Additional information:

Posted 18 November, 2000:

Subject:  FSK31 Explained

>From Peter G3PLX

FSK31 has been mentioned a few times again recently on this reflector. Perhaps this is a good time to describe, for those who have not met it before, what FSK31, how it relates to PSK31, and put it into perspective.

FSK31 was not part of my original PSK31 system but was introduced by UT2UZ and has been carried forward into Digipan. It should really be called MSK31, since it uses Minimum Shift Keying, a  well-established mode commercially. You will hear a lot of MSK in the 300-400kHz band transmitting DGPS telemetry. It's basically FSK but with the shift set to half the baudrate - the lowest shift you can  use  without the performance dropping off. For 31.25 baud this means the two tones are 7.8125Hz either side of the centre. If you think of the phase of a carrier that is 7.8125Hz low of centre, it lags by 90 degrees after 32mS, so MSK is actually equivalent to BPSK but using +90 and -90 degree shifts instead of  0 and 180. The beauty of MSK is that, like all forms of FSK, the amplitude is constant and so a linear transmitter is not needed. This is why FSK31 has been designed into the balloon experiments recently announced on this reflector, and why PA0OCD chose to use it on 2m with a particularly bad transmitter.

With BPSK the phase scope display shows two vertical lines, top and bottom, and with FSK31 it shows two horizontal lines left and right.  If you think about it, since the noise is the same in all directions, the noise performance of FSK31 should therefore be exactly the same as BPSK. Given the advantage of constant amplitude, does this mean that FSK31 is a good idea?

To answer this we need to consider two things. Firstly there is a need to synchronise the receiver timing to the distant transmitter.  Also, since our equipment (and indeed the ionosphere) is only marginally stable enough to work at bandwidths of 31 Hz on HF, we need to have AFC.

Let's first see how these things affect PSK31. If you picture the spectrum of a BPSK signal you can see that it's either a tone in the centre or two tones either side of centre, or somewhere between the two, but at all times it's obvious from the natural symmetry that there is going to be a way to locate the middle of the signal. Notice that the AFC system doesn't need to know anything about the data content or the timing. To get in sync. the PSK31 receiver derives it's timing from the 31Hz amplitude modulation on the signal. The Varicode alphabet has been specially designed to make sure there's always enough AM to keep the receiver in sync. Notice that we can extract the AM from the incoming signal even if it's not quite on tune. In PSK31 therefore, the AFC and the synchronisation are completely independent of each other.

Now lets consider MSK. The spectrum can be either a tone 7.8Hz high of the centre or a tone 7.8Hz low of centre, or somewhere in between.  There is no natural symmetry now. If we want to design an AFC system that will do it's job right, it WILL need to know something about the decoded data. On the timing side, there is no amplitude modulation so the only way to get the timing is to decode the data and line up on the edges, as is done in other FSK systems like AMTOR and Pactor. But there's a catch-22 situation here: to decode the data we must be on--tune, but to be on-tune we must have AFC, but to have AFC we must decode the data.

This doesn't mean that FSK31 can never work at all, but in practice it means that both the AFC and the synchonisation will be more critical and prone to malfunction. This is inherent in any MSK system. It's not a problem where the frequency stability is good and we don't need AFC, but in amateur HF (and particularly VHF) working, it's going to give trouble. It's interesting to note that although MSK is used on 300kHz for DGPS, in Europe at least the DGPS systems in the 1.6-4MHz region are all PSK.

There's another problem that relates specifically to FSK31 as currently implemented. To make sure that there are always enough transitions in the data to keep the timing in sync, the data is differentially encoded, just like in AX25 packet. The idle signal becomes a 50:50 mark/space squarewave rather than a constant mark or space tone. But it does mean that one corruption on the radio link causes two corruptions in the differentially-decoded data. In AX25 this isn't a problem - even one error causes the whole packet to be re-sent, so a second error is no worse - but in the FSK31 scenario the second bit error could easily cause a second character error.

I am saying all this to warn people away from thinking that FSK31 might be the way to go. This isn't just a bit of "not invented here" on my part: I have already been this way and rejected it. I had all but abandoned the idea of a narrow-band HF RTTY replacement using MSK when I saw the BPSK work of SP9VRC.

I therefore suggest that we don't tread the FSK31 path, at least not for the kind of things we are doing currently with PSK31. There are ways of generating high-quality high-efficiency PSK31 which do not require linear transmitters, and one has already been described in this reflector using hard-keyed PSK and an auxiliary AM modulator. I would even suggest that for applications where linearity is difficult but band congestion is not a problem, we simply tolerate the extra sidebands!

Thanks for your time.
73
Peter

Subject:  FSK31

>From Peter G3PLX

Since my last message about FSK31, in which I explained how it worked and compared it's performance with PSK31, I have learned that my explanation was wrong in one detail.  I said that FSK31 was constant-amplitude and I now know that this is not correct, at least not in the implementation of FSK31 implemented by UT2UZ in Digipan (I will call it FSK31d here).

The keying in FSK31d does involve a change in amplitude, in fact a dip down to 70% of the maximum as the signal advances or retards in phase by 90 degrees. This is the same dip that occurs in QPSK when a 90 degree change occurs but in FSK31d there is a dip in every symbol so the power meter doesn't kick up as you type like it does in QPSK or BPSK. The spectrum width of FSK31d is exactly the same as that of BPSK and QPSK. If the amplitude had been constant, the spectrum would have been slightly wider. I suggested earlier that FSK31 should really be described as MSK31 but this is only correct for constant-amplitude FSK31. FSK31d is effectively BPSK with a phase offset of 90 degrees so it could be described as OBPSK (Offset Bipolar Phase Shift Keying).

The advantages of constant-amplitude FSK31 (MSK) over BPSK is that it doesn't get wider when the transmitter is overdriven. The 30% amplitude modulation present in FSK31d means that it WILL get wider when the transmitter is overdriven, but not by very much. In fact if you overdrive an FSK31d transmission, it never gets wider than an MSK signal.  FSK31, as implemented for the high-altitude balloon experiments described in this reflector recently, is constant-amplitude FSK31 and therefore true MSK.

The performance comparisons I made between PSK31 and FSK31 remain valid. Although FSK31d has amplitude modulation, it not used in the synchronisation process. If it had done, the timing would suffer if the transmitter was overdriven and constant-amplitude FSK31 could never work at all!  My point about the interaction between AFC and timing still applies and this was the fundamental reason why I discarded MSK myself in the early days. Using BPSK means that the receiver can pull into tune and into sync quicker and more accurately and I thought that this advantage of BPSK over MSK for live two-way QSO's was important. I knew that non-linearity in the transmitter would make the signal wider, but the typical performance of present-day SSB transmitters was enough to keep the signal as narrow as MSK would have been. In any case, Clover (which is effectively four simultaneous PSK signals) and Pactor-2 (two simultaneous PSK signals) had already been well established. I don't accept the argument that PSK31 is too difficult to set up: the ITU definition of the amateur radio service says that we are capable of training ourselves to get it right. It's just unfortunate that a typical soundcard will  overdrive a typical mike input by 50dB!

I can see that MSK could have applications for VLF bands where the frequency stability is not a problem. It would also be suitable for beacons and broadcasts where it doesn't matter if it takes a bit longer to pull-in at the start, but in these cases there would be also a good case for using strong error-correction, something which was deliberately omitted in PSK31 because of the way it slows-down the live two-way QSO.

73
Peter

Return to the PSK MedFER page

Any comments or questions?  Send an email!