Re: callsign limit

Re: callsign limit

[IT3 Stuart Blake Tener]

Mr. Hast, et alia:

Though only Canada has started issuing 2x4's as far as I know.

While special event stations (even for Packet) are able to get 2x1 callsigns in
the United States. Jordon also issued 1x1 calls too.


-- 
IT3 Stuart Blake Tener, USN(RC), N3GWG
Beverly Hills, CA
mobile: (310) 358-0202
Nextel: 124*233172*14
e-mail: teners@bh90210.net

Re: callsign limit

[Chuck Hast]

On 5/31/06, IT3 Stuart Blake Tener <teners@bh90210.net> wrote:
> Mr. Hast, et alia:
>
> Though only Canada has started issuing 2x4's as far as I know.
>
> While special event stations (even for Packet) are able to get 2x1 callsigns in
> the United States. Jordon also issued 1x1 calls too.


Opps, guess that is going to give someone who has a 2x4 call a problem
if they try to use packet. I did not realize that ITU had changed the format,
will have to dig it up and see what they say.


-- 
Chuck Hast  -- KP4DJT --
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: callsign limit

[Robert Steinhäußer]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Hi! 

We're no longer on a linux subject (linux-hams), but I suppose enough
here are interested.

On Wed, May 31, 2006 at 12:12:03PM +0000, IT3 Stuart Blake Tener wrote:
> Though only Canada has started issuing 2x4's as far as I know.
> 
> While special event stations (even for Packet) are able to get 2x1 callsigns in
> the United States.

2x1 in the US aren't only for special events, see KA9Q etc. But I
haven't seen other countries issuing 2x1 or 1xN (e.g. N9KBK) in the
past. That seems to have changed recently.

> Jordon also issued 1x1 calls too.

Do you mean JY1 etc.? Using this terminology that would be a 2x0 ;-)

These special calls are becoming quite common in many countries now,
also here in Germany, from 2x1s for contest/clubstations (e.g. DR6A)
to the short-time stations during the soccer World Cup with calls like
DR2006N and DQ2006J (which would be "2x1" as well).

Perhaps somebody could check which syntax is valid now? I don't know
where to look. Was there any statement made on how calls longer than
6 chars are to be used on packet? Perhaps just use a different ID 
(which one?) and additionally set a beacon with the correct call in the
data part? How do other modes (was it AMTOR?) handle this?

73, Robert
DL1NC/N9KBK


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: callsign limit

[Bob Nielsen]

On May 31, 2006, at 6:15 AM, Robert Steinhäußer wrote:

> Hi!
>
> We're no longer on a linux subject (linux-hams), but I suppose enough
> here are interested.
>
> On Wed, May 31, 2006 at 12:12:03PM +0000, IT3 Stuart Blake Tener  
> wrote:
>> Though only Canada has started issuing 2x4's as far as I know.
>>
>> While special event stations (even for Packet) are able to get 2x1  
>> callsigns in
>> the United States.
>
> 2x1 in the US aren't only for special events, see KA9Q etc. But I
> haven't seen other countries issuing 2x1 or 1xN (e.g. N9KBK) in the
> past. That seems to have changed recently.

I think he meant 1X1 for special events.  Many countries have 1XN  
callsigns (G, F, I, W, etc.)

>> Jordon also issued 1x1 calls too.
>
> Do you mean JY1 etc.? Using this terminology that would be a 2x0 ;-)
>
> These special calls are becoming quite common in many countries now,
> also here in Germany, from 2x1s for contest/clubstations (e.g. DR6A)
> to the short-time stations during the soccer World Cup with calls like
> DR2006N and DQ2006J (which would be "2x1" as well).
>
> Perhaps somebody could check which syntax is valid now? I don't know
> where to look. Was there any statement made on how calls longer than
> 6 chars are to be used on packet? Perhaps just use a different ID
> (which one?) and additionally set a beacon with the correct call in  
> the
> data part? How do other modes (was it AMTOR?) handle this?

That is probably the best way (for now, at least).  Although I  
haven't encountered it, I suspect that is the way it is handled by  
stations operating from other than their home country (using  
designators such as DL/W1AAA).

