File contents

		 Update-Information for PTC-II-Firmware-Version 3.0
		 ==================================================

The main improvement the version 3.0 firmware offers, is support for
the new DSP plug-in modem for packet radio. (Only the PTC-II, not the
PTC-IIe). It also offers the possibility to interrogate a GPS receiver via
the RS232 interface. The last improvement allows remote control
position finding via PACTOR or PR. A number of other small improvements as
well as the obligatory "bug fixes" round off the update.

1. New features
---------------

- Support for the new SCS DSP Packet radio modem (PTC-II only).
- Requesting position data from a GPS receiver.


1.1 Support for the new SCS DSP packet radio modem
---------------------------------------------------

1.1.1 General
-------------

Simultaneously with the release of the new version 3.0 firmware, a new
plug-in DSP modem is being offered to complement the existing two PR
plug in units (1k2/2k4 or G3RUH-FSK). This new modem will support 300, 1k2
as well as 9k6 and 19k2 Bd. The actual modem software is loaded from the
main PTC-II processor shortly after switching on. It is a part of the
firmware and can thus be improved and expanded via firmware updates. Now
the enormous flexibility of the PTC-II concept, also includes the packet
radio side. The DSP concept for PR also naturally allows the software
setting and adjustment of all modem parameters (e.g. the output level).
The previous adjustment of potentiometers is now a thing of the past. (see
1.1.5).


1.1.2 DSP-Modem insertion and configuration.
--------------------------------------------

The DSP-PR modem offers, together with the firmware version 3.0 the
following modes:-

   - 300 Bd AFSK (Modem tones are fixed at 2300/2100 Hz, "High-Tones")

   - 1200 Bd AFSK

   - 9600 Bd FSK (Direct-FSK according to the G3RUH standard)

   - 19200 Bd FSK (Direct-FSK according to the G3RUH standard)

The choice takes place with help of the Baud command in the pac:- menu or
the %B command in hostmode. Both commands are independent of ports.

Example: setting to 9600 Bd:

	pac: B 9600 <Enter> (default port is set to 9600 Bd.)

	pac: B 2:9600 <Enter> (Port 2 is set to 9600 Bd.)

	 (see the Baud command in the manual!)

The choice or setting of the correct modulation for the actual baudrate is
automatically made by the PTC-II. The DSP PR modem is capable of full
duplex in all modes.
With direct FSK according to G3RUH, mixed Baudrates for TX and RX are
allowed, e.g. 9600 Bd for receive and 19200 Bd for transmission. (Setting
is as before with the conventional FSK modem by giving two Baudrates with
the Baud or %B commands.) Naturally, the DSP PR modem contains a high
performance Data-Carrier-Detection (DCD) in all modes.

The PTC-II saves the Baudrate values for ports with DSP modems in
flash-ROM, so that these settings are not lost even after a RESTart or
firmware update.


1.1.4 Specialities of 300 Bd AFSK
---------------------------------

300 Bd AFSK is normally used via an SSB transceiver, and usually requires
a tuning tolerance of +-30 Hz for satisfactory performance. The DSP modem
thus requires a tuning indicator for this mode. As the PTC-II only has
three LEDs for each port (PTT, Connected, Carrier), a two dimensional
tuning display cannot be realised. Instead, the tuning takes places by using
the brightness of ONE LED. With a bit of practice, one can obtain a tuning
tolerance of +-10 Hz using this method.

The fine adjustment of a received signal takes place with the help of the
brightness of the PTT LED. Maximum brightness corresponding to the best
tuning. The tuning display via the PTT-LED is ONLY active when a signal is
recognised (i.e. initial tuning by ear until the "carrier" LED lights). If
ONLY the PTT-LED lights, then the transmitter is keyed momentarily. The
PTT LEDs then have their normal function. Note: The "carrier" LED never
lights whilst transmitting in full duplex operation, even when a signal is
received.

In practice, the tuning takes place by slowly turning the tuning knob
until the carrier LED lights. With an active carrier LED, further careful
tuning backward and forward is made until the PTT LED is at its maximum
brightness. The PR monitor can also be turned on as a further tuning help,
to see if valid data packets are being received.


1.1.5 New command TXLevel in pac:- menu
---------------------------------------

As with the PTC-IIe, the PTC-II, now offers a command for setting the
output level when using the DSP PR plug-in modem. This command is the
TXLevel command, and is independent of port numbers. Values between
20-2000 mV (peak/peak) are allowed. The level for the AFSK modes (300 Bd
and 1k2 Bd) as well as the FSK modes (9k6 Bd and 19k2 Bd) can be separately
adjusted. The choice of the level to be adjusted (AFSK or FSK) takes place
with the argument "AFSK" or "FSK" that must be placed BEFORE the actual
level value.

Example:  pac: TXL AFSK 300 <Enter>    Sets the AFSK level of the default
				       port to 300 mV P-P.

	  pac: TXL 2:FSK 1100 <Enter>  Sets the port 2 FSK level to 1100 mV
				       p-p.

The default values set by the firmware are TXL AFSK 300 and TXL FSK 800.
The PTC saves the TXL values in flash-ROM so that the values are NOT lost
even after a RESTart or firmware update.


1.2 Calling up a position from a GPS receiver
---------------------------------------------

1.2.1 General
-------------

