OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
OE7FMI > OEVSV    15.07.10 21:27l 94 Lines 3720 Bytes #999 (0) @ OE
BID : 57KOE2XEL03F
Read: GUEST OE5RCO OE6OWG DB1YAK OE1VGC DG1NDE OE7FMI
Subj: Re:(3): Entspricht D-Star dem AFG?
Path: DB0FHN<DB0RGB<DB0PM<OE2XEL
Sent: 100705/1420z @:OE2XEL.#OE2.AUT.EU [Salzburg Gaisberg JN67NT] obcm1.06
From: OE7FMI @ OE2XEL.#OE2.AUT.EU (Markus)
To:   OEVSV @ OE
Reply-To: OE7FMI @ OE7XLR.#OE7.AUT.EU
X-Info: No login password

Hallo die Mitleser 

Ich kenne keinen Punkt, wo D-Star nicht konform waere.
Die Definition zu den Sendearten wurde ja weitestgehend
gelockert. (Alle techn. moeglichen Sendearten....) 

HF-technische Parameter verletzt D-Star auch nicht.

Die AFV sagt jedenfalls noch unter Pkz. Rufzeichen:
====
(5) Werden digitale Sendearten verwendet, ist das Rufzeichen im 
Adressfeld "entsprechend dem jeweiligen Übertragungsprotokoll" 
auszusenden ,,,
====

Bei D-Star wird das Call im Protokoll als Dateninhalt 
mit übertragen, und kann auf dem Display der Geräte abgelesen 
werden. ALso auch erfuellt.

Ansonsten:
Wikibloed/gscheit vermeldet am Beispiel DL:

====
Nach Auskunft der in Deutschland für den Amateurfunkdienst 
zuständigen Behoerde, der Bundesnetzagentur, vom 30. April 2008
gibt es keine rechtlichen Einwaende gegen den Einsatz des 
DV-Modus in Deutschland trotz der proprietären Natur des 
Codecs. Das AMBE+ Verfahren produziert einen Datenstrom, 
dessen Inhalt nicht ohne Rueckgriff auf proprietaere Verfahren 
ausgewertet werden kann. Die der Behoerde vorliegende 
Dokumentation ist hierfür ausreichend. 
Insofern ist die bisherige Diskussion, dass dieser Teil des 
Datenstroms als verschluesselt anzusehen sei, aus Sicht der 
Behörde widerlegt. Verschluesselte Uebertragungsverfahren 
sind im internationalen Funkverkehr gemäß der 
Vollzugsordnung für den Funkdienst (Art. 25.2A) 
und in Deutschland gemäß der Amateurfunkverordnung 
(§ 16 [7,8]) untersagt.
=====

Verschluesselung:
Eine Verschluesselung liegt meines Erachtens dort vor, wo ein 
(geheimer) Schluessel oder Codec angewendet wird, JEDOCH NICHT
wenn ein Datenprotokoll oder ein Fileformat mit bekannter 
Syntax / Semantik verwendet wird. 
(Die Verbreitung spielt ggf. auch eine Rolle)

Das betrifft auch Uebertragungen mit ganzen Protokollstapeln 
draufgepackt,sowie Fileformate. 
Beispiel: 
Auslesen eines gewoehnlichen JPEG-Bildes ueber AX25 aus einer 
PR-Mailbox heraus, und selbst wenn dies sogar noch 7plus 
(wers noch kennt) komprimiert waere.

Die technischen Hilfsmittel, um ein JPEG oder D-ATV DVB-S Bild/Ton 
anzuschauen sind jedenfalls nicht proprietaer.
Den SAT-Receiver gibt es zu kaufen, PC hat auch jeder.

Denn was waere mit PSK, RTTY, und Betriebsarten,etc.. ?
Die Hilfsmittel gibts als Free Download, man kann also 
"offen" dazu sagen.  
 
Wo sich da aber D-Star einreiht kann ich nicht sagen. 
Wenn die Behoerde D-STAR Geraete (unter Mitenbeziehung ihrer
Verbreitung) oder ein proprietaeres Hilfsmittel als ausreichend 
ansieht, um das Verfahren als "nicht Verschluesselt" einzuordnen, 
und zudem auch ihrem eigenen Auftrag nachkommen kann,
dann soll es so sein.

Verschluesselt ist nur fuer den etwas, der die geeignete
Empfangsvorrichtung zur Darstellung des Inhalts nicht hat. 
Ob PSK, D-STAR digitales ATV-egal oder Wurschtlfunk - egal.
Was also noch als offener Standard gilt, unterliegt auch 
individuellen Befindlichkeiten, auch bei (rechtlicher) Betrachtung.
Und wie bereits angemerkt spielt der Verbreitungsgrad der 
"Hilfsmittel zur Darstellung des Inhalts" eine Rolle. 
(Stichwort: wachsende Zahl an Digimodes fuer Kurzwelle,zb neu: ROS)
So schwarz/weiss wie frueher kann man das ggf. mit den
heute zur Verfuegung stehenden Moeglichkeiten nicht mehr sehen. 

Wie auch immer habe ich keinen Bedarf an einen D-STAR-Umsetzer. 
Das resultiert aus meinen persoenlichen Befundungen zu bestimmten 
technischen und organisatorischen Randbedingungen von D-STAR, 
sowie dem "Handling der Technologie". 
Auch das Kapitel "Internet Trust Server in den USA" geben Anlass
zur Kritik. 
 
73 de OE7FMI

Markus


Read previous mail | Read next mail


 21.04.2025 12:00:25lGo back Go up