Hi Walter.
>> Please advise how one would put the callsign GB50BOB into a
>> packet radio transceiver then?
> I do not like to cite my cites but:
>>>> just using DL1NC and (just in case) sending a beacon every 10
>>>> minutes containing my complete callsign and QTH. If anybody
>>>> wants to know more, they can connect me and ask.
> Just put GB50BO in the callsign field...
Thereby contravening the regulations in just about EVERY country I've
ever operated in! Certainly, doing that is against the British
regulations, the US regulations, the Canadian regulations, the French
regulations...should I keep going?
> ...and set up a beacon explaining "GB50BO = GB50BOB".
> But those celebration-callsigns are IMHO rare and therefore a
> minor "problem" :-)
You obviously make little use of amateur radio then.
> The field, in which the callsign is usually placed, is an
> address field, needed to identify the sender, repeater and
> receiver uniquely. This could also contain any other worldwide
> unique ID like your birthday combined with your locator. The
> identifier is needed for protocol purposes and not to identify
> the sender of the RF.
I don't know the German regulations - it's one of the few countries
in Europe that I've never operated in - but I would be VERY surprised
to discover that your suggestion complied with them.
> But we all have an unique callsign, so the callsign is a good choice
> for those fields.
In most countries, the callsign is a REQUIREMENT of the amateur radio
regulations, and your proposal to use anything else is therefore
illegal.
> But this does not mean, that it is required to put any extension
> (e.g. DC/ /mm /p /m /am /A) also into these fields.
Since I was the one who first pointed that out, I see no reason to
disagree with you. The requirement to comply with the regulations is
that the FULL BASE CALLSIGN be inserted in the address field.
> Of course, your national PTT could have requested to put the
> whole callsign including extension in the ax25.protocol. But if
> this would be true, they could never have allowed ax.25...
>>> AX25: DC/->DB0IZ-11 v /W0RLI*, /MM, DB0IZ-9 <C C P>
>> Since the proposed solution just doesn't work...
> it does :)
If one follows your proposal of ignoring one's licence...
>> but the problem definitely isn't nonsense, as was quite
>> evident prior to your missive !!!
> s/nonsense/irrelevant to me/g
{Shrug} Since you're clearly using illegal practices...
> BTW: non fixed address length in a protocol-field aren't funny,
> even in software.
It is fine if it's implemented correctly in the PROTOCOL. The problem
with AX.25 is that the protocol was flawed in that respect to start
with, and all implementations were handicapped by that flaw.
> Even the 0 to 8 digipeater address fields are annoying.
Personally, I agree with the various experts who claim that whilst
digipeaters served a purpose when packet was in its infancy, they are
no longer needed and should be deleted from the protocol.
> If this would be combined with length-infix callsign fields...
Nope, the digipeater facility would be stripped out in the proceess of
revising the protocol.
> And this only for GB50BOB?
Since you clearly don't use the amateur radio bands, you equally
clearly won't be aware of just how many callsigns are in regular use
that can not be used in the AX.25 protocol due to this stupid flaw in
the protocol.
Add to that the fact that several countries have already proposed
allocating ham callsigns with a four letter suffix since they are fast
running out of callsigns to allocate, and you soon see just how daft
your comments are...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
