Pages: 1 ... 4 5 [6] 
|
 |
|
|
Author
|
Topic: CAT Funktion eingebaut (Read 11761 times)
|
|
DB4PLE
positron
Urgestein
 Offline
Posts: 1278
|
 |
Re:CAT Funktion eingebaut
« Reply #75 on: 11. April 2016, 05:55:23 »
|
|
Hallo Ulrich,
dann hatten wir beide recht. Verursacht werden deine Probleme durch die zwischenzeitliche Nutzung der Schnittstelle durch ein anderes Program.
Der Kernel versucht jedenfalls nicht selbständig AT Befehle abzusetzen.
Und eine Lösung für dieses Problem ist der Timeout.
Sehr gut.
Dennoch sollte das Programm identifiziert werden und in unsere Watchlist im Wiki kommen.
73
Danilo
|
|
 Logged
|
|
|
|
|
|
DL3AAA
OM_nicht_I40
noch länger dabei
Offline
Posts: 132
Immer daran denken neugierig zu bleiben
|
|
Re:CAT Funktion eingebaut
« Reply #77 on: 11. April 2016, 07:18:54 »
|
|
Moinsen,
wenn ich lese das vorab schon AT-Befehle gesendet werden gehe ich zu 99,9 % davon aus das es die Braillezeile ist. Diese hat mich etwas länger beschäftigt, musste erst erkennen wer der Übeltäter war. Ich habe den Treiber gelöscht und die Sonne ging auf.
73 Dietrich
|
|
Logged
|
73 Dietrich
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #78 on: 11. April 2016, 12:36:58 »
|
|
Gute Idee!
Wie konnte es dazu kommen, dass ich bei beiden Systemen diesen Ärger hatte? Nun, Canonical setzt sehr auf Integration von Menschen mit eingeschränkten Fähigkeiten und da ich Ubuntu auf dem PC und MATE auf dem RasPi verwendet habe, ist auf beiden Systemen wahrscheinlich die Braille Zeile aktiv. Wenn ich über Noobs ein Raspbian installiert hätte... Das werde ich auf meinem anderen Raspi dann heute Abend mal testen...
Lösungen:
Letztendlich würde ich gerne meine Optimierungen komplettieren und damit generell das Entfernen von Treibern vor der Verwendung von CAT überflüssig machen. Ich denke es würde den Komfort unheimlich steigern, wenn die Schnittstelle am Anfang einströmenden Müll verarbeiten kann, statt einfach asynchron zu werden.
Problem:
1)
Das Protokoll ist binär und damit kann in einigen Befehlen durchaus die Byte-Folge AT enthalten sein.
2)
Durch die USB-Übertragung ist die von ICOM als Frame-Timing genutzte überschaubare serielle Übertragungsgeschwindigkeit nicht mehr vorhanden.
3)
Durch das Puffern und Frame-basierte Übertragen via USB können mehrere Telegramme gleichzeitig in einem Frame oder ein Telegramm verteilt über mehrere Frames übertragen werden.
Da die Hamlib per Default keine Zwangspausen eingestellt hat (Delays stehen alle auf 0ms) können via USB nicht nur beliebig viele Telegramme auf einmal kommen, die können auch über mehrere USB Frames verteilt werden. Und die 200ms Telegramm-Zeit, die ich jetzt eingestellt habe, werden von ICOM ja inkl. der Transportzeit einer Seriellen von 9600bps gerechnet. Auf dem USB sind die Daten ja ungleichmäßig viel schneller im Puffer.
Ich werde die Probleme zunächst mal wie folgt angehen:
1)
Direkt bei Aktivierung der USB Schnittstelle, baue ich ein Zeitfenster ein, in dem alle einströmenden Daten verworfen werden. Erst wenn eine definierte Lücke erkannt wurde, nach der ein 5-Byte Protokoll eingelaufen ist, wird dieses als korrekt angenommen.
2)
Ich prüfe die Pakete auf etwas mehr Validität. Da die Hamlib sich Mühe gibt, Pakete mit ungenutzten Datenfeldern, diese auch mit 0x00 zu senden, sollte das leicht fallen.
3)
Eventuell wären die OMs bereit in der Hamlib einen Delay einzustellen von vielleicht 5ms. Das würde im Hintergrund dafür sorgen, dass alle an der Übertragung beteiligten Systeme die Daten besser paketieren. Damit könnte die ganze Kette dann auch wirklich mit einem Timing basierten Protokoll funktionieren.
Ich teste da aber noch, will nur mal vorfühlen, wie die Resonanz da ist.
Wenn man eine Maus mit Schwungrad hat, also sehr schnell scrollen kann, dann kann man die Frequenz des mcHF noch komplett verwirren. Statt zügig von 21,100.000 nach 21,250.000 zu sausen, knackt es einmal kurz im Kopfhörer und man hat 30 oder 1050 Hz im Display.
Da überholen sich die Protokolle dann wohl gegenseitig.
Wenn man etwas Ruhe bei der Bedienung walten lässt, funktionieren fldigi, flrig, rigctl... Alles ohne Probleme und das auf Ubuntu 15.10 (PC) und Ubuntu MATE (RasPi)
vy 73!
Ulrich
|
| « Last Edit: 11. April 2016, 12:37:36 by Astralix » |
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:CAT Funktion eingebaut
« Reply #79 on: 11. April 2016, 19:18:15 »
|
|
Hallo Ulrich,
Wie man rausfindet, ob die Braillezeile aktiv ist, steht im Wiki. das wäre gut, wenn Du verifizierst, was jetzt der Verursacher ist. Und vorallem, wenn es nicht die Braillezeile ist, was ist es dann?
Das zeitweise Verwerfen von Daten nach dem Connect ohne Grund finde ich nicht gut. Das kann ungenannte Probleme für die Nutzer verursachen, die bisher keine Probleme hatten.
Data-Rate Limiting ist theoretisch sinnvoll, aber bisher hat es da keine ernsten Probleme gegeben. Nur für die Frequenzverstellung könnte das interressant sein, siehe auch Diskussion zum "dynamischen" Tuning, da wurden daran gearbeitet.
Könnte man nicht den USB Treiber dazu bringen, das er einfach meldet, er hat keine Lust auf Daten (NAK), wenn die Pakete zu schnell kommen. Das spart die hamlib Geschichte und wirkt "immer".
Die Validitätsprüfung bringen aus meiner Sicht nicht viel. Damit ist man doch auch nicht schlauer, wenn ein Versatz existiert. Es gibt auch nicht nur die Hamlib, das sollte beachtet werden. Und laut Protokoll sind die Daten halt "don't care" und müssen nicht 0 sein. Also sollte man das auch so halten.
Ehrlich gesagt, der Timeout ist irgendwie immernoch mein Favorit. Allerdings ist der echte Timeout wohl deutlich kürzer als 200ms. Kann diese Info leider nicht mehr finden, aber irgendwo habe ich das gelesen. Ausprobiert habe ich es nicht, aber ich habe einen FT-817, das kann ich schon rausfinden. Nur nicht die Tage.
73
Danilo
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #80 on: 11. April 2016, 21:49:34 »
|
|
Es ist nicht ganz einfach hier eine Idee zu diskutieren, ohne erst einmal viel "wenn..." und "aber..."
Wie Danilo zuletzt dann doch feststellt, ein Timeout basiertes Protokoll kann man zuletzt nur über Timeouts wieder in die Spur bekommen, wenn es diese verlassen hat.
Leider bietet USB nur garantiert Mindestgeschwindigkeiten, aber keine exakten Frames. Im Grunde kann man natürlich 5 Bytes vom PC auf die Reise schicken, aber die kommen halt erst mit dem nächsten Frame. Kann aber auch sein, dass ein Teil der Daten noch mit dem gerade gestarteten Frame raus gehen, die anderen erst mit dem nächsten.
Das Timeout ist ja nicht in Stein gemeißelt, auch wenn ka7oei schreibt:
"Note: It is specified in the manual that these 5 bytes are to be sent in quick succession - within 200 milliseconds of each other. Experimentation reveals, however, that this would be too slow - it is more likely that all 5 bytes must be sent within a 200 millisecond period."
Für unseren Fall kann man 50..100ms bei USB-Start abwarten, in denen zusammenhängende Datenblöcke als Schrott verworfen werden. Danach würde ich 3..5ms als definierte Trennung ansehen. Ich kann mir aber nicht vorstellen, dass das Hamlib CAT das nicht ohnehin schon so macht. Werde das im Code aber noch verifizieren. Im aktuellen Test bei mir verwende ich zwischen den Blöcken 5ms. Meine Microsoft Sculpt Maus hat eine Schwungrad-Funktion, damit kann ich den mcHF über die Frequenzeinstellung in fldigi zuverlässig wegschießen. Wenn ich das im Griff habe oder nachweisbar nicht das USB CAT daran schuld ist, checke ich ein.
Ich habe das Yaesu Protokoll nicht ausgesucht, ich versuche es nur unempfindlicher gegen noch vorhandene Störer bei der USB Anbindung zu machen. Ich möchte die Braille-Erkennung nicht raus werfen, da ich Sehbehinderten nicht den Zugang zum mcHF verbauen möchte.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF8OE
Administrator
Offline
Posts: 6265
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:CAT Funktion eingebaut
« Reply #81 on: 12. April 2016, 05:51:35 »
|
|
hallo Ulrich,
brauchst Du nicht. Es reicht eine neue udev-Regel und die Braillezeile fasst den mcHF nicht mehr an.
Hast Du schon mal versucht, mit deiner Schwungrad-Maus einen FT817 zu bedienen? Ich wette, Du schießt auch den weg  Insofern würde ich den Betrieb einer Schwungradmaus als VFO-Geber in den Bereich einer "Fehlbedienung" stecken
und mir darüber keine weiteren Gedanken machen  .
Und das mit den "wenns" und "abers" ist auch völlig richtig so! Wenn man bestehenden, funktionierenden Code hat und es soll etwas geändert werden, müssen vorher die Möglichkeiten einer Verbesserung bzw. Verschlechterung abgewogen werden.
Einige Dinge führen sonst zu einem Verzetteln bzw. zu "Verschlimmbesserungen".
Letztendlich hat die Tatsache, dass wir jetzt sowohl CAT als auch Audio GLEICHZEITIG über dieselbe USB-Verbindung senden können dazu geführt, dass die CAT-Schnittstelle nun nicht mehr als ttyUSBx auftaucht. Dann wähle ich aber ohne zu zögern die existierende Lösung...
Windows-User müssen für so gut wie jedes neue Gerät einen Treiber installieren - da ist es Linux-Usern mit Sicherheit zuzumuten, dass sie, wenn sie auf bestimmte Hintergrundprogramme nicht verzichten wollen, eine kleine udev-Regel zusammentippen...
Übrigens musste ich in den SI570-Code schon eine "Sicherung" einbauen. Durch das dynamische Tuning war es möglich, durch simples schnelles Drehen am VFO-Knopf den mcHF abzuschießen. Und zwar weil die Zeit, die der SI570 bei "großen Frequenzsprüngen" braucht um zu rasten, unterschritten wurde. Kommt in der Zeit, in der der SI570 abstimmen will aber noch nicht fertig ist ein neues I2C-Wort, hängt er sich in die Ecke, bis man die Betriebsspannung abnimmt. Selbst ein I2C-Reset-Befehl bewirkt *NICHTS*. Beim schnellen Drehen am VFO-Knopf werden einfach pro Sekunde maximal 5 Abstimmvorgänge durchgeführt und der Rest an hereinflutenden Daten einfach ignoriert. Selbst wenn Du es schaffst, das USB-Timing robuster zu machen - Du wirst nach wie vor nicht schneller abstimmen können. Die maximal im mcHF mögliche Abstimmgeschwindigkeit hat als physikalische Grenze den SI570.
vy 73
Andreas
|
| « Last Edit: 12. April 2016, 05:57:33 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #83 on: 12. April 2016, 11:44:27 »
|
|
Bei mir ist da das Paket aus den offiziellen Paketquellen installiert und das ist ..-4 und nicht ..-5
~$ dpkg -l | grep brl
ii brltty 5.2~20141018-4ubuntu4
rc libbrlapi0.5:amd64 4.4-8ubuntu4
ii libbrlapi0.6:amd64 5.2~20141018-4ubuntu4
ii python3-brlapi 5.2~20141018-4ubuntu4
ii xbrlapi 5.2~20141018-4ubuntu4
Letztendlich löst ein manuelles Update des brltty nicht das Problem, dass nur ein einziges Byte du viel oder zu wenig das CAT für immer aus der Bahn wirft.
Aber wenn Ihr so darauf besteht, dass ich diese Optimierungen in der Software nicht einbaue, dann lasse ich es eben.
git reset --hard HEAD
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #85 on: 13. April 2016, 14:16:32 »
|
|
Hallo Andreas,
allein schon, dass ich versuche die Rahmenparameter sorgfältig abzustecken, meinen eigenen Code erst prüfe und ihn auch nach Implementation und vor commit erst aufräume, soll ja zeigen, dass ich keine Schnellschüsse committen will.
Ich komme ja nicht nur mit Qualitätsansprüchen an die Funktionalität, sondern stelle diese auch an meine eigen Lösung, wenn ich Funktionalität hinzufüge oder verbessere. Es ging nie darum, dass ich jetzt sofort einen Commit von mir im Release haben will. Wer das so verstanden hat, sorry, das war nicht meine Absicht.
Ich möchte aus folgenden Fakten etwas machen, dass die Funktionalität von CAT sicherstellt:
- USB ist im Timing nahezu nicht beeinflussbar.
- USB garantiert nur zu 99%, dass ein Block Daten auch in einem Frame gesendet wird.
- YAESU CAT basiert auf Timeouts.
- YAESU CAT kalkuliert die Transport-Zeiten mit ein.
- Hamlib erkennt CAT Timeouts und wiederholt automatisch nach 200ms einen verlorenen Befehl.
- SI570 benötigt ebenfalls Timeouts.
- Schnelles Software CW soll nicht durch zu hohe Latenzzeiten verhindert werden.
- TX Delay bei digi muss klein bleiben.
- Aktuelle Implementation kann durch ein Byte zuviel oder zuwenig dauerhaft blockiert werden.
Da die ganzen Linux-Tools auf der Hamlib basieren, macht es vielleicht Sinn, auch ein paar Windows Tools zu testen. Ich habe keine Erfahrung, in wie weit diese ebenfalls auf der Hamlib basieren.
Aktuell habe ich noch keinen Überblick, in wie weit CAT ein Standard ist, ich sehe nur, dass es immer irgendwie anders gemacht wird...
Ich lasse mir mit dem Zeug aber Zeit, bis es definitiv funktioniert. Aber es wäre ungeschickt, keinen Delay zum Aufgleisen zu verwenden, wenn dieser Delay a) per Default schon da ist und b) vom SI570 gefordert wird.
Auch ist die Optimierung keine Kritik am Code selbst, es ist reiner Zufall, dass es genau dabei in Problem gab und ich es analysiert habe.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
OE1FHB
noch länger dabei
Offline
Posts: 222
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #87 on: 23. June 2017, 13:28:53 »
|
|
Hallo Andreas, Fehler gefunden ,warum FLDIGI fallweise nicht arbeitet:
wenn in Config z.b. Hamlib geöffnet wird werden einige gespeicherte Eingaben zurückgesetzt obwohl man keine Änderung durchführt.
Danach funktioniert FLDIGI nicht mehr.
Noch eine Frage:
Gibt es ein Comand im FT 817 Protocol mit dem man SWR auslesen kann.
VY 73 Friedrich
OE1FHB
|
|
Logged
|
|
|
|
Pages: 1 ... 4 5 [6] 
|
|
|
|
|
|
|