There may be a need for a change to AX.25. TAPR (as custodian of the  
AX.25 specification) has a mailing list which is already discussing  
this issue:

  <https://lists.tapr.org/cgi-bin/mailman/listinfo/ax25-layer2>.

73,
Bob, N7XY


-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

callsign limit

[stephen]

Hello fellow sysop's 

I have a small problem with my Linux fbb bbs (FBB-7.04j) and four letter 
callsigns. Ie: vk3fdcs (vk?f??? are the new foundation call holders here in 
Australia)

When I enter in vk3fdcs at the bbs prompt I get this error: 

VK3HEG BBS>eu vk3fdcs 
*** Error : The callsign is missing. 

The windows remote linux program will let me add the vk3fdcs callsign, but 
when listing the users the ending 's' is cut off/missing. 

Is it posable to set call sign lengths in fbb or is this going to require a 
re-compile/editing of the source code?

Running redhat9 with updates, 2.4.31 kernel, ax25-apps 0.0.6, ax25-tools 
0.0.8, libax25-0.0.11.


-- 
Stephen - vk3heg

Re: callsign limit

[Hamish Moffatt]

On Wed, May 31, 2006 at 09:27:56AM +0000, stephen wrote:
> When I enter in vk3fdcs at the bbs prompt I get this error: 
> 
> VK3HEG BBS>eu vk3fdcs 
> *** Error : The callsign is missing. 
> 
> The windows remote linux program will let me add the vk3fdcs callsign, but 
> when listing the users the ending 's' is cut off/missing. 
> 
> Is it posable to set call sign lengths in fbb or is this going to require a 
> re-compile/editing of the source code?

Good question. AX.25 callsigns are at most 6 characters long, so you
won't be able to use those callsigns on the air.

Foundation licensees aren't allowed on packet btw.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: callsign limit

[Chuck Hast]

On 5/31/06, Hamish Moffatt <hamish@cloud.net.au> wrote:
> On Wed, May 31, 2006 at 09:27:56AM +0000, stephen wrote:
> > When I enter in vk3fdcs at the bbs prompt I get this error:
> >
> > VK3HEG BBS>eu vk3fdcs
> > *** Error : The callsign is missing.
> >
> > The windows remote linux program will let me add the vk3fdcs callsign, but
> > when listing the users the ending 's' is cut off/missing.
> >
> > Is it posable to set call sign lengths in fbb or is this going to require a
> > re-compile/editing of the source code?
>
> Good question. AX.25 callsigns are at most 6 characters long, so you
> won't be able to use those callsigns on the air.
>
> Foundation licensees aren't allowed on packet btw.
>
>
> Hamish

I believe (I maybe taking one in the wind but so far my digging around the
web would show this correct) that the ITU format for amateur calls is a max-
imum of 6 alpha-numerics, the first 1 - 2 chars are the national ID, 3rd is
usually a digit and the last 3 are the unique ID of the station, AX25 only
allows for a 6 char call. So you are going to have a problem there.

This of course does not set a minimum size as long as the national info is
displayed, so in this country (USA a K4A is possible, I believe in AUS,
you can have say a VK2A) calls as short as 2X1 are possible.



-- 
Chuck Hast  -- KP4DJT --
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: callsign limit

[Hamish Moffatt]

On Wed, May 31, 2006 at 07:03:50AM -0400, Chuck Hast wrote:
> On 5/31/06, Hamish Moffatt <hamish@cloud.net.au> wrote:
> >Good question. AX.25 callsigns are at most 6 characters long, so you
> >won't be able to use those callsigns on the air.
> 
> I believe (I maybe taking one in the wind but so far my digging around the
> web would show this correct) that the ITU format for amateur calls is a max-
> imum of 6 alpha-numerics, 

I think that's no longer true as of WRC 2003. It's a bit late to change
AX.25 though!

> This of course does not set a minimum size as long as the national info is
> displayed, so in this country (USA a K4A is possible, I believe in AUS,
> you can have say a VK2A) calls as short as 2X1 are possible.

Actually 2X1 calls aren't issued. Only 2X2, 2X3 and now 2X4.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: callsign limit

[Ralf Baechle DL5RB]

On Wed, May 31, 2006 at 09:19:19PM +1000, Hamish Moffatt wrote:

