Title: CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 07:55:50
Hallo an alle,
die neue daily snapshot beeinhaltet zwei neue Features:
1) Man kann mit menu #332 den BIAS für Electret-Mikrofone jetzt per Firmware ein/abschalten. Das beseitigt einen lauten "plopp" am Anfang einer Sendung, wenn man mit einem dynamischen Mikrofon arbeitet(das braucht nämlich keinen BIAS der stört dort nur).
2) Ferner ist jetzt CAT implementiert.
serieller Treiber für Windows für den STM32F4 (http://www.amateurfunk-sulingen.de/data/uploads/stsw-stm32102.zip)
Nach Installation des Treibers unter "Windows" zunächst in den neuen Ordner (liegt normalerweise unter Programme/STMicroelectronics...) wechseln - dort sind Treiber für Win7 und Win8. Der für Win7 läuft auch mit Vista oder XP.
Es wird die KLEINE USB-Buchse dafür benutzt. Als Protokoll wird das des Yaesu FT817 verwendet. Ich würde mich über Feedbacks freuen!
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 09:57:15
Hallo Andreas,
werde die neue Firmware testen. Das Display ist auch angekommen; das Ablesen der
Frequenz ist nun einfacher.
vielen Dank für Deinen unermüdlichen Einsatz für das Projekt!
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 10:12:38
Gratuliere zum Display!
In der Tat kannst Du das Gerät erst jetzt wirklich ausprobieren...
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 10:44:17
Hallo Andreas,
das neue Display funktioniert auf Anhieb. Musste nur einen Jumper umlöten.
Neue Firmware ist drin. Macht alles einen soliden Eindruck.
Eines ist mir aufgefallen: statt DSP orange hinterlegt, heisst es jetzt
DIGITAL blau hinterlegt, und weiter unten steht FILT. Wenn DIGITAL
reinpasst, sollte doch auch FILTER rein passen. Ausserdem fände ich das
orange hinterlegte DSP oder DIGITAL übersichtlicher. Oder hat es mit
dem DIGITAL noch eine besondere Bewandtnis, kann man damit
noch etwas aktivieren?
vy73s
Roger
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 11:51:24
DIGITAL ist die Vorbereitung für die digitalen Modi. Das ist eine Touch-Taste - einfach mal drauftippen :)
Der sinnlose rote Kasten mit "DSP" ist nun für immer verschwunden - und der sinnlose mit "FILT" wird auch bald weg sein :)
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 02. February 2016, 12:15:33
Hallo Andreas,
habe die neue Firmware aufgespielt.
Kopplung zum WINDOWS-PC (WIN8.1) klappt; virtuelles COM-Port wird im Gerätemanager angezeigt.
Test mit "flrig".
Frequenz und Mode werden korrekt übertragen (bei Änderungen am mchf).
Die Steuerung vom PC aus klappt auch (Frequenz und Mode)
Protokoll ist aktuell mit 9600Baud und 2 Stoppbits; ist das so vorgesehen?
vy 73 aus Erfurt
Michael |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 12:48:27
Ja, die Verbindungsdaten sind korrekt so 8)
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 12:58:12
Hallo Andreas,
ok, habe ich probiert. mit der Touch-Funktion kommen dann FreeDV1 und FreeDV2 !!! !!!
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 13:07:31
...und wenn Du weiter touchst, kommen noch BPSK31, RTTY, WSPR-A und WSPR-P.
Aber das sind zunächst NUR DIE UI-Funktionen - die dazugehörigen Modi und die Einstellscreens für den jeweiligen Modus kommen noch. Da sind noch einige Kilometer zu gehen ::)
Sowie einer der Modi davon irgendwann mal in WEISS und nicht mehr in grau zu sehen ist, steckt schon was dahinter.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 13:11:20
Hallo Andreas,
also bei diesem Display habe ich Probleme mit dem sauberen Durchscrollen bei DIGITAL.
Einmal habe ich es hinbekommen, dass BPSK31 angezeigt wird.
Hingegen kann ich die 2x Vergrösserung und die Umschaltung W-Fall und Scope ohne Probleme umschalten.
Gibt es für die Touchfunktion eine Display-Kalibrierung?
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 14:40:58
Noch nicht. Wird aber irgendwann kommen. Allerdings sind die Ungenauigkeiten bei meinen fünf Geräte so gering, dass sich der Aufwand nicht lohnen würde. Ich habe nich vor, die Knöpfe so klein zu machen, dass man eine Lupe braucht :)
Drück einfach mal etwas länger. Es ist ein resistives Display, das reagiert nicht so präzise wie ein kapazitives...
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 15:19:53
Hallo Andreas,
ja, das habe ich bemerkt, wenn man etwas länger drauf bleibt, geht es besser.
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 02. February 2016, 15:32:20
Protokoll ist aktuell mit 9600Baud und 2 Stoppbits; ist das so vorgesehen?
|
|
Beim STM32F4 virtual port sind die meisten Verbindungsdaten relativ unwichtig. Die Geschwindigkeit, Start und Stopbits, Parität sind in jedem Fall völlig egal, bei den 7 oder 8 Bit könnte es sein, das Windows/Linux freundlicherweise bei 7 Bit ein Bit entfernt. Die Wahl einer COM Geschwindigkeit hat übrigens keinerlei Einfluss auf die reale Kommunikationsgeschwindigkeit, das geht so schnell wie USB es halt macht.
Lediglich bei der Flusskontrolle sollte "keine" aktiv sein. Denn XON/XOFF fügt u.U. Zeichen in den Datenfluss ein. Die Nutzung von HW Flusskontrolle mit RTS/DTR so wie es im Quellcode aussieht, nicht richtig genutzt. Also auch nicht einstellen.
Zusammenfassung: Flusskontrolle auf "Aus", 8Bit, alles andere egal.
73
Danilo DB4PLE
|
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 17:42:10
Hallo Andreas,
habe die neue Firmware auch am zweiten mcHF mit aktivierter Touch-Funktion
eingespielt. Dort funktioniert die Umschaltung, also das Durchscrollen der
digitalen Betriebsarten, sehr gut mit einem Stift.
Am anderen funktioniert das Touch-Display. Jedoch dort, wo das DIGITAL-Feld
ist, scheint er viel unempfindlicher zu sein.
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 18:51:22
Hast Du die Schutzfolie abgezogen? Mit geht es auch, aber bedeutend unpräziser.
Und wie gesagt: die Touchgenauigkeit ist nicht so prall...
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC4AS on 02. February 2016, 19:11:28
komisch bei mir (Windows10 64bit) installiert der Treiber kein Gerät. hab ich was vergessen zu drücken oder einzustellen??
Gruss Andreas
|
Title: Re:CAT Funktion eingebaut
Post by: DC4AS on 02. February 2016, 19:17:49
ahh jetzt gehts...manche treiber müssen halt 3 mal installiert werden bis sie gehen..gg
übrigends Danke Andreas ...Lieferung angekommen
|
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 02. February 2016, 19:18:20
Bei mir noch der Effekt, daß mit dem Ausschalten des mchf die Einstellung "CAT-MODE = ON" (#220) nicht gespeichert wird
Michael |
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 02. February 2016, 19:20:34
Bei mir noch der Effekt:
mit dem Ausschalten des mchf wird die Einstellung "CAD-MODE = ON" (#220) nicht gespeichert
Muß beim Wiedereinschalten neu aktiviert werden
Michael |
Title: Re:CAT Funktion eingebaut
Post by: DC4AS on 02. February 2016, 19:20:55
ja bei mir auch nicht gespeichert
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 02. February 2016, 19:34:45
Das ist kein Bug - das ist so gewollt.
CAT frisst Rechenzeit - es sollte nur dann aktiviert werden, wenn es gebraucht wird. Also KEINE automatische Speicherung.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: OE3HKC on 02. February 2016, 20:38:45
Hallo,
habe CAT auch schon getestet mit der neuen firmware-version...
zum Testen kurz eine ältere Version (Freeware) von hamradiodeluxe installiert, kommuniziert Spitze mit mchf, es werden Frequenzeinstellungen und mode in beiden Richtungen voll unterstützt...
danke, Andreas, ist toll, wie rasch der mchf sich "entwickelt" ::)
freu mich schon jeden Morgen darauf, im qrl den mchf zu starten und zu gucken, was es bei daily snapshots Neues gibt... und gleich wieder raufgespielt die neue software...
vy 73,
Helmut |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 02. February 2016, 23:28:17
Hallo Andreas,
Ja, diese Displayschutzfolie ist bei beiden schon entfernt.
Keine Ahnung, wieso das dort so taub ist.
Vy73s
Roger
|
Title: Re:CAT Funktion eingebaut
Post by: DJ6DB on 03. February 2016, 05:36:31
Vielleicht Streuung der Qualität, ist ja bei Monitoren im PC Segment genau das gleiche.
73 de Daniel |
Title: Re:CAT Funktion eingebaut
Post by: Roger on 03. February 2016, 05:50:18
gut möglich mit der unterschiedlichen Qualität. So bis in die Mitte und etwas
darüber hinaus scheint es gut zu gehen, aber der Streifen links, da ist das Ding
unempfindlich.
vy73s
Roger |
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 03. February 2016, 06:54:25
Hallo und Guten Morgen,
kann auch bestätigen: die CAT-Kopplung läuft ebenfalls unter XP.
Frage mal am Rande:
Für ANDROID-Geräte gibt es ein Programm POCKET RXTX+.
Hat da jemand Erfahrung wie hier die Kopplung aussehen könnte. Alle Adapter, die ich gefunden habe koppeln den 817 über die ACC-Buchse, die hat ja nun mal der mchf nicht.
Ein Tablet ist ja für den Outdoor-Betrieb günstiger (Volumen, Gewicht) als ein Laptop; Andererseits ist ja der Download neuer BIN-Dateien kein Problem damit.
vy 73 aus Erfurt
Michael |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 03. February 2016, 07:11:42
Ich denke, da bräuchtest Du ein Interface.
Es müsste ein Controller sein, der sich am einen Ende die Daten über den (Kauf) Bluetooth to ACC Adapter holt und dann umsetzt auf das benötigte USB/seriell-Protokoll.
Oder man müsste das apk entpacken und reverse engineeren um evtl etwas anderes koppelbar zu machen und ein eigenes Inteface basteln.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 03. February 2016, 07:16:05
Danke Andreas für die Antwort; dachte mir schon, daß es nicht "einfach" lösbar ist.
Nun, schiebe ich das erst mal nach hinten; diese und nächste Woche ist erst mal das Gehäuse dran.
vy 73
Michael |
Title: Re:CAT Funktion eingebaut
Post by: DL3ED on 04. February 2016, 18:08:34
hallo Zusammen,
welches Cat-Programm verwendet Ihr für den MCHF?
Gruß Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DF9EH on 04. February 2016, 18:27:56
Hallo Ulrich,
ich habe folgendes zum testen auf dem Rechner:
--- Fldigi 3.23.04 ----
73 de Klaus |
Title: Re:CAT Funktion eingebaut
Post by: Michael_K on 04. February 2016, 18:29:14
Hallo Ulrich,
auf meinem WIN8.1 - PC läuft das Programm "flrig"; stell die QRG und MODE dar (vom mcHF) und übergibt diese auch an den mcHF; ist Freeware, einfach mal "googlen" zur Startseite.
auf dem XP-Laptop läuft "DXLab", dort ist es das Modul Commander mit den gleichen Eigenschaften; Programm ist insgesamt Freeware, Installation frißt doch Zeit (bei mir ca. 1Std) da nach der Grundinstallation eine ganze Reihe Updates gemacht werden müssen.
Ich nutze es hauptsächlich zur Darstellung digitaler Betriebsarten (BPSK, RTTY); kann aberwesentlich mehr.
Nur zur Kontrolle der CAT-Funktion reicht das flrig aus.
vy 73 aus erfurt
Michael |
Title: Re:CAT Funktion eingebaut
Post by: dl2ki on 08. February 2016, 11:20:44
Hallo,
bei der CAT-Steuerung habe ich folgendes Problem:
Betriebssystem: Kubuntu 14.04 64-bit
CAT-Software: Flrig, 4800bd, 1 Stop-bit, RTS/CTS ein
Mitgliedschaft in Gruppe "dialout" ist gegeben.
Schnittstelle wird erkannt:[size=1]
Q: init_port_combos: Found serial port /dev/serial/by-id/usb-STMicroelectronics_STM32_Virtual_ComPort_in_FS_Mode_00000000050C-if00
Q: init_port_combos: Found serial port /dev/ttyACM0[/size]
---
Beim Initialisieren der Schnittstelleneinstellungen in Flrig, Frequenz = "14070.00" erscheint im mcHF Display "407.000.010". Gebe ich in Flrig z.B. "7123.45" vor, erschint im mcHF-Display "712.345.010".
Beim starten von z.B. Flrig oder Fldigi mit den passenden RigCAT-Einstellungen erfolgt zudem keine automatischen Verbindung zum mcHF. Über Hamlib in Fldigi ebenso nicht.
Frage: Liegt das Problem an den Einstellungen der CAT-Software? Wo könnte ich hier ansetzen?
73, Wolfgang
DL2KI
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 08. February 2016, 12:01:29
Hallo Wolfgang,
es liegt definitiv an den Einstellungen. Eventuell ist auch in dem Proggi ein Bug. Hier hilft nur herumspielen mit allen Einstellungen - oder mal eine andere Version des Proggis nehmen. An der CAT-Funktion im mcHF liegt es auf jeden Fall nicht - die ist schon zigmal verifiziert (von mir selbst auch).
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: dl2ki on 08. February 2016, 20:28:47
Hallo,
nun kann ich eine Lösung des Problems anbieten:
Da meine XYL gelegentlich Win7 benötigt, habe ich das System (64bit) auf dem gleichen Rechner.
Also habe ich mal den Treiber dort installiert und die CAT-Steueriung mit FLDigi und FLRig ausprobiert.
Funktioniert!
Also lautet eine Problemlösung: Von Linux auf Windows umstellen.
73, Wolfgang
DL2KI
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 09. February 2016, 06:23:35
Es könnte an einer fehlerhaften libusb liegen. Da es bei meinem LMDE2 (auf Debian Jessie Basis) aber einwandfrei funktioniert, ist eine Fehlerdiagnose "auf die Ferne" leider nicht möglich.
Auf jeden Fall geistern einige neuere (!!) libusb's rum, die Bugs haben. Am besten zu sehen, wenn man einem Raspi einen RTL-Stick anbietet. Der stürzt beim rennen der TCP-Verbindung ab. Ich habe da eine ältere libusb genommen - und alles ging. Bei Debian Jessie ist das Problem aber out-of-the-box nicht vorhanden.
Vielleicht ist es aber doch ein Einstellungsproblem - ich habe hier auf jeden Fall den Link, dass der STM32F4 virtual serial port vom Linux-Kernel definitiv unterstützt wird:
http://www.wolinlabs.com/blog/stm32f4.virtual.com.port.html (http://www.wolinlabs.com/blog/stm32f4.virtual.com.port.html)
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: dl2ki on 11. February 2016, 08:39:49
Hallo Andreas,
könntest Du mal nachsehen, welche "libusb-1" Version Du aktuell installiert hast ?
Danke.
73, Wolfgang
DL2KI |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 11. February 2016, 08:55:39
Ich habe die libusb-1.0-0 2:1.0.19-1 installiert.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: dl2ki on 11. February 2016, 14:27:44
Hallo,
in Kubuntu 14.04 ist standardmäßig die "libusb-1.0-0 2:1.0.17-1" installiert. Die habe ich nun einmal durch "libusb-1.0-0 2:1.0.19-1" ersetzt.
Leider ohne Erfolg. Das Problem bleibt.
Naja, zum Testen der CAT-Funktion gaht das ja. Demnächst steht eh ein Update der LTS-Version an. Mal sehen ob das da so bleibt.
73, Wolfgang
|
Title: Re:CAT Funktion eingebaut, FLDIGI senden ?
Post by: DL3AAA on 03. March 2016, 18:28:58
Hallo liebe mcHF Freunde,
jetzt läuft die Cat-Schnittstelle und die Soundkarte mit FLDIGI unter Linux Mint 17.
Was mir jetzt noch fehlt ist die Einstellung zum Sendebetrieb. Ich kann mir lebhaft vorstellen das der Fehler wieder vorm Gerät sitzt, nach langem suchen habe ich mich entschlossen das Risiko einzugehen.
Kennt jemand die ZAUBERFORMEL ??
73 Dietrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 03. March 2016, 18:47:58
Hallo Dietrich,
NEIN. Zauberformel kenn ich nicht :-(
Habe aber leider das Problem nicht verstanden. Kannst Du es etwas ausführlicher schildern.
Danke
Danilo |
Title: Re:CAT Funktion eingebaut
Post by: DL3AAA on 03. March 2016, 19:12:53
Hallo Danilo,
Cat funktioniert bidirektional = OK
Sound kommt in FLDIGI an, die Signale werden decodiert =OK
Jetzt kommt's, ich möchte jetzt via FLDIGI senden und gehe davon aus das ich das auch über den USB Anschluss kann. PTT wird über CAT angesteuert ? Wenn ich auf senden gehe leuchtet die Sende-LED kurz auf und das war es.
Es scheint ein kurzer Wischer die PTT anzusteuern, das reicht aber nicht.
Da ich unter Linux arbeite kann es auch an der Steuerdatei Hamlib liegen, da aber CAT funktioniert glaube ich nicht daran.
73 Dietrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 03. March 2016, 20:17:23
Hallo,
wenns nur kurz aufleuchtet, hast Du wahrscheinlich CW-U oder CW-L an.
Schalte auf USB oder LSB, dann sendets auch ordentlich.
73
Danilo
|
Title: Re:CAT Funktion eingebaut
Post by: DL3AAA on 03. March 2016, 20:55:40
Hallo Danilo,
das war die Lösung, danke.
73 Dietrich |
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 16. March 2016, 09:54:40
Hallo,
bei mir funktioniert die CAT-Funktion unter kubuntu und fldigi nicht.
Der Empfang der Funksignale klappt, alle anderen Parameter sowie die Umschaltung auf Sendung gehen nicht.
Die Schnittstelle wird erkannt.
Mit lsusb -v erhalte ich folgende Angaben:
Bus 001 Device 006: ID 0483:5732 STMicroelectronics
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x5732
bcdDevice 2.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 273
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Bin Linux-Anfänger und hab keine Ahnung was ich falsch mache.
Kann jemand helfen?
vy 73 Gert |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 16. March 2016, 09:58:06
Was ergibt auf der Konsole als root
ls -l /dev/ttyACM0
??
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 16. March 2016, 11:19:20
Hallo Andreas,
das ergibt:
ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Mär 16 12:15 /dev/ttyACM0
vy73 Gert |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 16. March 2016, 11:26:58
Das ist schon mal richtig...
Und jetzt rate ich mal:
führe als User (!!) auf der Konsole aus:
id
Ich würde dafür wetten, dass bei "Gruppen" diese wichtige fehlt : dialout
In dem Fall hast Du nicht das Recht, auf serielle Schnittstellen zuzugreifen. Du musst Dich selbst noch der Gruppe dialout zuweisen (als root).
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 16. March 2016, 11:38:46
das ergibt
id
uid=1000(gert) gid=1000(gert) Gruppen=1000(gert),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
Gert |
Title: Re:CAT Funktion eingebaut
Post by: dm6tt on 16. March 2016, 12:23:02
Dein User muss noch in die Gruppe dialout.
Ich mache das meist direkt via Editor in /etc/group.
Oder via
usermod -a -G dialout <user> |
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 17. March 2016, 11:06:57
Hallo Andreas,
danke für deine schnellen Antworten. Leider hat das auch nichts gebracht. User ist jetzt Mitglied von dialout.
Habe fldigi mal von der Konsole gestartet und es scheint ein Problem mit hamlib zu geben.
I: testCommPorts: Found serial port /dev/serial/by-id/usb-mcHF_Open_Source_Community__based_on_STMicroelectronics_Drivers_mcHF_USB_Interface_00000000050C-if00
I: testCommPorts: Found serial port /dev/ttyS0
I: testCommPorts: Found serial port /dev/ttyS1
I: testCommPorts: Found serial port /dev/ttyS2
I: testCommPorts: Found serial port /dev/ttyS3
I: testCommPorts: Found serial port /dev/ttyS4
I: testCommPorts: Found serial port /dev/ttyS5
I: testCommPorts: Found serial port /dev/ttyS6
I: testCommPorts: Found serial port /dev/ttyS7
I: loadDefault: macro file name: /home/gert/.fldigi/macros/macros.mdf
I: loadDefault: loading: /home/gert/.fldigi/macros/macros.mdf
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Verbindungsaufbau abgelehnt (111)
bt_audio_service_open: connect() failed: Verbindungsaufbau abgelehnt (111)
bt_audio_service_open: connect() failed: Verbindungsaufbau abgelehnt (111)
bt_audio_service_open: connect() failed: Verbindungsaufbau abgelehnt (111)
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = Datei oder Verzeichnis nicht gefunden
Cannot connect to server request channel
jack server is not running or cannot be started
F: show_error: hamlib_init: IO error
Werde weitersuchen. Erst mal herzlichen Dank für deine Hilfe.
vy73 Gert
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 17. March 2016, 11:33:20
Der mcHF liegt nicht auf /dev/ttyUSBx oder /dev/ttySx, sondern auf /dev/ttyACM0 . Stell das einfach mal um.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: dl2ki on 17. March 2016, 11:35:16
Hallo Gert,
läuft bei Dir der "Modemmanager" ?
"-> ps aux | grep modemmanager"
http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=417;start=msg4693#msg4693
73, Wolfgang
|
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 17. March 2016, 12:20:00
Danke für die Hinweise. Werde das ausprobieren und berichten.
Danke
vy73 Gert |
Title: Re:CAT Funktion eingebaut
Post by: Gert_L23 on 18. March 2016, 11:56:44
Der mcHF liegt nicht auf /dev/ttyUSBx oder /dev/ttySx, sondern auf /dev/ttyACM0 . Stell das einfach mal um.
vy 73
Andreas
|
|
Hallo Andreas,
das wars.
so einfach und ich habe tagelang herumprobiert.
Danke
vy 73 Gert |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 07. April 2016, 21:21:50
Spiele gerade mal mit fldigi und flrig herum...
Ich bekomme es irgendwie nicht ganz hin. Soundkarte und ttyACM0 sind da.
fldigi:
mchf wird als Soundkarte angezeigt und funktioniert. Wasserfall zeigt sinnvolle Dinge, zum dekodieren fehlt mir noch die Erfahrung. Trotzdem sieht es gut aus.
Aber CAT geht nicht. In Hamlib habe ich den Yaesu selektiert sonst habe ich nichts verstellt, denn virtuelle Serielle via USB sollte keine Einstellung benötigen. Keine Reaktion.
flrig:
Hier kann ich ebenfalls die Yaesu selektieren und ttyACM0 als Port angeben, aber bei Init habe ich plötzlich 407.520.000MHz im Display oder 30. Das Verstellen von Zahlen verändert die Dinge, aber der mcHF macht nur Unsinn.
Also an den Schreibrechten der Ports kann es nicht liegen, denn auch wenn ich fldigi oder flrig mal als sudo starte, machen sie nicht mehr oder weniger.
Der Vollständigkeit: Ich nutze die devel von Heute 7. April. |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 08. April 2016, 06:01:21
Das hört sich nach einem Problem mit der Hamlib an. Leider ist sowas nicht "auf die Ferne" zu finden.
Als erstes würde ich versuchen, einen anderen PC zu nehmen und dort fldigi zu installieren. Das zieht alle anderen notwendigen Pakete nach.
Unter "Konfiguration/Radio Steuerung" wählt Du den Reiter "Hamlib" aus. Dort wählst Du als Radio "Yaesu FT-817" und als Port "/dev/ttyACM0" aus. Fertig - Rest läuft out-of-the-box (wenn Du im erweiterten Configuration Menu des mcHF CAT eingeschaltet hast).
Ob bei Dir der Port auch auf ACM0 liegt kannst Du in den messages (oder im kernellog) erfahren.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 08. April 2016, 07:28:44
Hi Andreas,
Kann man auf der CAT (ttyACM0) auch via Terminal etwas machen? Nur zum Test, versteht sich.
Rechte kann ich ausschließen, denn andere vCOM Devices, wie z.B. der STLink arbeiten einwandfrei. Die STLink Boards stellen ja auch einen ttyACMx zur Verfügung, der an einen der UARTs des STM auf dem NUCLEO oder DISCO Boards angeschlossen ist.
Einen anderen Linux PC habe ich nicht, werde aber mal sehen ob fldigi auch für ARM verfügbar ist, dann hätte ich da noch zwei drei Kandidaten.
Das fldigi wirft, wenn man es auf der Kommandozeile startet einigen Debug aus. Wäre der hilfreich?
Ich suche aber parallel mal im Netz.
vy 73 de Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 08. April 2016, 07:39:11
Bei mir lief das alles out-of-the-box, sowohl auf meinem LMDE2-Gerät als auch auf meinem Raspi3...
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: dm6tt on 08. April 2016, 09:04:58
Mit rigctl kannst du die Hamlib auf Kommandozeile direkt testen.
Schau dir mal dir fldigi Version an. Die mit ubuntu, mint installierte Version lief bei mir nicht. Die hat Probleme mit dem ACM-Interface.
Ich habe dann die 3.23.08 übersetzt, damit geht es.
73, Marcus |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 08. April 2016, 13:54:08
Ich hatte die 3.28.08 aus den Paketquellen installiert. Die scheint in 15.10 also bereits aktuell zu sein.
Alternativ habe ich das zugehörige PPA installiert, das brachte aber die gleiche Version.
Also habe ich mir alles zusammen gesucht und hamlib und einen Großteil der der fldigi Module selber gebacken. Wenn es später funktioniert, werde ich berichten und eine Anleitung befügen, denn ich habe die Schritte zum selber backen von fldigi / hamlib gleich mal notiert.
vy 73 de Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 08. April 2016, 16:21:15
Hallo Astralix,
modemmanager und Co. hast Du schon als Störenfriede ausgeschlossen?
lsof | grep /dev/ttyACM
könnte noch hilfreich sein.
73
Danilo |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 08. April 2016, 20:30:32
Gehen wir mal systematisch ran:
Der Stand ist wie gestern: Sound geht, Serielle nicht.
Also mit System:
1) Programme:
fldigi, flrig, hamlib (und damit rigctl) sind aus den latest greatest Quellen neu gebaut und korrekt installiert.
which [datei] zeigt den für Ubuntu korrekten Pfad /usr/bin/[datei] an und die meisten Versionsnummern sind nun höher als zuvor.
2) Kabel
Zur Sicherheit habe ich mal das augenscheinlich sehr dünne China-USB-Kabel gegen ein hochwertiges getauscht. Wie erwartet kein Unterschied, denn wenn Sound geht, sollte auch UART gehen.
3) Device
Bus 003 Device 010: ID 0483:5732 STMicroelectronics
Ist da, na logisch, Sound geht ja
3) Modemmanager
Ich habe keinen modemmanager, der wäre mir eh immer nur im Weg, weil ich täglich mit zig UART Platinchen aller Marken am Rechner arbeite. Es gibt keinen Service der laut lsof an den Files ttyACM oder ttyUSB hängt.
Der Modemmanager war mir schon vor Jahren immer im Weg, wenn ich Embedded oder ARM Linux gemacht habe, daher ist der mit apt-get remove --purge ganz schnell abgeflogen.
Trotzdem ps aux | grep modem ergibt keinen Treffer (außer der suche selbst)
4) Fremde Dienste blockieren den Port
Eigentlich sollte das einen Fehler produzieren, der wird in den Programmen aber vielleicht nicht abgefangen?
Also picocom -b 115200 /dev/ttyACM0 behält die Verbindung. Wäre das File anderweitig verbunden, meldet picocom das und beendet sich selbst.
lsof | grep "/dev/ttyACM" findet keine Verbindung auf den Port.
5) Rechte
crw-rw-rw- 1 root dialout 166, 0 Apr 8 21:36 /dev/ttyACM0
crw-rw---- 1 root dialout 4, 64 Apr 8 21:26 /dev/ttyS0
...
crw-rw---- 1 root dialout 4, 73 Apr 8 21:26 /dev/ttyS9
crw-rw-r-- 1 root dialout 188, 0 Apr 8 21:26 /dev/ttyUSB0
Natürlich ist mein user in der Gruppe dialout.
6) Noch mal testen...
:~$ rigctl -m 120 -r /dev/ttyACM0 -v
Opened rig model 120, 'FT-817'
Rig command: f
rigctl_parse: input_line: f
get_freq: error = Communication timed out
Wie ich es drehe und wende, der Port nimmt entweder nix an, oder er gibt nichts zurück... Ich teste mal weiter.
vy 73
Ulrich
|
Title: Re:CAT Funktion eingebaut
Post by: dl8mby on 08. April 2016, 20:50:47
Hallo zusammen,
Muss noch vor dem zu Bett gehen meinen Output loswerden.
Hilft Euch das eventuell weiter.
usbhid-dump,
sowie der Link:
https://www.rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/
vy73
Markus
DL8MBY
|
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 08. April 2016, 21:59:54
Danke Markus,
war eine Idee, aber nichts neues :)
Habe mal gerade einen Raspi 2 mit aktuellem MATE bestückt und das fldigi Paket installiert.
mcHF dran, Soundkarte da, ttyACM0 auch...
Leider das gleiche Verhalten. Sound wird dekodiert, aber Steuerung via CAT geht nicht.
Ist es denn immer noch korrekt, dass man in der hamlib die Yaesu FT817 auswählt?
Auch auf dem raspi meldet rigctl -m 120 -r /dev/ttyACM0 dass get_freq: error = Communication timed out
Das wird heute nix mehr
vy 73
Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 08. April 2016, 22:19:45
Hallo,
FT-817 ist absolut korrekt. Ich werde es im Laufe des kommenden Tages nochmal anschauen. An der CAT Emulation und dem USB Code habe ich schon eine Weile nichts geändert und auch niemand anderers.
Schon komisch.
Worauf der mcHF unheimlich allergisch reagiert sind "falsche" Zeichen. Das Protokoll is 5 Byte lang. Wenn da auch nur 1 Zeichen Versatz drin ist, wird es nie was, weil man am Protokoll nicht erkennen kann, wann ein 5 Byte Block anfängt.
Das wird im echten Gerät über einen Timeout geregelt. In der mcHF Emulation noch nicht.
Sollte ich aber mal einbauen.
Im Zweifel sich einfach mal mit dem ST-Link auf die entsprechende Funktion im mcHF legen und schauen was da ankommt.
73
Danilo
|
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 09. April 2016, 05:58:09
Hallo,
am Raspi 2, Rasbian, fldigi aus dem Repository, aktueller devel-DF8OE Source (!, ich baue selbst):
Es funktioniert sowohl CAT als auch Audio problemlos.
Kabel?
73
Danilo
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 09. April 2016, 06:26:43
..oder, wo Danilo das jetzt explizit erwähnt hat - baust Du auch selbst? Hast Du mal das von mir gebaute Binary versucht (daily snapshots)? Vielleicht liegt das Problem ja ganz woanders.
Bis auf die Schwierigkeiten mit dem Modemmanager (oder auch der Braillezeile, die sich schon mal den Port greift) kenne ich keine Probleme mit CAT. Es hat bei mir stets mit allen Geräten out-of-the-box mit den Paketen aus dem Repository geklappt.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 10. April 2016, 09:04:01
Hallo!
Danke für die Ideen!
Ich werde mal das Binary probieren. Habe mich mal mit JTAG drauf geklemmt und kann sehen, dass Pakete empfangen werden, deren Inhalt mir jedoch seltsam vorkommt. Allerdings muss ich mir das Prokoll der FT817 erst einmal ansehen, damit ich as beurteilen kann.
Selber bauen:
- fldigi auf dem Linux PC habe ich selber gebaut, es verhält sich identisch, wie das zuvor getestete fldigi aus den Paketquellen.
- fldigi auf dem Raspi ist aus den Paketquellen installiert und verhält sich identisch.
- mcHF ist selber gebaut mit gcc-5.2 und der einzige gemeinsame Nenner bei dem Problem.
Ich verwende einen eigenen Makefile, der aber keine Veränderungen an den Optimierungen vornimmt. Im Grunde wäre es also gut, wenn die Ursache im Compiler / Toolchain liegt, dann könnten wir mal die Probleme in dem Bereich adressieren. Da mache ich mich dann mal ran.
vy 73 de Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 10. April 2016, 10:09:00
FT 817 Protokoll: Super simple, immer 5 Bytes. Siehe cat_driver.c, dort stehen im Kommentar die von der Hamlib unterstützten Kommandos.
Letztes Byte ist das Kommando, davor können statt der 0 Daten kommen.
mit #define FT817_DEBUG übersetzt gibt es noch einen Buffer ft817.req[], in dem die empfangenen Daten abgelegt werden (bis er voll ist).
Viel Spaß
Danilo
|
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 10. April 2016, 10:25:24
Danke Danilo,
den DEBUG nebst Puffer hatte ich schon entdeckt. Bin nur noch nicht dazu gekommen das auszuwerten. Bei dem Wetter wollen YL und die Hunde an die frische Luft, das wird also bis heute Abend warten müssen.
vy 73
Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 10. April 2016, 17:41:38
Also ich habe mich mal an den USB Code gemacht...
Dabei auch gleich etwas aufgeräumt, da gab es ein paar Unstimmigkeiten.
CatInterfaceState cat_driver_state() { return USBD_User_GetStatus(); }
Dabei wird in
void CatDriverFT817CheckAndExecute() {
bei der Antwort 0xff der Puffer zurückgesetzt, weil wohl angenommen wird, dass keine USB Verbindung mehr besteht.
USBD_User_GetStatus() ist wohl aus den ST-Libs? jedenfalls kennt die eigentlich nur 0 und 1 als Antwort.
Das ist aber nicht das Problem. Bei mir landen die CAT Telegramme um 1 byte nach links versetzt im Puffer, ich habe also nicht
00 00 00 00 03 als GET FRQ AND MODE bsi mir steht da
00 00 00 03 00
Damit ist es also das fehlende Framing, dass da Ärger macht und ehe ich jetzt lange suche, hat jemand eine Funktion im mcHF entdeckt, mit der ich z.B. eine ms genaue Laufzeit bekommen kann?
Dann wäre es sehr einfach, den für das Protokoll notwendigen Timeout zu implementieren.
Ich habe auch schon ein wenig umgestellt, als eine uinion für das Telegramm, ENUMs für die Befehle...
Habe noch ein paar Optimierungen vorbereitet, aber eines nach dem Anderen. Wenn ich mit Timeout die Telegramme korrekt verschieben kann, kann ich die Ausführung von CAT noch deutlich schneller machen.
vy 73
Ulrich
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 10. April 2016, 17:45:07
Hallo Ulrich,
das läuft bereits mit vielen Nutzern von Windows und Linux! Ich würde an deiner Stelle in Betracht ziehen, dass das Problem irgendwo bei Dir und nicht in der Firmware zu suchen ist!
Was mir noch fehlt ist die Aussage, ob es mit einem fertig gebauten daily snaphot die gleichen Probleme gibt.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 10. April 2016, 18:43:51
Auch mit dem daily snapshot von hier
http://www.amateurfunk-sulingen.de/mchf-projekt/modifikationen#start
auf der Seite ganz unten habe ich das gleiche Problem.
Sowohl die Linux, wie auch der RasPi mögen nicht.
Habe ja schon gesehen, dass der SysTick auch als solcher verwendet wird, damit habe ich ja dann eine ms Timeout Clock.
vy 73
Ulrich
|
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE on 10. April 2016, 18:57:51
Dabei auch gleich etwas aufgeräumt, da gab es ein paar Unstimmigkeiten.
CatInterfaceState cat_driver_state() { return USBD_User_GetStatus(); }
Dabei wird in
void CatDriverFT817CheckAndExecute() {
bei der Antwort 0xff der Puffer zurückgesetzt, weil wohl angenommen wird, dass keine USB Verbindung mehr besteht.
USBD_User_GetStatus() ist wohl aus den ST-Libs? jedenfalls kennt die eigentlich nur 0 und 1 als Antwort.
|
|
Ich habe das auf 0xFF geändert (vorher 0) weil es so nicht funktioniert hat (hat immer zu den Buffer resettet, ist auch logisch, es kommt ja immer wieder 0 wenn man fragt). Vorallem aber war es einfach nicht notwendig, das zu fixen. Hat ja auch so funktioniert.
Das ist aber nicht das Problem. Bei mir landen die CAT Telegramme um 1 byte nach links versetzt im Puffer, ich habe also nicht
00 00 00 00 03 als GET FRQ AND MODE bsi mir steht da
00 00 00 03 00
Damit ist es also das fehlende Framing, dass da Ärger macht und ehe ich jetzt lange suche, hat jemand eine Funktion im mcHF entdeckt, mit der ich z.B. eine ms genaue Laufzeit bekommen kann?
|
|
In der Tat finde ich es verwunderlich, das hier zuverlässig ein Versatz ist. Normalerweise kann das nicht passieren, macht es ja auch bei den meisten nicht. Es werden ja alle 5 Byte in einem USB Packet geschickt. Da ist es schwierig, mittendrin zu unterbrechen. Nur wenn ein Programm dazwischen funkt oder abstürzt, sehr viele Packete hintereinander verschickt werden, ist ein Versatz logisch erklärbar.
Dann wäre es sehr einfach, den für das Protokoll notwendigen Timeout zu implementieren.
|
|
ts.sysclock ca. 10ms Takt (abgeleitet aus 1,5Khz Audio-Interrupt).
Normaler Sysclock interrupt ist nicht angeschaltet.
Ich habe auch schon ein wenig umgestellt, als eine uinion für das Telegramm, ENUMs für die Befehle...
Habe noch ein paar Optimierungen vorbereitet, aber eines nach dem Anderen. Wenn ich mit Timeout die Telegramme korrekt verschieben kann, kann ich die Ausführung von CAT noch deutlich schneller machen.
|
|
Nur zu, ordentliche Strukturen im Code sind willkommen.
Wobei die Performance der CAT Befehle aus meiner Sicht eher nicht so kritisch ist, da sie relativ selten kommen und insgesamt kaum auftragen sollten im Vergleich zum UI, in dem ja ähnliche Funktionen aufgerufen werden und das deutlich mehr Code ausführt. Schaden solte es aber auch nicht.
73
Danilo |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX on 10. April 2016, 21:49:37
Danke,
ES GEHT!
Hätte jetzt den SysClock Counter abgefragt, da ich ja nur ein Delta brauche, keinen Interrupt. ts.systime geht aber auch gut.
Es soll ja nur nachgesehen werden, ob der Anfang des Telegramms schon mehr als 200ms in der Vergangenheit liegt, bevor es beendet wurde. Das habe ich jetzt implementiert und es geht!
Eigentlich sollten ja auch nicht mehr als ein Telegramm im USB->CAT Buffer liegen, aber USB und Timing ist so eine Sache, der packt einfach gerade das über den Bus, was gerade da ist. Also lassen wir das erst mal so.
Mir ist beim debuggen aufgefallen, dass im Buffer AT Befehle sind. Ich habe definitiv keinen Modemmanager laufen, aber ich gehe davon aus, dass das udev die Schnittstelle erkennt und eine Hardware-Erkennung dann loslegt um das Gerät zu identifizieren. Dieser Müll verursachte dann einen Offset von 1.
Es ist ebenfalls aufgefallen, dass der USB Stack sich das ein oder andere merkt. So habe ich gleich beim Start des mcHF schon CAT Telegramme empfangen, die ich wohl vorher mal versucht habe zu senden, und die dann wegen JTAG HALT noch im USB Puffer des Host lagen.
Schon jetzt ist ein TODO in der Liste:
Es ist möglich, dass die Kombination aus Schrott im Puffer + Timeout dafür sorgt, dass das erste Telegramm verloren geht.
Ich schreibe das jetzt mal noch schön und teste es, dann mache ich einen Mergerequest.
vy 73!
Ulrich |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE 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
|
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 11. April 2016, 06:12:10
Die Braillezeile...
Komisch nur,dass mein Raspi mit einer jungfräulichen Raspbian Installation sofort funktioniert hat. Ich musste weder eine udev-Rule anlegen noch irgendein Programm deinstallieren.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DL3AAA 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 |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX 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 |
Title: Re:CAT Funktion eingebaut
Post by: DB4PLE 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
|
Title: Re:CAT Funktion eingebaut
Post by: DC3AX 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 |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE 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 |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 12. April 2016, 10:18:49
UPDATE:
Ich habe eben mal auf meinem Debian Jessie und meinem Raspbian die Braillezeile installiert. Der Daemon läuft, aber der mcHF wird nicht angesprochen.
Offenbar gibt es Versionen der Braillezeile, die allzu heftig Devices für sich claimen.
Das ist ein Softwarebug, denn der mcHF hat definitiv keine USB-Kennung, die einer Braillezeile gehört.
--> Bugreport an die Maintainer des brltty-Paketes, wenn deine Version neuer ist als die 5.2~20141018-5 (die läuft nämlich fehlerfrei).
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX 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 |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 12. April 2016, 13:07:43
Es darf halt nichts Negatives bewirken - das ist alles. Da USB eben nicht streng an eine Zeitschiene gebunden ist, ist das nicht ganz einfach. Schließlich soll keine CAT-Verbindung abgeschossen werden.
Ich habe mal damit experimentiert. Wenn ich die USB-Geschichte auch nur leicht verzögere (z.B. durch ein Zurücksetzen, bleibt mein WSJTX stehen mit der Fehlerbox "CAT Unterbrechung" und macht erst weiter, wenn ich irgendwas anklicke. Sehr ärgerlich wenn das Mitten in der Nacht passiert und ich es erst am nächsten Morgen sehe.
Ich suche gerade, warum das sporadisch selbst jetzt schon passiert.
Ich befürchte, dass weitere Eingriffe in die CAT-Routinen etwas verschlimmbessern könnten. Denn es läuft absolut stabil - ich habe NULL Probleme damit. Auch die Probleme anderer mit CAT/USB sind scheinbar sehr gering - um das Thema ist es sehr ruhig...
Ich würde ein Binary mit einer Rücksetzroutine erstmal intensiv testen wollen. Die Testzeit dürfte dramatisch länger sein als die Commitabstände. Deswegen müsste ich das vorab testen und würde es erst einpflegen, wenn es sich woanders nicht störend bemerkbar macht.
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: DC3AX 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 |
Title: Re:CAT Funktion eingebaut
Post by: DF8OE on 13. April 2016, 17:31:02
Hallo Ulrich,
ich denke, wir sprechen schon die gleiche Sprache (nur vielleicht nicht den gleichen Dialekt)...
Verbesserungen sind immer willkommen. Aber bei der Komplexität der Firmware gibt es 1000 Stellen, an denen man sich hoffnungslos verzetteln kann. Ich weiß das sehr gut, weil ich diesen Prozess bereits mehrmals durchlaufen habe ::)
Daher muss eben gut überlegt werden, wo man seine Zeit hinsteckt.
Hamlib auf Windows hat vermutlich die gleichen Eigenschaften wie auf Linux. Du könntest also einfach postulieren, dass es so ist und den "Timeout" abhandeln.
Ob das allerdings Probleme mit dem Modemmanager bzw. der Braillezeile löst - muss man sehen. Try&Error - mache ich dauernd :)
vy 73
Andreas |
Title: Re:CAT Funktion eingebaut
Post by: OE1FHB 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 |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|