=> [ Minutes index ] [ Packet index ] [ Home page ]

Fourpak Packet Radio Group

Minutes Of The 4th UK Sysop Meeting

11th September 1988

Agenda

  1. Welcome
  2. Election of Chairman
  3. Introductions
  4. Apologies / Minutes of Previous Meeting
  5. Packet Scene Update
  6. HF Packet
  7. Bulletin Lengths
  8. For Sale Bulletins
  9. Local Area Sysop Meetings
  10. New Forwarding System
  11. NETROM
  12. 153Kbps High Speed Links
  13. 2m Packet Frequency Allocations
  14. (Unknown)
  15. NETROM Parameters
  16. Any Other Business

1. Welcome.

Paul, G0DXX, welcomed all to the meeting and opened the proceedings with item 2 on the agenda, election of the meeting chairman. The meeting elected Paul, G0DXX as Chairman.

3. Introductions.

The Chairman then suggested that those present introduce themselves, this was done by all, with a brief mention of each node or BBS that they were associated with.

4. Last Meeting Minutes and Apologies.

There were no minutes available for the previous meeting. Apologies for absence were reported as part of the list put out by Paul on the SYSOP-4 attendance bulletin.

5. Packet Scene Update.

The Chairman then asked G3XDV to give an update on the packet scene as seen by the RSGB and the PWG.

Mike, G3XDV, then started his talk by briefly describing the relationship which is not an "us and them" but complimentary, their job being to provide the infrastructure and the Sysops to provide the user service.

It was suggested that band planning was outside the remit of the meeting, as although there was good representation of packet interests this was only a small section of the amateur population.

Mike pointed out that in his talk, it was not possible to cover all aspects over the whole of Packet Radio , but the general points were as follows:

From the 30th September most of the packet regulations will be implemented, this is not a new item but will permit us to use packet formally. It will allow the passage of amateur to amateur messages as the DTI do not consider that amateur traffic is "third party" as all licenced amateurs are considered to be a single "community".

It will not be a requirement to log digipeated packets and unattended operation will be permitted on appropriate frequencies. The licence will be more liberal than with other modes.