> > I believe (I maybe taking one in the wind but so far my digging around the
> > web would show this correct) that the ITU format for amateur calls is a max-
> > imum of 6 alpha-numerics, 
> 
> I think that's no longer true as of WRC 2003. It's a bit late to change
> AX.25 though!

Indeed.  And the problem isn't even new.  The ITU has always assigned
callsigns blocks with three characters (such as DAA-DRZ to Germany).  It
was just a courtesy to the ham community that only 1 and 2 character
prefixes were ever issued with Swaziland (3DA) as the only exception
I know of.

One of my crazier ideas to deal with the issue of the longer callsigns
was using a hash value instead.  The probability of colissions is low but
how to do the reverse mapping from hash to callsign ...

  Ralf

Re: callsign limit

[David D. Hagood]

Ralf Baechle DL5RB wrote:
> One of my crazier ideas to deal with the issue of the longer callsigns
> was using a hash value instead.  The probability of colissions is low but
> how to do the reverse mapping from hash to callsign ...
> 
>   Ralf
>

Since a callsign is always from the set [A-Z0-9] (36 chars, 5.2 bits of 
data per character for a naive encoding) could you not simple encode the 
callsign of an otherwise too-long call as 6 bits per character packed 
into the octets, with a specific leading character to indicate 
compression (e.g. '?') - yielding about 8 chars/call.

Re: callsign limit

[Ralf Baechle DL5RB]

On Thu, Jun 01, 2006 at 07:04:02AM -0500, David D. Hagood wrote:

> Ralf Baechle DL5RB wrote:
> >One of my crazier ideas to deal with the issue of the longer callsigns
> >was using a hash value instead.  The probability of colissions is low but
> >how to do the reverse mapping from hash to callsign ...
> 
> Since a callsign is always from the set [A-Z0-9] (36 chars, 5.2 bits of 
> data per character for a naive encoding) could you not simple encode the 
> callsign of an otherwise too-long call as 6 bits per character packed 
> into the octets, with a specific leading character to indicate 
> compression (e.g. '?') - yielding about 8 chars/call.

That is a modest proposal which gives you a little bit of extra headroom.
But the WRC03 rules set no limit for callsigns length.  And, let's face it,
the current format of AX.25 MAC addresses sucks anyway, 7 bytes with
various other junk thrown in just because space was available make
processing more complicated than needed.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: callsign limit

[Curt, WE7U]

On Thu, 1 Jun 2006, David D. Hagood wrote:

> Since a callsign is always from the set [A-Z0-9] (36 chars, 5.2 bits of
> data per character for a naive encoding) could you not simple encode the
> callsign of an otherwise too-long call as 6 bits per character packed
> into the octets, with a specific leading character to indicate
> compression (e.g. '?') - yielding about 8 chars/call.

Are we still talking about AX.25 here?  This is from the AX.25
version 2.0 spec, published in 1984:

"The characters of the call sign should be standard seven-bit ASCII
(upper case only) placed in the leftmost seven bits of the octet to
make room for the address extension bit. If the call sign contains
fewer than six characters, it should be padded with ASCII spaces
between the last call sign character and the SSID octet."

So...  We only have 7 bits to play with, not 8.  I suspect that we
could still play some games though and compress the callsign into
the 42 bits available, plus up to 4 more bits for the SSID if we
wanted to mess with that.  Many people like to have more than one
station on the same frequency though (as I do with APRS), so messing
with the SSID too much would be problematic.  Perhaps one bit could
be borrowed from there leaving 8 possible SSID's per station instead
of 16?

There are also two reserved bits in the SSID byte.  I didn't check
the later version 2.2 spec (which isn't implemented anywhere as far
as I know) to see if they decided to use those two bits.  There may
be some other reserved bits further down the header to use as well.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

Re: callsign limit

[Ralf Baechle DL5RB]

On Thu, Jun 01, 2006 at 07:31:54AM -0700, Curt, WE7U wrote:

> Are we still talking about AX.25 here?  This is from the AX.25
> version 2.0 spec, published in 1984:

May it rest in peace.  V2.2 dated 1997 is the latest.

