This page is updated as the software evolves: Check back again occasionally...
Last update: 20020722
What is on this page:
This page describes the operation of the Version 2.0x source code of the PIC-based PSK31/FSK31 controller.
The discussion of Version 2.0x source code as well as compiled .HEX files may be found here.
Interfacing with the hardware:
All software/hardware timing has been adjusted for a CPU clock speed of 3.579545 MHz (approximately...) using an NTSC Colorburst crystal. Using any other speed will require careful readjustment of the timing routines: Use of a slower clock is not recommended due to the "busy-ness" of the software during the interrupt-service routines.
For schematics showing examples of how to use the PIC to transmit PSK31 or FSK31, go to the following pages:
It is essential that power supply pins be "decoupled" with "bypass" capacitors - a 0.1 uf capacitor across the power supply pins of the PIC is a good practice. As you may know, RF stages (such as oscillators and amplifiers) also require RF bypassing to ensure good, stable operation.
There is a "gotcha" with the PIC, however. If, for example, you choose to use the KEY_OSC pin to power your transmitter's oscillator directly (which is permissible if you need only 10-15 milliamps or so) then you must also - somewhere - provide a bypass capacitor for that oscillator.
The "gotcha" is this: If you put, say, a 0.1 uf capacitor directly across the KEY_OSC output pin of a PIC and ground, when the pin changes state, a brief current spike occurs as the capacitor (which, for an instant, looks like a dead short) goes from a discharged state to a charged state (or vice-versa.) This "glitch" may cause the output pin of the PIC to not change its output state as expected.
There is an easy solution to this: Simply put a 10-15 ohm resistor in series between the output pin of the PIC and capacitor and everything will be fine. Make sure your oscillator can tolerate a bit of voltage drop, however: Both the external 10-15 ohm resistor and the output transistor in the PIC itself will contribute to a slight voltage drop - probably on the order of a few hundred millivolts. If the drop can be tolerated, an emitter-follower (or a combination NPN/PNP switch) may be used.
Note: Keep in mind that the PIC should only be required to source 20 milliamps or so from an output pin.
|
The PSK31 mode has been affectionately called the "warble" - obviously because of the way it sounds. It gets its unique sound because of it's phase/amplitude modulation. Typically, the start of any PSK31 (or FSK31 transmission, for that matter) begins with a pure "warble" where a string of "zeros" are sent - each represented by the carrier changing state 31.25 times per second- to allow the receiver to synchronize before the first character of text is sent: PSK31 changes amplitude and phase while FSK31 changes frequency slightly. This portion of the transmission has a very distinctive sound and upon hearing it, you'd agree that "warble" is an appropriate description. |
Original EEPROM Beacon mode:
This code was written so that the PIC programmed with the version 2.0x software could be dropped into a socket where version 1.0x had been used - with no modifications. The "original" EEPROM Beacon mode is enabled simply by leaving PB5 floating.
In this mode, the EEPROM contents will be played out exactly as was done in version 1.0x: The EEPROM contents will be sent repeatedly, with approximately 2.5 seconds of "warble" (i.e. phase shifts) sent between each repetition. The message to be sent in this mode must be programmed into the PIC's EEPROM either at the time the PIC is originally programmed, or via the serial port if the PIC is temporarily set to the SERIAL PORT mode.
Note: In this mode, both PTT_OUT and KEY_OSC
are
always
active.
The Serial Port mode:
This mode is enabled when PB5 is grounded. Serial data is inputted to pin PB6 as described below:
Serial input is expected to be the same polarity as that output by a
computer's RS-232 port: All that is required to connect the
PIC
directly to an RS-232 port is a series resistor to limit current into
the
serial input pin, RB6. For bipolar or unipolar inputs
(i.e. 0-5 volts, or even 0-12 volts) a 2.7k resistor is appropriate and
for bipolar inputs (i.e. -12 to +12 volts) up to 10k may be used.
If you are driving this input directly from another device that runs
from
the same supply as PIC, then the resistor may be omitted completely.
|
If you are building your own interface, you should realize that RS-232 data is, by definition, inverted - that is, a "0" is a "1" and vice-versa. This is a result of the fact that RS-232 drivers, as defined in the standard, invert the logic level applied to them. For this reason, if you intend to drive the PIC with another device and are not using an RS-232 driver (i.e. to save power, reduce parts count, etc.) you will need to take this inversion into account. This inversion may be done in software (if the option is available to you) or with the an appropriate logic gate, or with a simple resistor-transistor circuit such as that shown to the right. It should be noted that pin RB6 has an internal pullup resistor so an external one is not required on the collector of the transistor.
The serial input operates at 1200 baud, 8 bits, 1 or 2 stop bits, and no parity. Internally, the MSB (8th bit) is ignored, limiting the input characters to the range of 0-127 (decimal.) Additionally, when the beacon is transmitting, the serial input is completely ignored. For "handshaking" indication, one may observe the status of the PTT_OUT pin (RB0) - and only if it is low is the serial data input available.
There are a number of commands available for control of the beacon. These use some of the less frequently-utilized control characters. The table below shows the official ASCII name, the hexadecimal code, and the corresponding control key. These commands are defined as follows:
Also note that many "dumb terminal" emulators default to using some of the above control characters to perform special functions: The ESCape key, for example, is often used to enter the "command" mode of the program: It may be necessary to re-define the use of these special characters in your program, or define a macro (if your program supports them) to send the appropriate control sequences.
Sending a message:
There are three characters that cause a message in RAM to be sent:
To force a playback of EEPROM contents ONLY, the following sequence is recommended:
<STX> <ETX>
The <STX> command clears the buffer and the <ETX>
command sends the RAM contents (which are now empty) followed by the
EEPROM
contents.
Important notice pertaining the use of a PIC16C84 versus the PIC16F84:
For the PIC16C84 version, the available RAM is 16 bytes instead of 48 for the PIC16F84. This means that the PIC16C84 version may hold up to 15 characters in RAM for a message or transfer up to 16 characters to EEPROM at a time. Keep this in mind when reading the discussion(s) below.
A few comments on loading the RAM
buffer:
Up to 47 characters may be stored in RAM. If more than 47 bytes are entered into RAM, the pointer will simply get stuck at the last byte which would be character 48. What's that? 48? Didn't I just say 47?
I did. But it should be noted that the <ETX> and <ESC> characters are saved in RAM - this is necessary both to mark the end of the text and to indicate the desired sending mode. For this reason one RAM location is required for storing this information. The "Transfer to EEPROM" command does not need this, so 48 bytes are available for THAT command... (In case you were wondering...)
Transferring data into EEPROM:
The <DC1> character (11h, control-Q) takes the current RAM buffer data and copies it into the EEPROM, terminating the EEPROM data automatically with the FFh character needed to signify the end of the text. Note that only as many bytes may be entered as there is room in the RAM buffer (48 bytes) so the EEPROM may NEVER be filled to capacity with just this command. Once this command is given, wait at least 250 milliseconds before issuing ANY other command.
A "companion" command uses the <DC2> character (12h, control-R) appends the current RAM buffer data to what is currently in the EEPROM. The use of this command in conjunction with the <DC1> character command allows all 64 bytes of the EEPROM to be filled. Multiple appends may be invoked (which is useful with the 16C84 which can only transfer 16 bytes at-a-time) and any attempts to put any characters past the 64th into EEPROM will simply be ignored.
Again, if either of these command is given, wait at least 250 milliseconds before issuing ANY other command to give the PIC time to write to EEPROM.
Operation of the Serially-Initiated "BEACON MODE":
(NOT to be confused with the mode that is operated when pin RB5 is left ungrounded...)
Sending a <DC3> control-S (13h) will put the controller in the beacon mode. This is done internally by setting the MSB of the first EEPROM character (byte 0) allowing the PIC to "remember" whether or not this mode was enabled even after being powered down.
In this mode, a preamble "warble" will be sent (about 2.5 seconds of "zeros") to allow synchronization of the receiver followed by the contents of the EEPROM. This is followed by a "tail" consisting of a dead carrier of about 750 millisecond duration: This "tail" allows the squelch of the receiving program to gracefully close, reducing the probability "garbage" characters.
Following this is a pause of approximately 1.3 seconds where only the PTT_OUT (PB0) line is dropped. It is ONLY during this "window" that the "stop EEPROM Beacon Mode" command (using the <DC4> character, control-T, 14h) will be recognized. If you are using a host computer it is recommended that the PTT_OUT line be monitored to determine when this command may be recognized and when you have "seized" control of the processor.
Note: The KEY_OSC line is always high during beacon transmission - i.e. unlike the PBB_OUT line, it does not go low during the "pause" between beacon transmissions. This allows the user to leave the oscillator on continuously if this is so-desired.
It should be further noted that upon going into and out of beacon mode, the processor will experience a forced watchdog reset, causing all I/O lines to momentarily enter a Hi-Z state. Depending on your monitoring logic (if you have any) you may wish to apply pullup/pulldown resistors to prevent falsing.
Using an external timer to control the beacon timing:
While in the serially-initiated EEPROM "BEACON" mode the SERIAL INPUT line may be used to control transmission. If this line is held LOW (as is the case on an RS-232 output that is in the idle state) or if it is grounded the message will automatically repeat after the 1.3 second pause.
If this line is HIGH (or disconnected) then the beacon mode will halt after (dropping the PTT_OUT line) the current message cycle is completed. This may be used to control a timed beacon: Pulling this line low for at least 1.5 seconds (but not for longer than how long it takes to send the message) will initiate a beacon transmission. Such a signal may come from a host processor or even a 555 timer.
It is also possible to effect timed beacon operation by asserting the !MCLR line to a LOW state momentarily to force a CPU reset.
PTT and OSCILLATOR control lines:
There are two lines used for controlling power to various stages of an attached transmitter. PB0 is the PTT_OUT line and it goes high when a message is being sent in any mode (i.e. in the strappable EEPROM-Beacon mode - PB5 is left open - it is ALWAYS high.)
The other line is the KEY_OSC line (PB1) and it is ALWAYS high when PTT_OUT is high, and it is ALWAYS (except as noted below) set to 0 when the PTT_OUT line is "unkeyed" - EXCEPT in the serially-controlled EEPROM PLAYBACK mode.
It does, however, allow for a special command, the <SI> control character (control-O, 0Fh) to set this to a HIGH state. This allows a host processor to turn on the oscillator BEFORE the beginning of a transmission so that its frequency may stabilize, but not pull full current of the transmitter's output stages.
Remember: The KEY_OSC line (PB1) is not unkeyed between repeats of the message during the Serially Initiated beacon mode.
A word of warning:
It is recommended that the keying circuit you use should fail in an "unkeyed" state. When the PIC is in its RESET state all I/O pins are in an undefined high-impedance state and internal pullup resistors are disabled.
When a bipolar transistor is used, this is usually not a problem as the leakage currents in a good bipolar transistor are enough to ensure that it will be turned off with good confidence. (If you are still worried, then you can't go wrong adding the pulldown mentioned below.) It should go without saying that if the output pin of the PIC is used to power the device (an example of this is to use the KEY_OSC pin to provide power to the transmitter's oscillator) then one need not worry about this.
If you use a MOSFET or a CMOS gate to key your transmitter there is no such guarantee! In these cases, always always always use a pulldown resistor to assure that the transmitter will not be keyed due to "floating" voltages on a MOS gate. A value of 100K or so should be more than sufficient for this task.
What can happen if you ignore this? You could end up with a transmitter that keys randomly if, for some reason, the PIC is being held in a RESET mode (or, heaven forbid, it crashes and the watchdog doesn't recover...)
The HEARTBEAT indicator:
NOTE: The Heartbeat indicator is operational in all operational modes - even the original and serially-initiated EEPROM BEACON modes!
An LED may be connected between pin PB7 and ground (with a series resistor) for an indication of PIC activity: The flashes may be used to determine what the PIC is doing and may be a useful troubleshooting tool - or possibly even used to trigger an external watchdog circuit.
It is recommended that, when used as an unattended beacon, that the LED (if used) be disconnected (by removing a push-on jumper, for example) to reduce power consumption. This pin will be pulsed high (i.e. the LED will be on) under the following conditions:
Please note that the HEARTBEAT is enabled by default upon powerup and it is enabled in both the pin-strapped EEPROM-SEND mode and the serially-initiated EEPROM BEACON mode: This means that if you do not want the LED to flash when in the serially-initiated EEPROM BEACON mode, you will have to disconnect the LED by removing the push-on jumper!
An important note about using MOSFETs switches for power control:
(This is important enough to warrant repeating...)
If the PIC is used to switch some power - say, key a transmitter or fire a drogue chute on a model rocket, it is important that the keying circuit be designed such that a floating input will always "fail" in the OFF mode. If the keying circuit is a bipolar transistor, the leakage currents from the bipolar device will generally assure a default OFF condition. It is recommended for bipolar devices and it is imperative if the interface to the device is a MOSFET or a MOS gate, you must use a pulldown resistor to assure that the device "faults" to an OFF condition. A resistor in the 100K-ohm range will usually suffice.
Software Reliability - (e.g. when
used for telemetry operation from remote locations):
Every reasonable effort has been made to design the software so that unexpected inputs will not cause the PIC's program to crash. If the software does crash it will most likely be due to some sort of power supply anomaly. One of the attempts made to improve software reliability is to use the PIC's onboard watchdog timer. As implemented, the watchdog timer requires a reset approximately every 18 milliseconds by the onboard software. If the software does not do this, a hardware RESET is executed.
The PIC also has available an external RESET line - the !MCLR
pin. This pin is normally tied high. When this pin is
brought
low, the PIC is in a state of RESET and all of its I/O pins are in a high
impedance (i.e. input) state with no pullups enabled.
 |
If additional reliability is desired, the heartbeat output may be used to trigger an outboard watchdog device. This outboard device should be capable of looking for a change-of-state on PB7 - pin 13 and momentarily bring the !MCLR input (pin 4) low to reset the PIC. Care should be taken to consider the timing of the output of the pin - a relatively long time-out period (3-4 seconds) is recommended. Note that if this PIC is used in a "timed beacon" mode (by forcing the serial input pin high - read about this in the User's Guide) then the heartbeat will cease: This should be taken into account by the external watchdog timer hardware. Please read other cautions in this user's guide.
Notice: It is possible (but somewhat rare) for the PIC's watchdog timer to fail to reset the processor. This may happen occasionally when the power supply voltage to the PIC rises relatively slowly or if there is excessive noise in the PIC's supply line. Proper power supply decoupling will help with the latter case and a zener-transistor based reset circuit (see the diagram to the right) may be be used on the !MCLR line if an external watchdog timer was not used. While this sort of "lockup" is rare, be prepared to deal with it if you have an application where the power supply voltage may rise very slowly - such as with a solar-powered transmitter (e.g. the voltage comes up when the sun comes out and slowly charges batteries.)
Note: If you are using solar-power, having a voltage-controlled switch using a comparator with a wide hysteresis can avoid the "slow-on" condition caused by a slowly-rising supply voltage.
Careful reading of the precautions given by the manufacturer (Microchip)
is highly recommended in "critical" applications - and pay close
attention
to reset circuits in the datasheet for the PIC16C84 or PIC16F84 -
whichever
PIC you are using.
For additional links/information on PSK31, MedFER, and LowFER operation, refer to those at the bottom of the PSK MedFER page.
Any comments or questions? Send an email!
This page copyright 1999-2002 and maintained
by
Clint Turner, KA7OEI.