Title: UI-Board und Linux
Post by: dl1dsp on 22. June 2016, 07:29:32
Hallo.
Nachdem ich das UI-Board bestückt hatte, stand für mich fest, dass die Firmware vom mcHF-Github von DF8OE unter Linux aufgespielt werden muss. Des weiteren wollte ich das UI-Board separat, also ohne RF-Board, testen. Dazu müssen +5 V für die Versorgung des Prozessors und des Displays bereitgestellt werden.
Dieses Herangehen hat folgende Vorteile:
- Das Brücken des Tasters S17(POWER) ist bei der Inbetriebnahme nicht erforderlich.
- Bei der Beschränkung auf das System Prozessor/Display gestaltet sich eine eventuell erforderliche Fehlersuche wesentlich einfacher.
- Es müssen noch nicht alle Modifikationen ausgeführt sein, um die Hardware – nach eingespielter Software – zu testen. Das gilt insbesondere für die Modifikation UI-04-N-017 (Firmware-Update über USB-Speicherstick), die dann ausgeführt werden kann, wenn die Hardware erst einmal in ihrer Ausgangskonfiguration läuft, um dann die Feinheiten bei der Inbetriebnahme anzugehen.
Um es einmal ganz deutlich zu sagen: Für das Flashen unter Linux ist – wie unter Windows auch – nur ein USB 2.0 Anschlusskabel Mini-USB Stecker (B5) auf USB-A Stecker erforderlich, welches z.B. bei Pollin unter der Bestellnummer 722 216 bestellt werden kann. Also: Wer nicht selbst entwickeln will, braucht auch unter Linux kein ST-Link o.ä. Diese Information findet sich zwar auch an anderer Stelle im Forum, aber sehr versteckt oder nur implizit. Auch ist die Beschreibung für das Vorgehen mit Hilfe des DFU-Modus unter Linux nur schwer zu verstehen.
In Ergänzung zur Seite "mcHF – die erste Inbetriebnahme" möchte ich hier ein Protokoll (siehe Anhang) vorstellen, mit dem die Inbetriebnahme – vom ersten Anlegen der Spannung bis zum Restart des Prozessors – protokolliert werden kann. Die von mir gemessenen Spannungen und Ströme habe ich als Referenz eingetragen.
Die Punkte 11 bis 18 dieses Protokolls beschreiben speziell das Vorgehen zum Aufspielen der Firmware unter Linux. Voraussetzung ist, dass die Firmware (mchf.bin) und der Bootloader (bootloader.dfu) heruntergeladen wurden und in einem Verzeichnis auf dem PC/Laptop abgespeichert sein müssen. Des weiteren muss das Programm dfu-util installiert sein.
Windows-User können das Protokoll ebenfalls nutzen, wenn sie, statt der Anleitung der Punkte 11 bis 18 zu folgen, die entsprechenden Windows-Programme (speziell DeFuSE) ausführen.
Da ich in Vorbereitung der Inbetriebnahme sehr viel Zeit darin investiert habe, die erforderlichen Informationen dafür zusammenzutragen, hoffe ich, dass diese Zusammenstellung allen, die noch vor diesem Problem stehen, helfen kann, diesen Aufwand zu verringern.
Auf keinen Fall werden die Informationen der Seite "mcHF – die erste Inbetriebnahme" ersetzt.
Noch ein paar Überlegungen zur Firmware. Zum Bootloader (bootloader.dfu von DF8OE) gibt es nicht viel zu sagen, da ja nur die Version vom 06.01.2016 13:26:5 existiert. Für die eigentliche Software nimmt, wer sicher gehen will, die Version V1.0.0 der Firmware. Andererseits spricht nichts dagegen, die aktuelle Software zu flashen. Nach einem Download sollte man aber die Beiträge im Forum verfolgen, so dass man hier eine stabile und möglichst fehlerfreie Version erwischt …
Für "Historiker" zum Schluss noch ein Hinweis zu den Anfängen: An Hand der Posts zu den Themen "Test UI-Board" und "Bootloader mcHF_boot_0.0.0.14", aber auch anderer, lassen sich die Irrungen und Missverständnisse zum Thema der Inbetriebnahme des mcHF unter Linux nachvollziehen.
vy 73
Winfried
Ergänzung am 24. Juni 2016:
Das Programm dfu-util muss mit root-Rechten aufgerufen werden (siehe aktualisierte Protokoll-Datei im Beitrag #4 am 24. Juni 2016) oder das Linux-System muss entsprechend konfiguriert werden.
Die Datei mit dem Inbetriebnahme-Protokoll wurde ergänzt und lautet jetzt
https://www.amateurfunk-sulingen.de/forum/attachments/Inbetriebnahme-Protokoll_UI-Board_.pdf
|
Title: Re:UI-Board und Linux
Post by: DF8OE on 22. June 2016, 07:49:15
Hallo Winfried,
vielen Dank für die Bereitstellung deines Inbetriebnahmeprotokolls! Ich finde es ehr gelungen und würde es gerne auf unseren Projektseiten unter "erste Inbetriebnahme" als Link zum Download anbieten. Darf ich das tun?
vy73
Andreas |
Title: Re:UI-Board und Linux
Post by: dl1dsp on 22. June 2016, 11:23:25
Hallo Andreas,
selbstverständlich.
Die pdf-Datei ist übrigens als PDF/A-1a-Datei und als Hybrid-PDF (mit eingebetteter ODF-Datei) abgespeichert worden.
vy 73
Winfried |
Title: Re:UI-Board und Linux
Post by: dl1dsp on 24. June 2016, 07:43:54
Hallo.
Hier noch ein paar Tipps:
- Für den Anschluss der +5 V an Pin 28 und der Masse an Pin 25 der Pfostenleiste P1 eignet sich gut eine Anschlussleitung mit Steckbuchsen (vierpolig, wobei nur die beiden äußeren Anschlüsse vorhanden sein müssen) aus einem alten PC. Der Anschluss sitzt stabil und hilft beim Finden der richtigen Position auf der Pfostenleiste …
- Wenn man vor dem Einbau der Pfostenleisten jeweils eine dünne Litze in das Loch des Pins 7 der Pfostenleiste P1 und in das Loch des Pin 1 der Pfostenleiste P8 vor deren Einsetzen steckt und so die Modifikation UI-04-N-026 vorbereitet (die Enden bleiben erst einmal offen), spart sich das Bohren eines Lochs in das UI-Board, wenn man die Modifikation ausführt, wie es auf den Bildern des UI-Boards auf der Seite "mcHF - Eigenbau-Gehäuse" http://www.amateurfunk-sulingen.de/mchf-projekt/mchf-case#start von Andreas/DF8OE gezeigt wird …
Zur Illustration habe ich noch ein Bild angefügt.
vy 73
Winfried
P.S.: Diese Überlegungen kamen für mich und die Litze in Pin 7 der Pfostenleiste P1 zu spät, so dass ich das Loch wohl doch bohren muss ...
|
Title: Re:UI-Board und Linux
Post by: dl1dsp on 24. June 2016, 15:46:02
Hallo.
Hier eine aktualisierte Protokoll-Datei (im Anhang), die berücksichtigt, dass das Programm dfu-util mit root-Rechten aufgerufen werden muss.
vy 73
Winfried
|
Title: Re:UI-Board und Linux
Post by: peter_77 on 25. June 2016, 07:22:48
Viele, wenn nicht alle dieser o.a. Modifikationen entfallen bei der aktuellen Platinen Version 0.5.
Da vom Chris keine anderen Versionen mehr geliefert werden basieren aktuelle Inbetriebnahmen also eher vermutlich auf dieser Version.
Mit Ver. 0.5 ist nichts weiter zu machen für eine nur UI Inbetriebnahme
Ich habe gestern ein neues UI Board mit STM32F427 MCU blind, sprich ohne Display nur mit den 2 LEDs, in Betrieb genommen.
DF8OE UI Prozedur und "Forumsstandard" mit P1 Stiftleiste (Männchen) auf dem UI Board.
ACHTUNG: Bei der Pin Nummerierung der Leiste:
http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=520
Das "Protokoll" dazu ist recht einfach:
- Ich verwende Standard Breadboard (Steckbrett) Steckkabel (Buchse-Stecker) zum Aufstecken auf die Stiftleiste.
- Jumper P6 gesteckt.
- Masse auf Pin 30 gesteckt der Pfostenleiste und Kabel per Krokoklemme ans Netzteil angeklemmt
- +5V auf Pin 28 gesteckt, noch nicht angeklemmt
- Band (+) gedrückt gehalten und 5V an Pin 28 Kabel per Kroko ans Kabel angeklemmt.
- Der Windows "USB Gong" ertönt und das Symbol "STM32 in DFU Mode" i.d. Taskleiste
- DeFuse gestartet und bootloader.dfu geladen.
- 5V abgeklemmt.
- Jumper P6 wieder entfernt.
- Fädeldraht von USB Mini Buchse an 5V Regler des 0.5er Bords gelötet. Zusehen im Foto hier: http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=489;start=msg6705#msg6705 auf der rechten Seite der UI Platine an der USB Buchse !
- Mit dem neuen Ver. 2.0.0 Bootloader von Andreas kann diese Prozedur entfallen, da die SW jetzt von der großen USB Buchse per Stick geladen wird !! Diese hat per se schon 5V anliegen !
- Adapterkabel mit USB Stick und mchf.bin aufgesteckt ....und Rest der USB Stick Update Prozedur ist ja bekannt ;) *)
- Fertisch !
Anhand der LEDs und auch ohne Display kann man schon grob "sehen" oder hören (Windows USB "Gong") ob es klappt.
Nach Kürzen der Display Stifte und Einstecken des Displays konnte man dann auch mit LCD "sehen" das alles funktionierte.
Als OS-X User bin ich auch kein großer Winblows Freund aber die Flashprozedur mit DeFuse ist in nicht mal einer Minute ohne große Frickelei erledigt.
Letztlich ist dieser Bootloader Flash Schritt aber auch unter Linux oder MacOS ein Kinderspiel.
Müsste man eigentlich mit meinem Raspberry Pi hier nochmal nachvollziehen nur just for Fun.... (sofern es auf ARM Linux rennt ?!) 8)
*) Scheinbar wohl doch nicht... ;D
http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=521
Zum Firmware Update immer nur Band - gedrückt halten !!
Band + ist für den Bootloader. |
Title: Re:UI-Board und Linux
Post by: dl1dsp on 25. June 2016, 14:59:40
Hallo peter_77,
da ich kein Board der Version 0.5 habe, kann ich mich nur auf die Schaltungsunterlagen von Chris und den Aussage in diesem Forum beziehen. Hieraus geht eigentlich nur hervor, dass sich die Inbetriebnahme des UI-Bords (Flash-Prozess) beider Versionen, wie Du ja auch festgestellt hast, nicht unterscheidet.
Ich finde es gut, dass Du in Deinem Beitrag unter diesem Thema das Vorgehen unter Windows noch einmal zusammenfasst. Da ich privat nicht mit Windows arbeite, konnte ich das natürlich nicht selbst machen.
Das Vorgehen unter Linux ist aber auch nicht komplizierter. Das Flashen des Bootloaders beschränkt sich auf nur einen Befehl. Da es dfu-util zulässt, auch .bin-Dateien zu flashen (nicht nur .dfu-Dateien!), erscheint es mir legitim, bei diesem Prozess auch gleich noch die eigentliche Firmware zu flashen ...
Alles andere ist nur eine Hilfestellung, um zu verfolgen, ob der Prozessor des UI-Boards erkannt wird und ob der Flash-Prozess erfolgreich durchgelaufen ist. Das ist im Erfolgsfall nicht so wichtig, aber lass mal etwas klemmen ... Also, ich bin in einem solchen Fall für jeden Fingerzeig dankbar.
Das von Dir beschriebene Vorgehen für die Versorgung der Mini-USB-Buchse mit +5 V halte ich für problematisch, da diese Buchse eigentlich der Anschluss für eine DFU-Verbindung ist (Pin 1 wird vom PC/Laptop mit +5 V versorgt) und mit dem Bootloader von DF8OE eher missbraucht wird. Daher hat Andreas in der Modifikation UI-04-N-017 ja auch unbedingt eine Schottky-Diode (mit niedriger Flussspanng) vorgesehen.
Also: Wenn jemand den Draht direkt vom Pin 1 (J11) an +5 V zieht (das trifft sowohl für die UI-Board-Version 0.4 als auch für die Version 0.5 zu und ist unabhängig davon, ob hier ein gesonderter Spannungsregler zum Einsatz kommt; es sei denn die Entkopplungsdiode ist im Spannungsregler integriert, was ich (zumindest auf die Schnelle) dem Datenblatt des Spannungsreglers nicht entnehmen konnte), sollte er vor einem erneuten direkten Anschluss eines PC/Laptops an J11 unbedingt beachten, diesen Draht wieder zu kappen!!!!
Wenn es mit dfu-util auf dem Raspberry nicht gehen sollte, gibt es garantiert ein anderes Programm, mit dem sich der Flashprozess durchführen lässt.
vy 73
Winfried
|
Title: Re:UI-Board und Linux
Post by: peter_77 on 25. June 2016, 17:20:54
"Das von Dir beschriebene Vorgehen für die Versorgung der Mini-USB-Buchse mit +5 V halte ich für problematisch,"
Da hast du natürlich nicht ganz unrecht, keine Frage aber wenn man sich entscheidet den Forums Bootloader zu installieren und somit bei der Update Prozedur per Stick bleibt, benötigt man die Buchse nicht unbedigt mehr in einem anderen Mode, sprich muss ihn nicht mehr an einen Rechner anschliessen.
Mehrfaches, versehentliches Stecken mit 5V von U8 per Mini USB auf den Rechner hat übrigens sowohl dieser als auch der Spannungsregler U8 bis dato klaglos überstanden.
Update:
Die Diskussion darüber ist mit dem aktuellen Bootloader Ver 2.0.0 bzw. HAL Version 3.0.2 jetzt überflüssig, denn der nutzt die große USB Buchse die per se mit 5V versorgt ist !
Die kleine kann dann gänzlich ohne 5V verbleiben, was auch besser ist als reine USB Client Buchse !
Es sollte auch keinesfalls ein Postulat für Winblows sein hier (bin ja bekennender OS-X User und musste mir den Win Laptop leihen ;) ) sondern lediglich zeigen das der Flashprozess kein Hexenwerk ist... |
Title: Re:UI-Board und Linux
Post by: dl1dsp on 25. June 2016, 18:17:19
Hallo peter_77,
da kann ich mitgehen ...
vy 73
Winfried
|
Title: Re:UI-Board und Linux
Post by: dl1dsp on 10. September 2016, 19:22:02
Empfangsseitig läuft mein mcHF mittlerweile, habe aber noch nicht alle Modifikationen durchgeführt, da ich zur Zeit noch mit dem Gehäuse (analog des Aufbaus von DG8WM, siehe http://www.mdtweb.de/, Feltron-Zeissler-Gehäuse vom Typ 2010-0505: 245 x 85 x 180 mm (BxHxT) mit Füßen 2008-2510) beschäftigt bin. Auf Grund der neueren Entwicklung kann ich mir ja nun die Modifikation der kleinen USB-Buchse ersparen (manchmal ist es doch von Vorteil, nicht zu den Schnellsten zu gehören …)
Beim Lösen der Aufgabe, den neuen Bootloader auf den mcHF zu überspielen, ist mir der Gedanke gekommen, nicht nur P6 sondern auch S14 (BANDP) und S17 (POWER) von der UI-Platine herauszuführen und an von außen zugängliche DIP-Schalter (o.ä.) anzuschließen. Damit kann man dann auch relativ komfortabel, also ohne Knopfdruckakrobatik und ohne die Benutzung eines USB-Sticks, die aktuelle Software auf den mcHF überspielen.
Nach dieser kleinen Harware-Ergänzung lässt sich der Download der Software (des Bootloaders aber auch des Systems) wie folgt über ein USB-Kabel und die kleine USB-Buchse vornehmen:
1. mcHF ausschalten;
2. USB-Kabel an eine USB-2-Buchse des PCs und an die kleine USB-Buchse des mcHF anschließen;
3. DIP-Schalter P6 auf "ein";
4. DIP-Schalter S14 (BANDP) auf "ein";
5. DIP-Schalter S17 (POWER) auf "ein" --> mcHF-Display leuchtet;
6. nach ca. 3 s: DIP-Schalter S14 (BANDP) auf "aus";
7. Download der Software auf den mcHF mittels dfu-util entsprechend der Beschreibung im "Protokoll" (siehe Inbetriebnahme-Protokoll_UI-Board_.pdf im Eingangsbeitrag dieses Themas: https://www.amateurfunk-sulingen.de/forum/attachments/Inbetriebnahme-Protokoll_UI-Board_.pdf);
8. DIP-Schalter S17 (POWER) auf "aus";
9. DIP-Schalter P6 auf "aus";
10. USB-Kabel von der USB-2-Buchse des PCs und der kleinen USB-Buchse des mcHF trennen;
11. mcHF wie gewohnt über S17 (POWER) einschalten und die neu aufgespielte Software sollte auf dem mcHF laufen.
Auch an dieser Stelle noch einmal der Hinweis: dfu-util läuft auch unter Windows.
vy 73
Winfried
P.S.: Ich glaube, Andreas hat eine ähnliche HW-Lösung (Bilder https://www.amateurfunk-sulingen.de/data/uploads/cimg3842.jpg, cimg3841.jpg und cimg3840.jpg auf der Seite https://www.amateurfunk-sulingen.de/mchf-projekt/mchf-case#start, die Erläuterungen zu den Bildern kann ich im Augenblick nicht finden) mit Jumpern auf dem UI-Board realisiert, die aber leider nicht ohne das Öffnen des Gerätes zugänglich ist ... |
Title: Re:UI-Board und Linux
Post by: DF8OE on 11. September 2016, 08:05:29
Richtig. Weil ich sie nicht brauche. USB-Stick rein - Knöpfe drücken - 10 Sekunden warten - fertig.
Ich wüsste nicht, was ich da noch ändern oder nach Außen legen sollte.
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: ve3ll on 06. May 2018, 02:38:08
| I have a problem with USB audio in Linux Mint. See pictures. Please help me to fix this problem. |
Title: Re:UI-Board und Linux
Post by: ve3ll on 06. May 2018, 02:43:32
| there is screenshot audio settings JTDX program. |
Title: Re:UI-Board und Linux
Post by: DF8OE on 06. May 2018, 08:33:55
Please take a newer version of your Linux application. I do not know which application you are using but there are a few which contain this bug - I have recognized this by myself.
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: ve3ll on 06. May 2018, 13:00:46
| Thanks for the answer. I'm using JTDX last version. But in Windows that program works well via USB. As I understand in Linux should work too. May be something wrong is in Pulseaudio. |
Title: Re:UI-Board und Linux
Post by: DF8OE on 06. May 2018, 13:42:29
What do you think about usage of WSJTX? ::)
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: ve3ll on 06. May 2018, 16:41:39
| LTDX is much better. It has better sensitivity, better functionality. |
Title: Re:UI-Board und Linux
Post by: DF8OE on 06. May 2018, 16:51:43
...but WSJTX works without any issue...
First step should be to test if WSJTX does work without this issue or not. If the issue persists problem is not related to application and we can investigate further. If problem vanishs it is located in application (not in Linux, Pulse Audio or anything else). Then you can make an issue reort to JTDX programmers.
Edit:
I have tried JTDX. First issue was that there is no package for Linux 64 bit release version ("404" error).
Second issue was: I downloaded 64 bit version of evaluation version and it cannot install on my 64 bit system because of it depends on a handful of i386 versions of other packages (???!!!???)
Code:
root@wst-andreas:/test # dpkg -i /home/andreas/Downloads/jtdx_18.1.0_step84_amd64.deb
Vormals nicht ausgewähltes Paket jtdx:i386 wird gewählt.
(Lese Datenbank ... 761635 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../jtdx_18.1.0_step84_amd64.deb ...
Entpacken von jtdx:i386 (18.1.0-step84) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von jtdx:i386:
jtdx:i386 hängt ab von libfftw3-single3.
jtdx:i386 hängt ab von libgfortran3 (>= 4.6).
jtdx:i386 hängt ab von libgomp1 (>= 4.9).
jtdx:i386 hängt ab von libqt5core5a (>= 5.5.0).
jtdx:i386 hängt ab von libqt5gui5 (>= 5.2.0) | libqt5gui5-gles (>= 5.2.0).
jtdx:i386 hängt ab von libqt5multimedia5 (>= 5.2.0).
jtdx:i386 hängt ab von libqt5network5 (>= 5.0.2).
jtdx:i386 hängt ab von libqt5serialport5 (>= 5.1.0).
jtdx:i386 hängt ab von libqt5widgets5 (>= 5.2.0).
jtdx:i386 hängt ab von libgfortran3 (>= 4.8.2).
jtdx:i386 hängt ab von libqt5serialport5 (>= 5.2).
jtdx:i386 hängt ab von libqt5multimedia5-plugins (>= 5.2).
jtdx:i386 hängt ab von libqt5widgets5 (>= 5.2).
dpkg: Fehler beim Bearbeiten des Paketes jtdx:i386 (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für man-db (2.8.3-2) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
jtdx:i386
|
|
Third issue was: It is written that it is a forked WSJTX (WSJTX is GNU GPLv3) but a few lines later it is written that it is "© 2016-2017 by Igor Chernikov, UA3DJY and Arvo Järve ES1JA" - that is a inconsitency. If it is forked it cannot legally be copyrighted like this. Additionally I do not find a repository where I can take a look at the sources. I do not hope it is a fork whichs sources now are hidden...
As I uninstalled the package I got strange error messages. I dug into the package and recognized that the "amd64 package" is in truth an "i386" package and it installs binaries to /usr/local/bin instead of "usr/bin". Very, very strange. I kicked it off my PC.
Again I remembered that an early version of WSJTX does have the issue you reported (I think it was 1.6.x). Can it be that the sources of JTDX are based on this faulty WSJTX base???? Hmmmmm.......
Sorry. Actually I do not want to use this.
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: ve3ll on 06. May 2018, 23:44:58
| I'm using Linux Mint 18.3 64 bit. In my system JTDX program was install without any problem, WSJT too. WSJT don't work via USB too, see picture. That is why I think that problem is not in the program JTDX. But I'm not so familiar with Linux yet to solve this problem. But in Windows 10 both program are working good. |
Title: Re:UI-Board und Linux
Post by: DF8OE on 07. May 2018, 07:00:28
Linux Mint "with number" is based on Ubuntu. I am using Siduction and LMDE (Linux Mint Debian Edition). Both are based on Debian, both are working flawlessly with newest WSJTX. If you do have problems with WSJTX, too it may be due to your soundsystem. That is very strange - you cannot fix samplerate to a wrong value by accident! Please start application via terminal and look at the error messages which are thown there. Error messages on terminal are much better than error boxes of GUI.
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: peter_77 on 07. May 2018, 10:32:26
Maybe this helps ?! WSJT audio settings on Raspian and Debian:
https://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=544
|
Title: Re:UI-Board und Linux
Post by: ve3ll on 08. May 2018, 01:43:04
Thank you for help. I have try , but no changes. Please send me your daemon.conf file. I compare it with my daemon.conf May be find something.
Thanks. |
Title: Re:UI-Board und Linux
Post by: ve3ll on 10. May 2018, 01:57:41
| I have adjusted USB sound for transmit (from PC to mcHF via USB), but PC can not read sound via USB from mcHF. I determine that problem with sound is im my system. Could you give me parameters of USB sound in mcHF sound card. Wich audio codec should be installed in Linux system for catch sound from transceiver. I try to fix out the problem. |
Title: Re:UI-Board und Linux
Post by: DF8OE on 10. May 2018, 07:07:54
I must not change or install anything on the following systems:
- Debian 9 stretch 64bit
- LMDE2 (Betsy) 64bit
- Siduction 64bit
- Antergos 64bit
Everything worked out-of-the-box. Sound is in "48KHz".
No need for a special codec, and samplerate is correctly submitted via USB descriptors.
There is no need for pulse audio or any other mixer. You can set the sound card directly in the applications. Some applications (like WSJTX 1.6.x) are buggy and do not accept USB descriptors - so same error messages as you wrote. But if you take the newest debs from the websites (or build the applications by yourself) everything works fine.
vy 73
Andreas
|
Title: Re:UI-Board und Linux
Post by: peter_77 on 10. May 2018, 09:53:08
Yepp, same here.
Everything out of the box. Debian as well as Rasbian. Just a few clicks in the audio settings to select the right interfaces and thats it.
|
Title: Re:UI-Board und Linux
Post by: DB4PLE on 10. May 2018, 10:33:37
Hi,
since I upgraded to Ubuntu 17.10 I was not able to get WSJTX to work correctly, same issue as VE3LL. All tricks I tried did not work. Older WSJTX, new WSJTX, ... could not get it to work. Worked flawlessy just before upgrade (with Ubuntu 16.04, 17.04) on same machine.
TRX has no problems on Windows or with Raspberry Pi. FLDIGI works AFAIR.
73
Danilo
|
Title: Re:UI-Board und Linux
Post by: DF8OE on 10. May 2018, 10:35:42
Please help me to get it for testing.
I visit the website (http://www.jtdx.tech/en/) and navigate to JTDX downloads / General releases / Linux Version 64 bit - and get a "404 error".
OK. So I navigate to "Evaluation Versions only" / Linux version 64 bit - and get a debian package which is named "amd64". But it contains only i386 version which needs a lot of additional 32 bit stuff which I do not want to have on my 64 bit machine. It is not recommended to install 32 bit versions on 64 bit machines - it is risky that you are missing some libs (tools which are not in the dependencies (app will start but not work properly).
Where can I get a 64 bit version of JTDX?? And - very important question: where can I find sources of JTDX - they **MUST** be accessible because the base "WSJTX" is Gnu-GPLv3!
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: DF8OE on 10. May 2018, 12:36:06
Maybe it is related to Ubuntu and its strange "Canoncal way of moving". I left Ubuntu about 10 years ago and now I am happy about my decision. Canonical does have joint venture with Microsoft... I have dreams what this can mean ($$$...) and what is moving on the next time in Ubuntu...
Canonical has done many "lonely" moves in its distributions the last years. It is ignoring community and the orientation of the base Debian. Most impacts where graphic drivers and integration, Canonicals "own desktop" and maybe now its impacting audio chain. Don't know that. And I do not want to setup a machine using Ubuntu to investigate.
But actually I cannot access any JTDX 64 bit version package nor the sources to build it by myself.
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: DB4PLE on 10. May 2018, 13:08:02
Hi,
I think it is a combination of issues. Today I upgraded to Ubuntu 18.04 and it now works again (sort of). I can again transmit and also receive. However, I receive only "silence". When I switch to Digial IQ I can see that some sound is send out but also very low volume. And external volume control does not work at all in Ubuntu 18.04.
All of this is different from Ubuntu 17.10 where I got error messages when I tried to start WSJTX. Now I just don't get any sound data. This problem may be an interaction problem between Linux USB sound driver and our UHSDR sound driver code. As with some other issues, maybe Linux kernel has a changed handling, more standard compliant handling in this area and we are not so compliant. Will look into this. However, what the problem on 17.10 was I have no clue.
73
Danilo
|
Title: Re:UI-Board und Linux
Post by: DF8OE on 10. May 2018, 14:19:52
It cannot be Linux kernel issue at all. I am using Linux kernels 4.15 and 4.16 on all my machines.
But - as I already stated - Ubuntu (Canonical) Kernels are not standard kernels! Canonical added many "homebrew" and instable kernel modules in the past. This modules never ahve reached "official" kernels which are used by most distributions.
Canonical wanted to press their "Unity" desktop in the market and dreamt of an "Ubuntu phone" which runs Unity, too. So they added many inofficial drivers (modules) to their kernels. Most of them are not working, impact othe functions, slow down kernel by eating horse power without doing anything (useful).
I am nearly sure if you debug on command line you can fix it. But Ubuntu is moving away from the Linux community and that is the reason I don't want to spend time there.
Is there a possibility to take kernels from external sources (ppa's) that are much cleaner?
vy 73
Andreas |
Title: Re:UI-Board und Linux
Post by: DF8OE on 10. May 2018, 14:41:00
Update:
I was successful in finding the sources and a real 64 bit version in the "release notes". After installing it worked flawlessly like WSJTX. So I can state that it is an Ubuntu problem.
I do not know which audio source you are using - it is recommended to use the devices which start with "plughw:"
It can (and will) differ at your working space but here the device for "Input" is named:
plughw:CARD=U40SDR,DEV=1
and for Output:
plughw:CARD=U40SDR,DEV=0
Here the output of aplay -l when OVI40 is attached:
Code:
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: NVidia [HDA NVidia], Gerät 0: ALC883 Analog [ALC883 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: NVidia [HDA NVidia], Gerät 1: ALC883 Digital [ALC883 Digital]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 2: U40SDR [USB Interface 40SDR], Gerät 0: USB Audio [USB Audio]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
|
|
If you are using mcHF (or sparrow) your string is "mcHF" instead off "40SDR".
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|