> "The characters of the call sign should be standard seven-bit ASCII
> (upper case only) placed in the leftmost seven bits of the octet to
> make room for the address extension bit. If the call sign contains
> fewer than six characters, it should be padded with ASCII spaces
> between the last call sign character and the SSID octet."
> 
> So...  We only have 7 bits to play with, not 8.  I suspect that we
> could still play some games though and compress the callsign into
> the 42 bits available, plus up to 4 more bits for the SSID if we
> wanted to mess with that.  Many people like to have more than one
> station on the same frequency though (as I do with APRS), so messing
> with the SSID too much would be problematic.  Perhaps one bit could
> be borrowed from there leaving 8 possible SSID's per station instead
> of 16?
> 
> There are also two reserved bits in the SSID byte.  I didn't check
> the later version 2.2 spec (which isn't implemented anywhere as far
> as I know) to see if they decided to use those two bits.  There may
> be some other reserved bits further down the header to use as well.

DAMA packs some information into the the unused bits of the SSID field.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: callsign limit

[Curt, WE7U]

On Thu, 1 Jun 2006, Ralf Baechle DL5RB wrote:

> On Thu, Jun 01, 2006 at 07:31:54AM -0700, Curt, WE7U wrote:
>
> > Are we still talking about AX.25 here?  This is from the AX.25
> > version 2.0 spec, published in 1984:
>
> May it rest in peace.  V2.2 dated 1997 is the latest.

Last I heard 2.2 is not used anywhere.

As far as I know around here, everyone still codes to the 1984 spec.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

Re: callsign limit

[Ralf Baechle DL5RB]

On Thu, Jun 01, 2006 at 08:15:35AM -0700, Curt, WE7U wrote:

> > > Are we still talking about AX.25 here?  This is from the AX.25
> > > version 2.0 spec, published in 1984:
> >
> > May it rest in peace.  V2.2 dated 1997 is the latest.
> 
> Last I heard 2.2 is not used anywhere.
> 
> As far as I know around here, everyone still codes to the 1984 spec.

Yes and no.  I don't think anything tries to follow the new spec to the
letter but quite a few of it's elements have made it into actual
implementations.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: callsign limit

[Thomas Sailer]

On Thu, 2006-06-01 at 19:52 +0100, Ralf Baechle DL5RB wrote:

> Yes and no.  I don't think anything tries to follow the new spec to the
> letter but quite a few of it's elements have made it into actual
> implementations.

Or the other way round. Quite a few implementation practices have made
it into the 2.2 spec, without making sure the 2.2 spec is actually
self-consistent.

73 Tom

Re: callsign limit

[Kevin Dawson]

On various dates at various times, various people wrote: :-=)

> Date: 	Wed, 31 May 2006 16:02:03 +0300
> From: Matti Aarnio <matti.aarnio@zmailer.org>
> 
> I have at times considered of what would be decent new way to do things
> so that these big callsigns are also supported, and worst (or all) AX.25
> shortcomings are fixed at the same time.
> 
> [ IPv6 ]
> 
> Of course it is completely incompatible with existing AX.25 ...

As will be any change to the address field.  There is no immediate need
for a 7-character callsign on packet (even here in VK, although I
predict it will only be a few years); there is some time to work on it.

IPv6 isn't as omnipresent as one would hope - look at the mail headers
in this message.  All the addresses are likely IPv4.  That's not say
the various stages along the way don't use IPv6, of course, but the
world has been waiting a long time for the omnipresence to happen.

> Unfortunately we have _huge_ deployed base of inferior technology...

Definitely.  That will be the largest stumbling block to anything new.

In the meantime, there was an idea that jumped at me, which will solve
the callsign length problems.  I'll make some comments on other posts
along the way.

> From: Bob Nielsen <nielsen@oz.net>
> Date: 	Wed, 31 May 2006 07:57:25 -0700
> 
> On May 31, 2006, at 6:15 AM, Robert Steinhäußer wrote:
> 
> > Perhaps somebody could check which syntax is valid now? I don't know
> > where to look. Was there any statement made on how calls longer than
> > 6 chars are to be used on packet? Perhaps just use a different ID
> > (which one?) and additionally set a beacon with the correct call in  
> > the data part? How do other modes (was it AMTOR?) handle this?