Mailboxes will be explicitely excluded from the terms of the licence, but the RSGB will act as agent for the DTI to issue Notices of Variation (NoV's) to existing licence holders.

The frequencies specified in the NoV's will be in the 50-51 MHz, 144-146 MHz and 1298-1300 MHz bands, with specific spot frequencies of 50.65 and 144.65 being used. Allocation of a frequency in the 1298-1300 band will not be automatic.

A MOST IMPORTANT point is that the NoV will PERMANENTLY vary the licence of the holder. If the DTI considered that the mailbox part of the licence is misused, the DTI would revoke the WHOLE licence, not simply the mailbox NoV.

It was worth remembering that these licence conditions are far in advance of many other countries, in the United States international "third party" traffic even between amateurs is illegal, and hence the DCE has had problems linking with the U.S., also high speed links, which will be covered by our "digital communication" would require permission from the FCC.

On the topic of 70cms operation, it was pointed out that the primary user of the band had an objection to unattended operation, but the RSGB were hoping that negotiations could continue on this topic. In the mean time, it was worth remembering that attended operation was permitted under the terms of the licence. In addition, a number of 432 MHz requests have now been cleared, some after only three months. All concerned are urged to use common sense and tolerance.

Lastly, DONT PANIC!

Mailbox stations that currently have a GB3 call will eventually be issued with a GB7 call, but this will be done after the initial issue of the NoV's.

HF forwarding and bandplanning should be discussed at the EU HF managers meeting next week, this should decide what is happening and provide a better idea where we are going and which mailboxes go forward. In the mean time it would be OK to run an attended HF gateway for mail.

Mailboxes need coordination as they are considered to be 'QRM Generators'!

NETROM operators will be OK to run unattended on appropriate frequencies, otherwise site clearance is needed.

Mike, G3XDV, then replied to a number of questions from the floor:

The CW ident - when new licence conditions are published - will be "after activity ceases or 30 minutes, whichever is soonest", rather than every 15 minutes in phone or CW (20 wpm max) as is the case at present.

A list of site clearances should appear in the repeater list which includes site clearance information.

70cms forwarding could be achieved by the use of ATTENDED cross-band digipeating and connect to this with one of the BBS ports. An attended digipeater should use the licencee's own callsign and not that of the BBS.

The text of the licence changes should be available to go out over the packet network prior to the publication of the Gazette notice.

Some of the 2m and 23cm nodes with GB calls may not need them after the new conditions are published, and should be able to notify the alternative address for an unattended digipeater.

It was agreed by the meeting that this discussion had also covered item 14 on the agenda. The meeting also proposed the RSGB should be thanked for their efforts over the last two years on behalf of the Packet community, bringing about considerable advances in the licence conditions.

13. 2m Packet Frequency Allocations.

Item 13 on the agenda ( affirmation of policy towards 2m packet frequency allocations ) was then discussed. The meeting agreed that the use should be:

144.650 - used for mailbox end users.
144.675 - to be kept clear of mailboxes
144.625 - for experimental use, perhaps with different protocols.

G3XDV was asked if European mailboxes would change to 144.650. It was pointed out that originally 144.650 was the only frequency designated for data. Eventually there may be some guidance from the IARU; Belgium already has a network on 650 and France seems to be moving.

6. HF Packet

The meeting then turned to Item 6, HF Packet. There were four sub-topics included, these being:

  1. @EU, Who needs it?
  2. HF forwarding problems.
  3. HF bulletins - no one wants them.
  4. Forwarding of mail to HF gateways.

There followed a lively discussion, during which the following points were made:

Over the last 3-4 months there has been a dramatic increase in traffic. Some bulletins have been duplicated by their being re-headed. It was thought that Europeans keep their bulletins far longer than we do.

If it is decided that @EU bulls are wanted, NTS stations should forward them, at present some mailboxes do not and thus this stops the bulls from propagating where they might be wanted.

G0BSX pointed out that the real question was 'does the NTS carry HF or EU?' If the message qualifier is changed within the UK, this might make it difficult if these bulletins "got out" and were re-imported.

Perhaps a small number of folks could be nominated to 'weed out' the bulletins! (No-one volunteered!).

It was agreed that a number of users have different interests, and what is of great interest to one may not appeal to another.

One suggestion was to make the system operate faster then we could get more.

A vote was then taken, on the question "Do we want @EU bulletins?" Of those present, 8 did NOT want it, 9 abstained and the rest were in favour.

As the meeting had a majority in favour of @EU bulletins, it was further agreed that ALL NTS mailboxes MUST handle @EU bulletins to allow their propagation through the network. It was suggested that if this were added to the end of the forwarding lists, in cases where links were difficult, this would prevent mail and other bulletins being swamped.

It was suggested that (d) could be covered by HF ports confering and generating a list of who they forward to, seeing who is closest and hence work out the routes.

Discussing (b), 80m appears to work well to Ashford (Kent) from Cornwall.This is a useful path to 'jump' the country.

14MHz was quite different, with uncertainty about frequencies and should a proposal be made to have only one mailbox on a frequency? Mike G3XDV pointed out that this problem has already been solved as the RSGB would only agree to one frequency for HF mailboxes per HF band.

Another problem was the number of repeated bulletins, particually from a couple of OZ stations.

7. Bulletin Lengths

The meeting then turned to Item 7 (lengths of bulletins).

A discussion was held on the question of "What is a reasonable length?"

A mailbox Sysop should NOT make huge files available to the users, and the forwarding of very large files often fails on a less than perfect route when a considerable amount of time has been spent by the box sending the file, only to have the link fail near the end. At the next forward time, the whole process starts again, causing the system to become slow.

On HF an ideal max is 5K or on VHF, 10K. There is a simple way of stopping large files as the addition of a file size limit in the forward file would cause files larger than that specified to be 'skipped over' at forward time.

There is a possible problem in that mail files "grow" as they pass around the system, thus a file could exceed the limit and "stick" if it grew beyond the limit. The main problem is to educate all users that there will be a limit on the file size.

The proposal was therefore put to the meeting "That there be an ABSOLUTE limit of 12K on file size, and encourage a 10K limit as user education".

26 were in favour
5 against
9 abstained, the motion was carried.

(The meeting then broke for lunch)

Upon reconvening after lunch, the Chairman suggested that the meeting consider the question of the venue for the next meeting. This would allow those who had to leave promptly to know what had been decided. The suggestion was made that the next meeting be held at Leicester, offered G6ZZE. Unless a further north location was put forward in the following week, it was agreed that the next meeting would be held on December 4th in Leicester.

8. For Sale Bulletins.

The meeting then discussed item 8 on the agenda (For sale bulletins - a firm policy).

Under the terms of the current licence, it may not be used for advertising. Amateur radio should not be used to sell things was the DTI solicitor's view.

If a digipeater passed on such a message, it could not 'reasonably' be construed that one could be expected to stop it. In the case of a Mailbox, however, if it could 'reasonably' be expected that the message should have been reviewed, then the Sysop would be held responsible. It was felt that Packet should not be different to, say, voice repeaters.

After considerable discussion, including varying definitions of an advert, the meeting did not agree on a policy, but left it up to individual Sysops to apply the licence rules to their individual mailboxes.

9. Local Area Sysop Meetings.

Item 9 was then discussed ( Local area Sysop meetings). The main questions that were posed were:

Local user groups already exist, in some areas. It was suggested that the London area forwarding 'was a mess' but after some discussion it was considered that such problems (which were not just London problems) were best solved by Sysops communicating directly.

Defining such areas would be a problem especially with an homogenous network, perhaps the formation of local groups should be encouraged perhaps centred on the local mailbox, several already exist such as MAXPAC, YAXPAC etc.

10. New Forwarding System

The meeting then turned to item 10 (the new forwarding system, summary, modifications and formal approval). G0BSX presented a talk on the subject of hierarchal mail, bulletin forwarding and software developments.

G0BSX started his talk by saying that the new forwarding system works well. He had only altered his forwarding file twice since the experiment started, which is a definite improvement over the previous system. However, the ideal system for forwarding would be a true heirarchal system, unfortunately the software comprising MBL 3.31, 4.31 and 5.12 does not properly cope with heirarchal forwarding.

Considering the system below:

         4             5              6
        / \           / \            /
       /   \         /   \          /   ..... etc
      /     \       /     \        /
     41     42     51     52      61

It would be useful to be able to do @4 etc and currently @4* is NOT supported.

MBL 5.12 is hinting that MBL is working on the form: < >.< >.< > ie the user specifies the route to the destination. This is not satisfactory as the address then is specifying the route. What is important is that the SYSTEM generates the route from the address, and can change it dynamically to suit conditions, for example, if a link becomes unavailable.

In current MBL forwarding, EXTFWD specifies a route to another gateway and tags mail onto it - it doesn't actually as it means 'all F mail must go to....' rather than finding out. It is also another program to run.

From the point of MBL 5.12, G0BSX reported his experiments and has come to the following conclusions: there are both benefits and disadvantages to the new software.

On the plus side:

On the minus side:

G0BSX ran it for a week and then took it off and went back to 4.31.

Both G8UFQ and G8AMD have software in development, the G8UFQ software is at alpha-test currently and will be at beta-test soon.

The G8UFQ software was presented at the last Sysops meeting and has the advantages of:

G0BSX then put forward four proposals on the current situation for discussion, these being:

  1. Approval of the current concept of addressing Proposals on system:
  2. 6 digit codes
  3. @ field - heirarchy
  4. @ field - Subject

Coding at the moment is _ plus 5 digits, it would be as easy and efficient to use a six digit code without the '_' and without the trailing '0's. There are currently only six digits available, but there seems no reason why this couldn't be extended.

Bulletins could be @AMSAT or @DCE, so the subjects could be split. (&@UK, @EU etc).

Use the @ field to give heirarchical fowarding, using the swap file, for example, SWAX -> _44* for bulletins. It is important to keep mail and bulletins separate.

All present were asked to discuss these points, while the meeting broke off for tea.

-- TEA --

After the tea, the meeting voted on the proposals.

  1. NTS forwarding system: Formal approval. This was carried unaminously.

  2. Removal of trailing '0's from NTS codes and Removal of the underscore character from the code start.

    It was pointed out that the removal of the underscore would cause problems, for example, some foreign calls stating with 4!! This part of the proposal was withdrawn, and the meeting voted on the removal of the trailing '0's only. The result of the vote was all in favour except one abstention.

  3. Heirachal @ field: all in favour except two abstentions.

  4. Use of the @ field for subject: This item provoked a lively discussion, it being pointed out that MBL 5.12 does not allow a blank @ field. It was decided to drop this suggestion during this discussion and substitute the proposal that:

'Information should NOT be in the @ field; this field being used ONLY for addressing, and the TO field for the subject'.

A vote was taken, all were in favour with the exception of four abstentions.

There was a proposal put to the meeting that there be a single designator for the @ field to cover the UK, after a number of proposals a vote was taken on 'the use of @GB to cover the United Kingdom'. There were 27 votes in favour thus the use of @GB was carried.

11. NETROM

G0BSX then turned to item 11.

He mentioned the TCPIP NETROM and its interface into the NETROM network. For co-ordination, each node needs a route to each other node and EACH USER needs to have a route to a node. Correct format should be used, with only one per region, if there is more than one per region, then these should be subservient to the region node. This really needs a co-ordinator.

12. 153Kbps High Speed Links.

Steve, G4FPV, was then asked to talk about Item 12 on the Agenda, 153kbps high speed links.

Steve started his talk by saying the equipment evolved from his interest in 10GHz working and in Packet. Some might not be able to make use of it, as 10 GHz was DEFINITELY line of sight when used with the wideband FM system he would describe, but it was thought that for point to point links, where the stations were well sited, this would not be a problem.

The equipment was designed to give a 153kB DATA path, it is NOT a packet link in that the data passed over the link does not conform to AX25 protocol, but it would support ANY DATA, thus allowing future systems to evolve without constraining the link to a particular format.

For the benefit of those who were not conversant with 10 GHz working, Steve then described a typical Gunn diode transceiver.

The Gunn oscillator is constructed in a waveguide cavity, the end of the waveguide being closed. The other end of the waveguide is defined by an 'Iris plate', which is just a plate with a hole in the centre. The distance from the Gunn to this plate determines the frequency of operation, a tuning screw in the cavity giving coarse tuning and small frequency changes can be effected by changes to the Gunn supply. This supply must be stabilised and in the range 6 to 10 volts. This voltage range might typically provide 100MHz fine tuning.

This oscillator is normally used as the local oscillator for an in-line mixer. This comprises a length of waveguide, connected to the output of the Gunn, with a diode suitably placed across the guide, the other end of this guide being connected to the antenna. As this is an unbalanced mixer, the local oscillator is radiated from the antenna and serves as the transmitter as well. If two such equipped stations make contact AND they are using the same I.F. frequency, full duplex communication results (One LO high and one low).

The output from such a system is approximately 1 to 10 mW, which with a suitable dish antenna can give line of sight communication over a 100km path.

In the high speed data system, the basic Gunn and mixer is used, with the mixer output fed into a 100MHz first IF, thence to a 10.7MHz IF and demodulator.

For the transmitter, the format is WBFM, the incoming data having a pseudo random binary code (PRBC) added to it to produce reversals, taking away any DC component of the data and allowing AC coupling.

In the receiver, a gating circuit fed with the same PRBC code and the received signal, recovers the data.

A problem arises due to the RX LO being also used as the transmitter, thus the transmitted data is impressed onto the received data. A solution to this was found by modulating the 110.7MHz second LO with the transmitted data, and the deviation adjusted to 'cancel' the outgoing signal modulation in the receiver. The cancellation is not perfect but is quite adequate for this use.

ONE of the Gunn oscillators is swept in frequency and a squelch circuit used to achieve carrier lock (which turns off the sweep), and allows code search, lock and timing recovery to occur. Low frequency tones are also added to the transmission to perform handshaking and housekeeping functions.

The system should be suitable for use in, say, 1MHz wide channels as it is fundamentally a WBFM system with 153kB modulation. The waveform applied to the modulator (the Gunn power supply stabiliser!) is filtered to remove the sharpest edges and reduce the bandwidth to an acceptable figure.

The equipment was set up and working in the meeting over a short line of sight path (two feet!) and after the main buisness of the meeting had been completed Steve offered to answer any questions individually.

15. Netrom Parameters.

The meeting then turned to item 15 on the agenda, NETROM parameters.

Two suggestions had been put forward, these were:

a. Parameter 3 (HDLC Quality) to stay at 192
b. Parameter 2 change to P2=100

This item provoked a lively discussion, with some present asking that the HDLC quality be kept (for TheNet) at 100 as this would tend to throw out poor links. It did not seem possible to define this on a country wide basis, some Sysops changing the value to force paths to change.

A suggestion was made that for routing of mail it would be useful to collate all the routing paths, however the system was volatile and people could not always use fixed or defined paths.

Modifications that were suggested were:

that Parameter 1 be raised to 70 from 50.

that the 'time to live' ( parameter 8) should be reduced from the NETROM default of 64. It was suggested that 15 was a reasonable figure.(TheNet uses a figure of 10 for its default).

Level 2 window reduced to 2 except for dedicated links which could stay at 7

The algorithm used for waiting was mentioned, it appears that a random dwait is used. It was suggested it would be better to set dwait low but Ppersistance higher as they are different methods, Ppersistance being considered much better than dwait.

The topic of TheNet alias's was then mentioned. Should they be centrally co-ordinated? With the G8UFQ software false callsigns are rejected, they must be at least 3 characters long and contain a number. The problem of alias's comes to the fore when there is a lift in conditions.

There is a problem in the Thames Valley area when a TCPIP 'user' disappears. A NETROM keeps outputting its table containing a 'defunct' node which is learnt by other nodes which will refresh it when it goes... is this perpetual motion at last?!

16. Any Other Business.

The meeting was then asked to look at item 16, A.O.B.

  1. G6FCI asked that the ATV frequencies not be used for forwarding. The meeting agreed NOT to use ATV frequencies.

  2. An item had been submitted to discuss the suitability of one of the Sysops It was agreed that this did NOT form part of the terms of reference of the meeting. It was felt that any censure should be done privately if it was necessary.

  3. A question was asked about making the meeting accountable, it was considered that it would be a good idea to publish the minutes of the meeting so that all could see what the Sysops meeting was doing. A suggestion was made that a precis could perhaps be submitted for the 'Radcom' bulletin section.

  4. On the 1st October callsigns would change. All were asked to either run BULLSTOP or make sure the appropriate entries were exchanged to prevent an 'outburst' of bulletins being forwarded.

  5. It was suggested that NETWORKING is really SEPARATE from mailboxes, and may require separate design and/or operators. Should a separate group be organised to see how it should be set up?

This brought the meeting to a close at 17:30

A vote of thanks was proposed to G0DXX by G8AMD for arranging the venue and chairing the meeting.

( End of Formal Meeting and Minutes, )

G8UFQ then gave an informal update on his mailbox software, and G4FPV demonstrated the 153kB high speed data link.

END OF SYSOP 4 MINUTES. (Author unknown)


=> [ Top of page ] [ Minutes index ] [ Packet index ] [ Home page ]