The "Global Positioning System" (GPS) has very quickly become a standard
for all areas that require exact positional information e.g. shipping,
in-car navigation systems etc. Today, GPS receivers are cheaply available
and widely used. The firmware 3.0 for the PTC-II offers the possibility to
link the GPS technology with PACTOR, and also to PR. It now becomes
possible for example to call up the present position of small ships or
deep sea yachts via shortwave, without requiring a PC to be running on the
mobile station and without a ships radio operator.


1.2.2 Connecting the GPS receiver
---------------------------------

The GPS receiver must be connected to the secondary serial port of the
PTC-II. The input and output of the secondary port is brought out to the
normal SUB-D plug of the RS232 interface, and is available from there.

The secondary port input is connected to pin 4 of the RS232 socket.
The secondary port output is connected to pin 9 of the RS232 socket.
(Ground is connected to pin 5. Do not forget the ground connection!)

SCS offer a special Y cable which splits the leads to and from the RS232
socket on the PTC-II so that two separate DIN-9 RS232 standard sockets are
available. By using the Y cable, it is possible to connect a GPS receiver
and a PC to the PTC-II without needing a soldering iron.

GPS receivers normally work at a speed of 4800 Bd from their serial NMEA
output. The PTC-II normally operates automatically at 4800 Bd on its
secondary serial port.
If both PR sockets are occupied with a modem, then there is no free
baudrate generator available. In this case the PTC-II uses the baudrate of
the TRX port for the secondary serial port. (Most transceivers can be set
to 4800 Bd for remote control. The typical 4800 Bd for the GPS receiver
can be set using the TYpe command in the trx:- menu, without having to
sacrifice the TRX remote control ability.)

IMPORTANT: Some GPS receivers offer various protocolls for control via the
	   serial port. The PTC-II expects an NMEA compatible GPS
	   receiver. The GPS equipment must therefore be set to "NMEA
	   compatible"!

1.2.3 the POSition command. Practical aspects of a position request
-------------------------------------------------------------------

As soon as a GPS receiver is connected, the PTC-II evaluates the incoming
data and saves the actual position with the corresponding (GPS) time. The
user can call up this position data with the POSition command in the cmd:-
menu. The POSition command is also a remote control command, and available
for use via PACTOR and PR. It can also be called up by users of the
PTC-box.

The position information normally has the following format:

  GPS POSITION REPORT
  -------------------
  Latitude:   50�430' North
  Longitude: 008�980' East

  Recorded at: 19:25:48 UTC/GMT

The POSition command allows the argument NMEA.

  Example: cms POSition NMEA <Enter>

The PTC-II in this case gives out the original NMEA compatible position
string ("sentence") - exactly as it was received from the GPS receiver.
NMEA compatible strings are "understood" by various navigational programs,
and can thus be almost universally used.

The NMEA compatible position string usually has the following format:

  $GPGGA,192552,5005.430,N,00845.983,E,1,03,2.7,106.3,M,47.8,M,,*4F

In hostmode, the command PS gives an output of the present position.
The NMEA compatible positions string is ALWAYS given as an
answer to a PS command. The argument NMEA is not required / allowed.


2 Improvements and de-bugging
-----------------------------

- XU command expanded with the "wildcard" (*) (e.g. XU DO* 0000).
  Priorities without the "wildcard" in the callsign dominate, e.g.
  XU DO1XXX 333 has priority despite the DO* entry in the user list.
  "Wildcards" can be used for example to suppress illegal access to the
  PR->Pactor gateway.

- CSDelay can now be remotely controlled and the value requested over
  PACTOR. It does not however appear in the remote HELP list. The command
  is only there for experimental use. It may be used to determine the
  propagation delay over a particular path. The "slave response time" and
  the slave CSD can be used to give the effective propagation time between
  master and slave stations to an accuracy of around 1 mSec.

- The BMsg parameter now works on PSK31 similarly to Baudot RTTY
  operation.

- The Baudot RTTY transmit routine has been expanded to that even RTTY
  receivers with active USOS always receive the correct text, when receiving
  a row of figures interspersed with spaces as can occur in an HF contest.

- LFignore parameter values expanded to 0-2. Parameter 2 activates in
  addition the multi-CR suppression with RTTY and AMTOR/FEC reception.
  (Multiple <CR> in a row without other characters between are suppressed
  except for the first <CR>. In the EOL (End Of Line) sequence in some
  US-American controllers, <CR><CR><LF> no longer causes an unwanted empty
  line. A number of commercial RTTY services (e.g. Meteo services) also
  still use the historical double-CR at the end of every line. These
  services can be better copied when LF=2.

- Bug fixed where under certain circumstances, PACTOR 1 users with non SCS
  controllers, received a graphic character and a small m instead of a
  <CR> when receiving text from a PTC-IIe. In PACTOR 1 a <CR> is usually
  interpreted as a line-feed.

- Two bugs in the antenna attribute have been fixed. On returning to
  standby, the resetting to antenna 0 now no longer takes place. On
  choosing a channel through the PR->PACTOR gateway, an antenna attribute
  following a timer attribute is no longer just ignored. (E.g.:- #:T0A1
  was always ignored whether Timer is valid or invalid; #:T0 #:A1 however
  had always worked.)



Have fun with the new firmware!


73s de Peter DL6MAA for the entire PACTOR team.