AMTOR used 4 letters, which IIRC were just the first 4 letters of
the callsign (no digits).  Although it's not unique, it seemed to
work enough to be usable.

> That is probably the best way (for now, at least).  Although I  
> haven't encountered it, I suspect that is the way it is handled by  
> stations operating from other than their home country (using  
> designators such as DL/W1AAA).

One of the regulations (at least in VK) is that *every* packet must
contain the full callsign of stations involved, so a shortened version
won't be enjoyed by the authorities.  Visitors to VK only have VK
callsigns (on application), so VK/xxxxx doesn't happen.

> There may be a need for a change to AX.25. TAPR (as custodian of the  
> AX.25 specification) has a mailing list which is already discussing  
> this issue:
> 
>   <https://lists.tapr.org/cgi-bin/mailman/listinfo/ax25-layer2>.

I've just joined that list, being where this should really be discussed,
so if this spills over to there, that's OK.

> Date: 	Thu, 1 Jun 2006 14:25:00 +0100
> From: Ralf Baechle DL5RB <ralf@linux-mips.org>
> 
> But the WRC03 rules set no limit for callsigns length.  And, let's face it,
> the current format of AX.25 MAC addresses sucks anyway, 7 bytes with
> various other junk thrown in just because space was available make
> processing more complicated than needed.

I agree, although I don't know all the little quirks that had to be
accommodated in reaching the specification.  But then, I started in
packet using Vancouver's V2 and V3 protocols...

In these days of computing power, it makes sense to keep separate
fields in different octets.  The problems will come when you try
to please everyone.

> Date: 	Thu, 1 Jun 2006 16:08:54 +0100
> From: Ralf Baechle DL5RB <ralf@linux-mips.org>
> 
> On Thu, Jun 01, 2006 at 07:31:54AM -0700, Curt, WE7U wrote:
> 
> > "The characters of the call sign should be standard seven-bit ASCII
> > (upper case only) placed in the leftmost seven bits of the octet to
> > make room for the address extension bit. If the call sign contains
> > fewer than six characters, it should be padded with ASCII spaces
> > between the last call sign character and the SSID octet."
> > ...
> > There are also two reserved bits in the SSID byte.  I didn't check
> > the later version 2.2 spec (which isn't implemented anywhere as far
> > as I know) to see if they decided to use those two bits.  There may
> > be some other reserved bits further down the header to use as well.
> 
> DAMA packs some information into the the unused bits of the SSID field.

The spec still has them as reserved in 2.2, plus:
| c) The bits marked ?R? are reserved bits. They may be used in an
| agreed-upon manner in individual networks. When not implemented,
| they are set to one.

DAMA's use of them doesn't prevent other implementations.  Yes,
there will be pain when networks interoperate.

So Curt seeded my thoughts.  At present, the address extension bit is
used to indicate the end of the entire address field.  I propose that
this be modified to indicate the end of an individual callsign, then
use one of the reserved bits in the SSID octet (say bit 5) to indicate
the end of the address field as the present address extension bit does.
That simply changes the definition of what address is being extended,
rather than completely rewriting the format of the field.  The padding
of shorter callsigns with spaces is then unnecessary, although there
may be a weak case for compatibility with the current format to retain
it.  I'd rather not.  The SSID and control bits should perhaps be put
into separate octets, although this is getting further away from the
minimalist approach I'm giving.  You may as well just write a new
format (and I'm in support of that).

So, using the example of Figure 3.8 in the spec (single repeater hop),
the address field octets, still with space padding, would be:
98 94 6E A0 40 40 C1   98 6E 98 8A 9A 40 41   98 6E 9E 9E 40 40 E3
To not have space padding, the '40' octets are removed.

Secondly, I'd suggest allowing the '/' character to be allowed for the
case of DL/xxxxx.  Perhaps just allow the entire 7-bit ASCII set.  The
next hurdle will then be internationalisation in callsigns, which (in
the extreme case) could be handled as in email.  But I digress.

Advantages I see:
- no more length restrictions
- allowance for the XX/yyyyy format of callsign
- allowance for other future addressing methods.  If I wanted to send a
  signal from Germany, showing a separate receive frequency for this
  particular link, my address might look like DL/VK2KD-2:RX=433.750
- it's conceptually simple for programmers to implement the present
  callsign conventions in this scheme
- it keeps the authorities happy

Disadvantages:
- Of course, most things now will break.  Difficult to avoid unless one
  of the control bits is used to indicate an extended addressing scheme
  which would sit in the I field under the current protocol.
- more intelligence and finer control required, but this should be easy.
- it discourages proper work in bringing the format up to date.  As I
  understand it, Phil Karn is not entirely happy that KISS is *still*
  being used...

There is no doubt more to think about, so I'll happily listen!

Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: callsign limit

[Hamish Moffatt]

On Fri, Jun 02, 2006 at 12:51:17PM +1000, Kevin Dawson wrote:
> won't be enjoyed by the authorities.  Visitors to VK only have VK
> callsigns (on application), so VK/xxxxx doesn't happen.

Though that is meant to be fixed at some point too (ie automatic
reciprocal licensing).


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: callsign limit

[Geoff Blake]

On Wed, 31 May 2006, Chuck Hast wrote:

> On 5/31/06, Hamish Moffatt <hamish@cloud.net.au> wrote:
> > On Wed, May 31, 2006 at 09:27:56AM +0000, stephen wrote:
> > > When I enter in vk3fdcs at the bbs prompt I get this error:
> > >
> > > VK3HEG BBS>eu vk3fdcs
> > > *** Error : The callsign is missing.
> > >
> > > The windows remote linux program will let me add the vk3fdcs callsign, but
> > > when listing the users the ending 's' is cut off/missing.
> > >
> > > Is it posable to set call sign lengths in fbb or is this going to require a
> > > re-compile/editing of the source code?
> >
> > Good question. AX.25 callsigns are at most 6 characters long, so you
> > won't be able to use those callsigns on the air.
> >
> > Foundation licensees aren't allowed on packet btw.
> >
> >
> > Hamish
>
> I believe (I maybe taking one in the wind but so far my digging around the
> web would show this correct) that the ITU format for amateur calls is a max-
> imum of 6 alpha-numerics, the first 1 - 2 chars are the national ID, 3rd is
> usually a digit and the last 3 are the unique ID of the station, AX25 only
> allows for a 6 char call. So you are going to have a problem there.
>
> This of course does not set a minimum size as long as the national info is
> displayed, so in this country (USA a K4A is possible, I believe in AUS,
> you can have say a VK2A) calls as short as 2X1 are possible.

ISTR that as part of WARC2003, a change in the suffix part of a call sign
to permit 4 digits was promulgated.

i.e. VK2ABCD would be legitimate.

Geoff

-- 
    Geoff Blake G8GNZ      located near Chelmsford, Essex, U.K.
    Please reply to:       geoff (at) palaemon (dot) co (dot) uk
    Using Linux on Intel & Linux or NetBSD on Sun Sparc platforms

------------------------------------------------------------------------------

    This  E-mail  and any  attachment(s) are strictly  confidential
    and is intended solely for the addressee(s). If you are not the
    intended recipient please notify <postmaster(at)palaemon.co.uk>
    and the sender by return and permanently delete the message.

    You may not disclose, forward or copy this E-mail or any of its
    attachments to any third party without the prior consent of the
    sender.

------------------------------------------------------------------------------

Re: callsign limit

[stephen]

On Wed, 31 May 2006 09:37 am, Hamish Moffatt wrote:

> > When I enter in vk3fdcs at the bbs prompt I get this error:
> >
> > VK3HEG BBS>eu vk3fdcs
> > *** Error : The callsign is missing.
> >
> > The windows remote linux program will let me add the vk3fdcs callsign,
> > but when listing the users the ending 's' is cut off/missing.
> >
> > Is it posable to set call sign lengths in fbb or is this going to require
> > a re-compile/editing of the source code?
>
> Good question. AX.25 callsigns are at most 6 characters long, so you
> won't be able to use those callsigns on the air.

That does in deed seam to be a limiting factor, and is going to be a pain to 
fix (ie: There's a lot of old gear around)

> Foundation licensees aren't allowed on packet btw.

Thanks Hamish, wasn't sure on that bit.'


-- 
Stephen - vk3heg
Ph: 0409149641

Re: callsign limit

[Chuck Hast]

On 6/1/06, stephen <vk3heg@iinet.net.au> wrote:
> On Wed, 31 May 2006 09:37 am, Hamish Moffatt wrote:
>
> > > When I enter in vk3fdcs at the bbs prompt I get this error:
> > >
> > > VK3HEG BBS>eu vk3fdcs
> > > *** Error : The callsign is missing.
> > >
> > > The windows remote linux program will let me add the vk3fdcs callsign,
> > > but when listing the users the ending 's' is cut off/missing.
> > >
> > > Is it posable to set call sign lengths in fbb or is this going to require
> > > a re-compile/editing of the source code?
> >
> > Good question. AX.25 callsigns are at most 6 characters long, so you
> > won't be able to use those callsigns on the air.
>
> That does in deed seam to be a limiting factor, and is going to be a pain to
> fix (ie: There's a lot of old gear around)
>
> > Foundation licensees aren't allowed on packet btw.
>
> Thanks Hamish, wasn't sure on that bit.'
>

I assume that these licenses are some sort of celebratory license?
Foundation sounds like a SciFi book series that Issac Asimov
wrote. (Don't laugh they are a classic)


-- 
Chuck Hast  -- KP4DJT --
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: callsign limit

[Hamish Moffatt]

On Thu, Jun 01, 2006 at 06:54:33AM -0400, Chuck Hast wrote:
> I assume that these licenses are some sort of celebratory license?

Not at all. It's a new introductory license. The concept was pioneered
in the UK a few years ago and recently introduced in Australia.

Licensees do a weekend course followed by a written exam and practical
assessment. In return they get access to 80/40/15/10m SSB with 10W
limit plus 2m/70cm FM, commercial gear only (no homebrew).
It's been very popular.

Foundation licenses all have calls of the form VKnFxxx.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: callsign limit

[Geoff Blake]

On Thu, 1 Jun 2006, Hamish Moffatt wrote:

> On Thu, Jun 01, 2006 at 06:54:33AM -0400, Chuck Hast wrote:
> > I assume that these licenses are some sort of celebratory license?
>
> Not at all. It's a new introductory license. The concept was pioneered
> in the UK a few years ago and recently introduced in Australia.
>
> Licensees do a weekend course followed by a written exam and practical
> assessment. In return they get access to 80/40/15/10m SSB with 10W
> limit plus 2m/70cm FM, commercial gear only (no homebrew).
> It's been very popular.
>
> Foundation licenses all have calls of the form VKnFxxx.

In England Foundation calls take the form of either M3xxx, or in the rest
of the UK: My3xxx, where 'xxx' is the the unique part and 'y' is the
regional identifier, like I for Norther Ireland, M for Scotland and W for
Wales etc.

The Foundation Licence courses that I have been involved with have either
been a pretty high pressure weekend course or six Sunday mornings. It is a
concept I believe in and many, if not most of the Foundation Licencees
either have, or are seeking to, move up the licence hierachy.

Geoff
-- 
    Geoff Blake G8GNZ      located near Chelmsford, Essex, U.K.
    Please reply to:       geoff (at) palaemon (dot) co (dot) uk
    Using Linux on Intel & Linux or NetBSD on Sun Sparc platforms

------------------------------------------------------------------------------

    This  E-mail  and any  attachment(s) are strictly  confidential
    and is intended solely for the addressee(s). If you are not the
    intended recipient please notify <postmaster(at)palaemon.co.uk>
    and the sender by return and permanently delete the message.

    You may not disclose, forward or copy this E-mail or any of its
    attachments to any third party without the prior consent of the
    sender.

------------------------------------------------------------------------------

Re: callsign limit

[Matti Aarnio]

On Wed, May 31, 2006 at 09:27:56AM +0000, stephen wrote:
> Hello fellow sysop's 
> 
> I have a small problem with my Linux fbb bbs (FBB-7.04j) and four letter 
> callsigns. Ie: vk3fdcs (vk?f??? are the new foundation call holders here in 
> Australia)
> 
> When I enter in vk3fdcs at the bbs prompt I get this error: 
> 
> VK3HEG BBS>eu vk3fdcs 
> *** Error : The callsign is missing. 
> 
> The windows remote linux program will let me add the vk3fdcs callsign, but 
> when listing the users the ending 's' is cut off/missing. 
> 
> Is it posable to set call sign lengths in fbb or is this going to require a 
> re-compile/editing of the source code?

This needs radical rework of AX.25 protocol - it supports only 6 characters
in callsign.

Consider also callsigns:

   DR2006N
   DQ2006B

there are a bunch of similar callsigns in Germany.  I know couple "long"
ones in Finland as well.

 

I have at times considered of what would be decent new way to do things
so that these big callsigns are also supported, and worst (or all) AX.25
shortcomings are fixed at the same time.

Surprisingly(?) I did end up revising link-level protocol entirely and
using IPv6 IP frames for "mac" level on radio link with callsign being
encoded in IPv6 address' lower 64 bits as 6-bit character code...
Something like:

  1 byte of local address type tag
  6 bytes of 6-bit encoded compacted callsign
  1 byte extra (SSID + extra ?)

For the CONS and CLNS services I would use TCPv6 and UDPv6.
(And suddenly you need no new protocol stack in your machine - besides
of IPv6 stack, which is very soon omnipresent.)

Of course it is completely incompatible with existing AX.25 ...
I have also considered throwing away existing 1200 bps AFSK radio system
and replacing it with something smarter - like PI/4-DQPSK modulated FECed
(Reed-Solomon/Turbocode/LDPC/something) and interleaved thingamajing.

Unfortunately we have _huge_ deployed base of inferior technology...
(That PI/4-DQPSK does not work with your average 'completely in compression'
FM radio transmitter/limittered receiver, but with slight 2 dB backoff
things do improve a lot..)

> Running redhat9 with updates, 2.4.31 kernel, ax25-apps 0.0.6, ax25-tools 
> 0.0.8, libax25-0.0.11.
> -- 
> Stephen - vk3heg

  /Matti Aarnio - OH2MQK

Re: callsign limit

[Thomas Sailer]

On Wed, 2006-05-31 at 16:02 +0300, Matti Aarnio wrote:

> FM radio transmitter/limittered receiver, but with slight 2 dB backoff
> things do improve a lot..)

2dB backoff is kinda hard to achieve with an ALC in the signal path. And
it doesn't help when transceivers "forget" to disconnect the internal
microphone when you connect an external modulation signal.

I still think it would be good to have some form of MAC layer ARQ
capability...

73s,
Tom

Re: callsign limit

[Matti Aarnio]

Hello Thomas,

On Wed, May 31, 2006 at 03:12:50PM +0200, Thomas Sailer wrote:
> On Wed, 2006-05-31 at 16:02 +0300, Matti Aarnio wrote:
> 
> > FM radio transmitter/limittered receiver, but with slight 2 dB backoff
> > things do improve a lot..)
> 
> 2dB backoff is kinda hard to achieve with an ALC in the signal path. And
> it doesn't help when transceivers "forget" to disconnect the internal
> microphone when you connect an external modulation signal.

Of course I would not use normal built-in modulator at all.
One can perhaps use some components out of surplus NBFM radios,
but not original modulator, nor (of course) FM demodulator.

I spotted recently also TI's  CC1100 (et.al.) chips.
Nice sets of features for a data radio in a very cheap package - but
it does not look very sensitive in itself... (about 15 dB of "deafness"
in our (oh2mqk, oh3bk, oh3nwq, oh2bns) opinnion about it..)

On the other hand - adding narrowband low-noise preamp for Rx, and
some real PA for Tx should make it  quite interesting thing all in
its own right.

> I still think it would be good to have some form of MAC layer ARQ
> capability...

The ARQ makes sense when your transmission is very slow.
(E.g. HF AMTOR).   TCP retry timers are somewhat ARQ incompatible...

Having a 9600 bps TCP running at 99% packet transmit reliability 
gives you so good a result, that you don't want extra ARQ there
to spoil things.

Now ALE (Automatic Link Establishment), and ways to self-organize
the network, those would be neat....


> 73s,
> Tom

73 de Matti, OH2MQK

PS: "73s" is plural of plural