Title: [gelöst] USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 12. February 2018, 08:36:34
Hallo Freunde
Seit Längerem erfreue ich mich einer gut funktionierenden Firmware und das bis zur Version 2.7.82 (Mit Grossschrift). Ab Version 2.7.83 sehe ich wieder das schon zweimal gehabte Problem beim laden der Treiber für Cat (Comport) und der korrekten Installation der Audio Treibern über USB . Das wie schon zweimal gehabt. Grund: Speicher oder was auch immer. Also genau wieder dasselbe Übel. Lässt sich da vielleicht etwas machen, denn ich liebe die neue Grossschrift Frequenzanzeige? Für Tests stehe ich gerne zur Verfügung.
73 Chris
|
Title: Re:USB Treiber Probleme ab v2.7.83
Post by: DF8OE on 12. February 2018, 14:12:17
Das ist garantiert wieder ein "out-of-RAM"...
Bitte schreib einen Issue-Bericht auf GitHub - dann sehen das die Programmierer schneller.
EDIT:
Bitte probiert doch mit einer der Versionen ab 2.7.83 bis einschließlich der 2.9.2 mit aus, ob CAT und Audio bei euch noch laufen. Interessant ist vor Allem, was für ein Betriebssystem und was für eine Version ihr benutzt. Wir hatten das schon mal verglichen - die USB-Enumerierung läuft ohne sichtbare Veränderung weiter, aber bei bestimmten (??) Windows-Versionen geht dann nichts mehr - warum auch immer. Ich wrde gerne wissen, welche betroffen sind und welche nicht.
Interessant ist auch, dass ich das mit meinen mcHFs und meinem Linux-System wieder mit keinem Programm reproduzieren kann. Bei mir läuft alles wie vorher, keine Einstellungen sind anders, CAT und Audio funktionieren einfach out-of-the-box.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 16. February 2018, 08:53:55
Danke Andreas,
die letzte Version v2.9.6 arbeitet wieder normal
73 Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 16. February 2018, 10:55:26
Das Problem scheint auch außer Dir niemand zu haben. Oder niemand benutzt CAT - was ich eher für unwahrscheinlich halte.
Wir bewegen uns, was den RAM angeht, aber im Grenzbereich der STM32F40x MCU. Da nützt auch die 1MB Variante nichts. Erst die STM32F427/429/439 bieten etwas mehr RAM (256KB / 192KB). Es steht außer Frage, dass beide Grenzen irgendwann mit weiteren Funktionen (JT65, WSPR, SSTV etc.) überschritten werden. Da ist dann für den mcHF das Ende der Fahnenstange erreicht.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 16. February 2018, 14:26:24
Das glaube ich auch nicht, dass niemand ausser mir Cat benutzt, aber ich benutzte hier seit laengerem diverse Digi Programme, die ich immer gleich aufstarte, und da zeigte es mir sofort den Treiber Fehler. Auch wenn ich der Einzige sein sollt, es konnte diesmal wieder behoben werden und ich komme in den Genuss der Grossschrift und des gut funktionierenden Noisereduction.
Danke Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 16. February 2018, 14:55:46
Wie Du schon richtig schriebst:
Verhaken tun sich nicht die Programme, sondern die Treiber. Und die Programme setzen auf die Treiber auf. Funktionieren die Treiber nicht, funktioniert auch KEIN Programm.
Irgendwas muss bei deinen Treibern im Timing anders sein. Die Enumeration hatten wir ja schon mal verglichen - die ist bei Dir und bei mir absolut identisch. Also kann es nur ein Timingproblem sein. Eines, das offenbar von meinen Linux-Systemen entsprechend durch ein anderes Reaktions-Timing aufgefangen wird, bei Dir aber dieses Auffangen nicht geschieht.
Bei mir ist an allen Fällen, wo bei Dir das Problem aufgetaucht ist, keinerlei Veränderung festzustellen gewesen. Alles lief auf allen Rechnern (alle mit Linux-Betriebssystemen - was anderes kommt "bei mir nicht in die Tüte") problemlos weiter.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 17. February 2018, 00:07:57
Ich verwende ein normales Windos10 32. auf einem Supermicro C7 Board
Digi Programme sind: Mixw2, Fldigi, Multipsk und Ham Radio Delux.
Bei alles diesen Programmen verwende ich USB Connect.
Bei eingestecktem, verbundenem mcHF - zum Rechner mit USB Kabel
werden beim Missverhalten die Audioports oder Comport Nummer, falsch gesetzt. Das ist nicht der Fall wenn es wie jetzt wieder, ich mit v2.9.6 (Mit Grossschrift) arbeite, dann laeuft alles richtig. Bei Missverhalten, sehe ich zwar im Geraete Manager das Port und auch die Audio in/out, aber sie werden nicht richtig angenommen. Thats a fact, und den hatte ich jetzt das dritte mal. Was Du, ihr, dann machtet dass es wieder klappte, weiss ich nicht? Erklaere es mir.
73 Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 17. February 2018, 07:39:50
Hallo Chris,
kannst du bitte mal für eine der problematischen Versionen, also eine Version, bei der das Problem sicher auftrat, den entsprechenden Small Build flashen (den für die MCU < 512K) und berichten, ob das auch beim small build nicht funktioniert.
73
Danilo |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 17. February 2018, 08:44:55
Ich rate mal, dass es an deinem Micro C7 Board liegt. Ich habe mal versucht, auf so einem "tollen neuen Gerät" ein Linux System zu installieren. Ganz davon abgesehen, dass es mir das UEFI mit dem nicht abschaltbaren security Boot fast unmöglich gemacht hat da ein Linux draufzukriegen lief nach etlichen Versuchen auch nur ein speziell gepatchtes Ubuntu. Die Hardware ist dort (gelinde gesagt) sehr eigenwillig und hat mit den normalen Kerneltreibern nicht richtig funktioniert. Es hat zwar funktioniert - aber eben nicht richtig. Hat sich aufgehängt, war an Stellen zäh, wenn ich was ganz anderes aktiviert habe (z.B. hakte die Grafik nach dem Einstecken eines USB-Sticks).
Mich würde wirklich brennend interessieren, ob mit den benannten Versionen, die bei Dir den Bug haben, auch andere mit Windows-Systemen einen Fehler reproduzieren können. Das ist natürlich alles kein Beweis - alles was ich geschrieben habe ist reines Bauchgefühl - und die negativen Erfahrungen mit diesen modernen Tabs kommen aus meinem Berufsalltag.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 17. February 2018, 08:50:24
Hi Andreas,
wenn es dass C7 board ist, warum ändern dann unterschiedliche UHSDR Firmware releases dass Verhalten, obwohl in keiner von den Releases Änderung am CAT gemacht wurden? Am C7 Board und Windows 10 sind ja keine Veränderungen vorgenommen worden.
Also ich würde da schon eher der das Problem liegt auf Seiten des Speicher beim mcHF sei. Wir schauen mal, was der Test mit dem Small Build bringt, der ja nicht nur weniger Flashbedarf sondern eben auch den RAM Bedarf von FreeDV nicht hat. Damit ist hier auch mehr "Platz".
73
Danilo |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 17. February 2018, 09:11:46
Hallo
Andeas,such doch den Fehler nicht immer bei mir. Ich berichte nur Tatsachen und kann Dir sagen, dass es mit anders Pc's dasselbe ist, es auch nicht funktioniert, ich habe 5 Syteme hier. Ihr habt mich mal gefragt euch zu melden wenn es wieder auftaucht, das habe ich gemacht. Dann wurde es wieder behoben, wie? Also!
Hallo Danilo
Du hast die richtigen Fragen gestellt. Irgendwie hanegt es mit der Speichegroesse zusammen. Ich stellet fest das ich ab FW v2.7.85 und spaeter das alte Treiber Problem wie vorgaengig beschrieben wieder auftrat, und zwar nur mit dem grossen File Size 464Kb. Dann versuchte ich es mit der 512 Version, also kleinern File. Das funktionierte OK.
Das ging dann so bis ich die Version v2.9.6 (Grossen File) versuchte. Bingo es war wieder in Ordnung. Aber File Size jetzt 451KB anstatt 464Kb. Die 512 Versionen gingen immer auch auf einem mcHF mit nur 512KB Flash Size.
Der Problem zeigt sich immer so, dass voreingestellte Werte des Comports und der Audio Adressen nicht mehre richtig eingetragen werden, was bei den gut funktionierenden Versionen nicht der Fall ist.
Macht es noch Sinn, dass ich weiter Berichte, wenn der schwarze Peter immer mir zugeschoben wird, aber dann das Problem doch irgebwie geloest wurde.
Danke Danilo |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 17. February 2018, 09:31:52
Es gibt keine "schwarzen Peter" - nur Ursachen und Wirkungen.
Und da alle Versionen bei mir laufen, möchte ich einfach nur die Ursachen verstehen. Chris, würdest Du dabei helfen?
Du hattest das ja schon mal getan indem wir unsere USB Descriptoren verglichen haben. Ich meine mit lsusb ausgelesen, Du deine mit einem Windows-Tool. Ergebnis: bei beiden PCs exakt dasselbe.
Woran liegt es also, dass es auf dem einen PC läuft und auf einem anderen nicht - wobei bei beiden mcHFs der gleiche knappe Speicher vorliegt???
Das würde ich gerne verstehen! Und auch, warum sich sonst wirklich noch NIEMAND gemeldet hat, der das ebenfalls beobachtet hat.
EDIT:
Meine erste Vermutung ist und war, dass es ein Betriebssystem - spezifisches Verhalten ist. Das ließe sich ganz leicht feststellen - aber nicht von mir, da ich keinen einzigen PC mit Windows besitze. Bislang weder Bestätigungen, dass es mit einem anderen Windows-PC läuft oder eben auch nicht.
@Danilo:
Meine "Verdacht ins Blaue" ist dass sich durch den knapper werdenden Speicher das Timing verändert. Die Hardware anderer Windows-PCs oder Versionen können das genauso wie Linux auffangen - das Gerät von Chris nicht. Das kann durchaus ein Hardwareproblem sein. Es ist auch möglich, dass das Timing unseres USB-Ports dann out-of-specs ist, aber eben auf fast allen Geräten noch als korrekt erkannt wird.
Wobei der letzte Post von Chris, dass es bei ihm auf fünf PCs auftrat, diese Vermutung wieder über den Haufen wirft. Und ein noch größeres Fragezeichen aufleuchten lässt: Warum tritt es bei einem bei 5 PCs auf und sonst hat diesen Bug noch niemand gehabt?
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 17. February 2018, 10:10:56
Hallo Andreas,
@Danilo:
Meine "Verdacht ins Blaue" ist dass sich durch den knapper werdenden Speicher das Timing verändert. Die Hardware anderer Windows-Maschinen oder Versionen können das genauso wie Linux auffangen - das Gerät con Chris nicht. Das kann durchaus ein Hardwareproblem sein. Es ist auch möglich, dass das Timing unseres USB-Ports dann out-of-specs ist, aber eben auf fast allen Geräten noch als korrekt erkannt wird.
|
|
UHSDR: Das Zeitverhalten der Firmware verändert sich nicht, wenn der RAM Speicher knapper wird, es ist davon völlig unabhängig. Diese Theorie bringt uns nicht weiter.
Natürlich ist bei einem Multitaskingsystem wie Windows oder Linux das Zeitverhalten des USB Stacks variabel, und dadurch ergeben sich auch leicht andere Abläufe im UHSDR, aber wir hatten es hier ja mit einem systematisch, reproduzierbaren Fehler zu tun, der über die UHSDR Releases auftritt oder nicht, deswegen gehe ich erstmal nicht von einer Problemursache(!) auf Windows-Seite aus (wobei die Nutzung von Windows schon eine Rolle beim Auftreten des Fehlers haben kann, die eigentliche Ursache ist Windows aber nicht).
Wenn also der Fehler bei einer Firmware mit kleinerem RAM Bedarf (die Small-Builds brauchen nicht nur weniger Flash sondern belegen auch ca. 40k weniger RAM mit Daten, wg. Nichtnutzung FreeDV) nicht auftritt, bei einer ansonsten identischen Release mit FreeDV aber schon, liegt der Verdacht nahe, dass der Füllgrad des RAMs eine Rolle spielt.
Eine (!) mögliche Erklärung:
Hier kommt zum Tragen, wie der Speicher verwendet wird. In dem betreffenden RAM Bereich wird eine bestimmte Menge Speicher durch Daten belegt, und zwar vom Anfang des Bereichs bis zu einem bestimmten Punkt. Dieser Punkt wird durch den verwendeten Programmcode (globale und statische Daten plus über malloc belegte Daten bestimmt). Am Ende liegt übrigens der FreeDV Speicher (da dynamisch nach dem Programmstart belegt). Vom Ende dieses RAM-Bereichs her kommt der Stack, auf dem temporär je nach aufrufenen Funktionen zusätzlich Speicher belegt wird. Wenn dieser Stackbereich in den anderen Bereich reinwächst (oder umgekehrt), dann kommt es zur Zerstörung von Daten des Stacks, das kann komische Folgen haben. Die Stackbelegung ist hochdynamisch und daher durchaus zeitabhängig, d.h. je nach dem z.B. wann exakt der PC seine USB Kommandos schickt, kann bei 2 verschiedenen Systeme eine Überlappung auftreten oder nicht, oder keine sichtbaren Folgen haben.
Bisher wurde dieses Phänomen nur von wenigen beobachtet, aber alle Maschinen AFAIR 192k Maschinen, bei denen die Gefahr der Überlappung sehr viel höher ist, da wir hier fast 100% Auslastung des Speichers haben. Als ich den FreeDV gemacht habe, sind mir solche Effekt sehr wohl aufgefallen und ich konnte sie nachweisen durch Inspektion des Speichers mit dem ST-Link.
Und wenn wir uns die Unterschiede in der Speicherbelegung der Versionen anschauen, und das mit den Versionsnummern korrelieren, die Chris uns geliefert hat, glaube ich zu erkennen, das wir dort immer Sprünge nach oben in der Auslastung hatten und durch Reduktion die Sache wieder in Griff bekommen. Das ist schlecht, hängt aber mit der RAM Knappheit zusammen.
Eine einfache Lösung dafür gibt es nicht. Würden wir allen Speicher statisch belegen (und damit die Stacknutzung minimieren), würden wir soviel Speicher belegen, das wir nicht mit 192k auskommen. Wir könnten natürlich permanent prüfen, ob eine Überlappung auftritt. Da der Prozessor uns aber nicht freiwillig verrät, was der maximal Wert seinen Stacks war, ist das praktisch so nicht umsetzbar. Was man machen könnte, ist eine Schutzzone zwischen Stack und Speicher zu legen (ein sogenanntes "Canary"-Konzept, vom Kanarienvogel, der früher in Bergwerken zum Erkennen von gefährlichen Gasen eingesetzt wurde). Damit können wir erkennen, ob der Stack in diesen Bereich vorgedrungen ist. Das werde ich mal andenken.
Aber es gibt da noch viele andere mögliche Ursachen, die aus Programmierfehlern resultieren könnten.
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 17. February 2018, 10:24:57
Mir muss niemand helfen, die neueste FW v2.9.6 laufen nun wieder mit grossem oder kleinen Filesize. Bei mir ist der mcHF ein Arbeitgeraet, was ueber USB mit dem Rechner verbunden ist. Wenn dann aber bei einer neu geladenen FW es nicht mehr funktioniert, schaue ich genauer hin. Immer zuerst bei mir, eben auch mit auf anderen Rechnern und wenn sich dann das gleiche Problem zeigt, gelange ich an euch. Einfach weil die vorgegeben Konfiguration die bis jetzt anstandslos lief, nicht mehr ging. Ob andere das Probelm nicht haben bezweifle ich. Aber die Voraussetzungen sollten identisch sein, naemlich als Arbeitsgeraet nicht als Testversuch. Bei mir befinden sich 6 verschiedene SDR Transceiver, inkl. dem Icom7300, der sich fast identisch aufsetzen laesst wie der mcHF, aber immer mit derselben FW.
Nur nochmal, eine Frage? Warum ging es mit v2.7.85 nicht Filesize 464kb, aber dann wieder mit v2.9.6 bestens, Filesize 451kb. Das ist nur eine Frage.
Es geht mir auch nicht darum wer recht hat oder nicht, sonder um wiederholbare Tatsachen, auf verschiedenen Rechnern. Ich hatte mal ein aehnliches Probelm mit einem renomierten SDR Trasnceiver Hersteller, wo ich auch als einziger eine Problem fand oder erkannte.
Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 17. February 2018, 10:39:40
Das hat nichts mit dem Flash zu tun (oder mit der Filesize, die Du sehen kannst), sondern mit der Auslastung des internen RAMs der MCU des mcHF. Die dort vorhandenen 192KB sind nahezu aufgebraucht, wenn man FreeDV mit im Boot hat. Bei der für die kleinen MCU gebauten Firmware ist FreeDV nicht mit dabei - deswegen ist der RAM-Verbrauch niedriger.
Wie Danilo schon sagte, kann man den RAM-Verbrauch nicht 100% sicher bestimmen. Es gibt Dinge in der MCU, die werden dynamisch belegt, wie z.B. der Stack. Da kann es dann schon mal sein, dass, wenn irgendwas in irgendeinem Timing anders ist, der Stack unterschiedlich groß ist. Und dieser Unterschied von ein paar Bytes kann über funktionieren und nichtfunktionieren entscheiden.
Es kann auf jeden Fall keine generelle Überlappung sein - dann dürfte es auch unter Linux nicht mehr funktionieren. Es muss irgendwas sein, was im Zusammenspiel mit (EDIT: deiner Konfiguration von/mit) Windows auftritt.
Klar: wenn wir genügend RAM frei haben ist das Problem weg. Aber wir werden bei der 192KB MCU niemals mehr "genügend RAM" (EDIT: nach dem Motto: "don't worry be happy") frei haben - wir müssen mit dem Leben, was da ist. Also muss man auch die andere Seite anschauen. Vielleicht liegt es ja an einer bestimmten Windows-Version? Oder an einer bestimmten STM- oder Audio-Treiberversion?
Wir brauchen mehr Berichte, ob und wenn unter welchen Kombinationen der Fehler auftritt! Durchaus möglich, dass er weg wäre, wennn Du eine andere Treiberversion wählst. ABER: das sollte man erst tun, wenn da auch genügend Feedback hintersteht, dass das was bringt.
Wir haben einfach NULL Rückmeldungen (außer deiner) zu diesem Problem - und damit ist ein eventueller Workaround nicht zusammenzunageln.
EDIT:
Und dass das mit der 6er-Version wieder ging lag daran, dass Danilo in Sachen RAM-Verbrauch unabhängig von deiner Fehlermeldung den uralt-Code von Chris/Clint, aber auch unseren nach zu großzügig belegtem Speicher durchforstet hat und ein paar Dinge verbessert hat. Dadurch haben wir wieder wenige Kilobyte frei. Aber selbst so ein Feature wie ein größerer Font verschlingen auch RAM (im Betrieb). Wir kratzen an dieser Grenze schon länger.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF9PV on 17. February 2018, 11:21:04
Halllo zusammen,
nachdem ich von den Schittstellenproblemen hier gelesen habe musste ich auch mal wieder den mcHF mit FLdigi verheiraten und testen. Winblöd 10 64 läuft hier und der 0,4er mcHF mit noch kl. Prozessor 512 kb.
Alles wie gewohnt FT8 und WSPR klappt nachdem erst 12 khz Versatz in der TX Freq. vorlag.
Ein paar Versuche und irgendwie nach einigem Abspeichern klappt es. Andreas hat mich auch
gerade geloggt in WSPR. Habe ca. 2 m USB-Kabel was eigentlich zu lang ist dran.
115 Kbit Schnittstellengeschwindigkeit.
73 und Grüße aus Neuwied
DF9PV Franz K08 |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 17. February 2018, 11:21:39
Hallo Chris,
wenn es die Speicherüberlappung ist, kann jede Änderung am Code zu mehr, gleichem oder weniger Verbrauch führen. Wenn man jetzt scharf an der Grenze zwischen passt und passt nicht ist, sind schon kleinste Änderungen wirksam. So kann es zwischen jeder Release alternierendes Verhalten geben.
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 17. February 2018, 11:27:59
Hallo Franz,
wenn Du uns helfen möchtest, probiere das Ganze bitte nochmal mit der Firmwareversion 2.7.83 durch. Du findest sie im Archiv. Und schreib bitte dazu, ob Du die 512KB Version oder den "full build" nutzt.
Damit hätten wir endlich einen zweiten Bericht - egal, wie der ausfällt. Ohne Input geht hier gar nichts.
EDITEDIT:
Hab gerade nochmal gelesen und gesehen, dass Du den kleinen Prozessor hast - also ohne FreeDV nutzt. Das nützt uns leider nichts: denn damit tritt das Problem nicht auf :'(
Wir brauchen Testberichte mit der MCU mit 1MB Flash und 192KB RAM.
EDIT:
Meine "Traum" wäre es, wenn es bei Dir geht - was es bei Chris nicht tat. Und wenn wir dann feststellen, dass Chris z.B. einen anderen STM-Treiber nutzt. Und es dann bei ihm auch mit der 2.7.83 geht, wenn er den gleichen Treiber nimmt wie Du. Weil durch ein geändertes Timing einfach der Stack im mcHF nicht so weit anwächst. Wir wissen nicht, wie weit er anwächst (und ob es überhaupt der Stack ist - das ist aber die wahrscheinlichste Begründung). Nur wenn es mit einem "besseren" Treiber zu lösen wäre, dann... Hoffnung schöpfe ich daraus, dass es in den bisher von Dir gemeldeten drei Fällen mit meinem Linux-System in allen Fällen nach wie vor noch einwandfrei lief.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF9PV on 17. February 2018, 11:57:49
Hallo Andreas,
ja 2.7.83 jetzt aufgespielt kleine Version große ist schon zu groß. Alles geht.
WSJT-X lief auf Anhieb. Ein kleiner Fehler kam Audio Input war einmal weg, aber
nach Neustart von WSJT-X alles gut.
Habe ein Foto der Treiber ID angehängt.
73 Franz
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 17. February 2018, 13:57:09
Kleine Version lief bei mir immer, die Grosse wie erwaehnt.
Bleiben wir bei den Tatsachen.
Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 17. February 2018, 14:33:34
Full Ack.
Wir brauchen Testberichte von:
- Firmware 2.7.83, full build
- auf dem mcHF, MCU mit 1MB Flash und 192KB RAM
bezüglich der einwandfreien Funktion oder auch Nichtfunktion von
CAT und USB Audio
unter Angabe folgender Testparameter:
- Betriebssystem und Version
- getestete Programme (z.B. fldigi, WSJT-X etc.)
- Treiberversion für die COM und Audioschnittstelle
Und das ist genau das, was ich mit dem Start dieses Threads eigentlich bewirken wollte. Bislang leider ohne Echo...
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 18. February 2018, 09:53:34
Mein letzter Bericht !
System 1: Windows10 32, C7 Supermicro Board, SSD
System 2: Windows10 64, Acer Notenook, SSD
Digi Programs: Mixw2, v2.18, FLdigi v4.0.12
Transceivers: 4 Verschiedene mcHF’s. 3 mit 1024kb Flash Size, 1 mit 512kb Flash Size
Getestet wurde mit grossem FW File (Grossschrift Version) wie auch mit kleiner Version.
Die kleine FW Version (264kb) Funktioniert immer.
Das Problem entsteht mit der grossen FW Version auf den 1024kb Transceivern.
Computer mit mcHF über USB Kabel fest verbunden
Einschalt Reihenfolge:
Computer AN Desktop erscheint. Dann erst mcHF AN (Wichtig) mit USB Kabel schon verbunden. Das einschalten des mcHF wird gehört.
Dann auf dem Desktop Mixw oder FLDigi starten.
System bereit !
Diese obige Reihenfolge funktioniert einwandfrei bis und mit FW v2.7.82 und dann erst wieder ab FW v2.7.93.
Die dazwischen liegenden Versionen setzen Comport4 nicht in den jeweiligen Digi Programmen Mixw oder FLdigi. Ich kann sie zwar mit etwas Mühe setzen, aber beim nächsten Einschalt Prozess kommt wieder die Fehlermeldung Comport nicht gefunden, auch wenn er im Geräte Manager in Windows10 gesetzt ist. Wie auch die USB Audio Ports.
Dies ist der Fall auf zwei komplett verschiedenen Computern.
Das Missverhalten der Erwähnten FW Versionen v2.7.83 – v2.7.97 verhindert also das richtige setzen Treiberdaten in die jeweiligen Digi Programmen.
Dies war auch schon bei viel frühern FW Versionen der Fall und konnte jeweils durch die Software Autoren behoben werden.
Ich suchte den Fehler immer eingehend zuerst auf meiner Seite und gelangte erst dann ins Forum, was aus dem Schriftwechsel ersichtlich ist.
Meine Frage: Wie wurden jeweils die Probleme behoben dass nach meinen Meldungen
alles wieder zu vollsten Zufriedenheit lief.
Denn schon bei meiner ersten Meldung im letzten Jahr, wurde auf die Speicherknappheit hingewiesen, dann aber jede Menge gute Features zusätzlich eingebaut?
Ich liebe und schätze das Programm und die dahinter liegende Arbeit sehr und melde mich erst bei Unregelmässigkeiten.
Es ist äusserst wichtig beim nachvollziehen dieses Problems die Startreihenfolge einzuhalten, ebenso die die System Anordnung, ansonsten kein Vergleich zustande kommt.
73 Chris
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 18. February 2018, 10:13:03
Hallo Chris,
danke für deinen ausführlichen Bericht.
Ich möchte für mich zwei erkenntliche Fragen / Probleme beantworten:
1) Einschaltreihenfolge
Bitte nimm es nicht übel: die Reihenfolge des "Einstöpselns" bzw. Anschaltens ist bei jedem individuell. Auch verwendet jeder andere Programme. Dementsprechend halte ich die Bedingung, dass genau auf diese Weise getestet werden soll/muss, nicht für zielführend. Die Problematik scheint ja bei Dir zu sein, dass der Com-Port bzw. der Ausio-Port nicht mehr zuverlässig zuzuweisen bzw. anzusprechen sind. Das ist das Paoblem - und dazu brauchen wir Testberichte.
2) Speicherknappheit
Die Speicherknappheit hat im Prinzip begonnen, als wir FreeDV eingebaut haben. Schon damals war das nur mit Klimmzügen und viel Aufräumen möglich. Seit dem tag ist ein weiteres Implementieren von irgendwas, was RAM braucht, mit einem gleichzeitigen Aufräumen an anderer Stelle verbunden, sonst passt es nicht mehr. Glücklicherweise sind bei vielen neuen Implementierungen (neuer NR...) gleichzeitig die alten Funktionen entfallen und somit schwappen wir immer wenige Millimeter unter dem Maximum. Und das kann sich in Zukunft nicht zum Besseren ändern ::). Eine gewisse Entspannung bringt der Wechsel der MCU zur 256KB Version (427/429/439). Die "richtig speicherhungrigen Funktionen" wie standalone SSTV, WSPR, JT65 wird es aber nur auf dem OVI40 geben können, weil nur dort die nötige Menge an RAM vorhanden ist.
Deswegen sind Fehlermeldungen wie Du sie machst auch sehr wichtig. Es wäre nur schön und wünschenswert, wenn sich daraus sowas wie eine "kleine Forscher- und Interessengruppe" aus all denen bildet, die das gleiche Problem haben. Denn es ist mit Sicherheit ein Problem, das von mehreren Stellen aus gelöst / umschifft werden kann. Es gibt Dinge, die kann man nicht ändern: man kann der 405/407 MCU nicht mehr als 192KB Speicher gönnen. Und wenn es durch irgendwas anderes gemildert werden könnte (siehe das, was ich in vielen vorherigen Posts bereits geschrieben habe), dann wäre ja auch geholfen. Leider hat sich eine solche Gruppe mangels Interesse (oder es gibt halt bei niemand anderem das Problem) noch nicht gebildet.
Bislang hat es immer gereicht, wenn ich etwas bissig geschrieben habe, dass das Problem wohl niemand anders hat: dann kamen die Meldungen doch. Hier hat das leider nicht gewirkt: Schweigen im Walde.
Ich habe auf jeden Fall auch wieder einen mcHF mit 407er MCU mit !MB Flash zum Testen und kann das von Dir beschriebene Problem mit keinem meiner PCs nachstellen. Meine Programme (fldigi, QSSTV, WSJTX, Quisk) laufen alle ohne Probleme über die "Grenze" von der 82 zur 83 und weiter hinweg. Keine Einstellung muss geändert werden, es gibt keine Fehlfunktion. Das beweist, dass es auf jedenFall möglich ist, auch mit der "fehlerhaften" Firmwareversion ohne Einschränkungen mit CAT/USB-Audio arbeiten zu können. Nur fehlt zur Zeit mangels Mitarbeit anderer die Möglichkeit, das für andere PC/Softwarekonfigurationen als die Deine und die meine, herauszuarbeiten.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 18. February 2018, 10:54:46
Andreas,
vielleicht solltest Du etwas weniger bissig Antworten und Berichte genau lesen. Es kann jeder machen was er will. Ich bin Benutzer und habe festgestellt dass alles so wie von mir beschrieben prima laeuft und wenn dann Abweichungen sind, reagiere. Das ist ja Hilfe fuer euch, aber evt. braucht ihr das gar nicht? Schade, Schuldzuweisungen an ander habt ihr doch gar nicht noetig. Aber der Dialog sollte freundlich und ruhig gefuehrt werden, und auch wahrgenommen werden, ohne dass sich der Meldende noch rechtfertigen oder verdeitigen muss fuer was er schrieb.
Danke an Euch alle, ich werde mich ab jetzt nicht mehr melden, ist ja sinnlos,
Keiner hat mir bis jetzt meine mehrmals gestellte Frage beantwortet, warum es dann ploetzlich wieder besten lief, wie z.B von v2.7.92 zu v2.7.93. Was wurde gemacht????
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 18. February 2018, 11:06:19
N*I*C*H*T*S konkret auf dein Problem hin. Es wurden, wie das fast täglich gemacht wird, neue Features eingebaut, alte Dinge entfernt oder reworked. Mehr nicht!
Schade, dass ich bissig werden muss. Lies bitte die Posts genau und ohne dass Du Dich angegriffen fühlst durch. Dann wirst Du von Danilo in einem Post auch lesen, dass bei diesem Problem schon das Ändern einer einzigen Zeile Programmcode, die absolut nichts mit CAT zu tun hat, dazu führen kann, dass es bei Dir läuft oder auch nicht läuft.
Bitte versuche die Sachlichkeit meiner Fehleranalyse zu verstehen. Und bleib nicht verbohrt auf "Deiner Einschaltreihenfolge" und schließe nicht kategorisch aus, dass das Problem vielleicht auch durch eine Änderung deiner Konfiguration zu lösen sein könnte. Wenn Du das kategorisch ausschließt, brauchen wir gar nicht erst weiterzusuchen. Und solange niemand anders hier mithilft, kommen wir auch nicht weiter.
EDIT:
Solange sich keine weiteren Berichte (egal ob positiv oder negativ) hierzu zeigen werde zumindest ich nur abwarten. Natürlich sind wir immer bemüht, den Speicherbedarf so niedrig wie möglich zu halten. Da wir aber bereits an der Schwelle des "passt nicht" sind kann es täglich passieren, dass das Problem nochmal auftaucht. Wenn der Speichermangel nicht zu heftig ist, werde ich das hier nicht merken (habe ich ja bislang noch nie). Aber Du (war ja schon mehrfach so). Dann kannst Du zur Zeit nur melden und wenn es nicht (wie diesmal) zufällig durch irgendeinen anderen Rework sowieso wieder funktioniert kann ja geschaut werden, ob man irgendwo noch ein paar Byte RAM einsparen kann. Insofern bist Du der von Danilo beschriebene "canary". Deine Zusammenstellung scheint den internen RAM-Verbrauch des mcHF etwas ansteigen zu lassen, wodurch es dies Speicherüberschneidungen gibt. Und dann zeigen sich bei Dir Fehler. Wird jetzt der allgemeine Speicherbedarf im mcHF noch etwas größer, werden die Fehler bei allen auftreten - dann geht CAT gar nicht mehr, und dann besteht akuter Handlungsbedarf. In der "Grauzone" kann man durch eine Änderung an anderer Stelle vielleicht noch was machen - vielleicht auch durch eine etwas weniger heftigere Änderung als den Ersatz von Windows durch Linux (das würde helfen - das haben wir schon festgestellt). Ob es was anderes gibt oder nicht kann man nur mit mehr Mittestern herausfinden.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 18. February 2018, 12:10:43
Hallo Chris,
Keiner hat mir bis jetzt meine mehrmals gestellte Frage beantwortet, warum es dann ploetzlich wieder besten lief, wie z.B von v2.7.92 zu v2.7.93. Was wurde gemacht????
|
|
Genau diese Frage wurde mehrfach beantwortet, aber offenkundig nicht so, dass die Antwort für Dich erkennbar/verständlich war.
Also: Wir kennen die genaue Ursache deiner CAT Probleme nicht. Es gibt eine begründete Vermutung, dass die Probleme mit einer zu hohen Auslastung des RAM Speichers zu tun hat, bei der dann sich Bereiche im Speicher überlappen, die das eigentlich nicht dürfen. Dadurch kann es zu den von Dir beobachtbaren Fehlfunktionen kommen. Und das kann auch reproduzierbar sein (ist es ja bei Dir).
Diese o.g. Vermutung stützt sich darauf, das bei Versionen, die bei dir nicht mehr gingen, Änderungen vorgenommen wurde, die mehr Speicher verbrauchen. Und bei Versionen, die dann wieder gingen, wurde der Speicherverbrauch in die andere Richtung geändert wurde.
Das kann man nur die Analyse der Änderungen im GitHub rausfinden. Das sieht dann so aus:
https://github.com/df8oe/UHSDR/compare/316404897d80d0c7c37eabd75c6902e2571140b3...c1c50e67d4ee2e2ee893862421109766ee0ecf89 (https://github.com/df8oe/UHSDR/compare/316404897d80d0c7c37eabd75c6902e2571140b3...c1c50e67d4ee2e2ee893862421109766ee0ecf89)
Das ist der Unterschied von 2.7.80 zu 2.7.82. Dort sieht man, wenn man genau hinschaut, dass in audio_nr.h Änderungen erfolgen, die mehr Speicherbedarf ergeben. Wenn man dann noch weiter gräbt, findet man raus, ob der Mehrbedarf an Speicher im problematischen Speicherbereich ist oder in einem anderen Speicherbereich. Und daraus kann man schlussfolgern, das möglicherweise der hier deutlich erhöhte Speicherbedarf im ungünstigen Bereich zu den von Dir beobachteten Problem führt.
In der Folge wurden dann eine Reihe von Änderungen vorgenommen, die den Speicherbedarf wieder reduzieren, ich erspare uns mal die Codeanalyse. Und irgendwann kommen wir dann offensichtlich wieder unter die Grenze, wo es problemlos funktioniert.
Das war dann offensichtlich 2.7.93. Und irgendwann schlägt das Pendel wieder in die andere Richtung, denn Mehrfunktion gibt es in der Regel nicht ohne zusätzlichen Speicherbedarf. Es ist recht mühsame Arbeit, die gleiche Aufgabe dann mit weniger Speicherverbrauch umzusetzen oder bestimmte Funktionen auszubauen, sodass wieder etwas frei wird.
Besser werde ich deine Frage nicht beantworten können, ohne noch viel mehr erklären zu müssen. Also sollten wir es dabei belassen. Oder jemand anders kann das besser als ich.
73
Danilo |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 18. February 2018, 13:31:39
Eins möchte ich doch noch dazu schreiben, weil mir etwas daran liegt, weiterzukommen - vielleicht motiviert das ja den einen oder anderen, bei dem es läuft, hier mitzuhelfen.
Genau in dem Bereich der Firmwareversionen die bei Dir, Chris, nicht laufen, liegt unsere "stable release 2.8.0". Ich bin mir sicher, dass die bei sehr vielen - gerade aus der Yahoo-Gruppe - installiert wurde und im täglichen Einsatz ist. Dort folgt man wesentlich intensiver dem Gedanken "stable releases müssen stabiler sein als andere Versionen - also bleiben wir bei der stable bis die nächste stable rauskommt".
Es gibt aber seit die stable in freier Wildbahn ist keine einzige Meldung oder gar einen Aufschrei der Empörung, dass CAT nicht läuft. Ich schreibe zwar nicht mehr in der Yahoo-Gruppe, bekomme aber die Meldungen noch alle.
Wir sind ja irgendwie am Glaskugelreiben, weil es keine andere Möglichkeit gibt als Vermutungen zu folgen.
Also bauen wir unser Gebäude auf Wahrscheinlichkeiten auf und wenn die hinreichend groß sind ziehen wir daraus Schlüsse. Nicht schön - aber Forscher machen es nicht anders.
Wenn ich nun also annehme, dass die 2.8.0 bei sehr vielen installiert ist, und weiter annehme, dass viele diese Version auch mit CAT benutzen, und gemäß dem Verbreitungsgrad von Linux % Windows weiter schliesse, dass es viele User geben muss, die mit der 2.8.0 mit CAT und Windows problemlos arbeiten - dann würde ich einfach nur gerne von so einem User eine Meldung bekommen: "bei mir läuft es". Und dann könnten wir deine Systeme, Chris, mit dem von diesem User vergleichen.
Die Tatsache, dass Du das Problem gleich auf zwei verschiedenen Windows10-Rechnern hast, macht für mich wieder die Wahrscheinlichkeit niedriger, dass es an Windows an sich liegt. Da die Audio-Treiber von Microsoft selbst kommen (es müssen für den mcHF keine installiert werden - oder??) macht auch die Wahscheinlichkeit für die Audio-Treiber als Ursache kleiner.
Aber wenn Du zwei Rechner hast, hast Du höchstwahrscheinlich den gleichen STM-seriell-Treiber auf beiden Maschinen installiert. Ich vermute (Wahrscheinlichkeit...), es könnte an deinem seriellen Treiber liegen. Wenn dort im Timing oder Handshaking etwas anders ist als bei Linux oder einem anderen Windows Treiber (??), dann kann es sein, dass die Verwendung der Treiber, die Du hast, den RAM-Verbrauch im mcHF etwas erhöhen - und damit die Sache kippt.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 18. February 2018, 15:35:32
Hallo Andreas, Chris,
die Spekulation über den "falschen" Windowstreiber ist aus meiner Sicht müssig. STM liefert mindestens ab Vista und neuere Windowsversionen keinen echten Treiber mit, sondern lediglich eine Beschreibungsdatei, die dem offiziellen Windows-Standard-Treiber mitteilt, sich auch für die Geräte mit den STM32 USB Ids zuständig zu erklären. Also ist es sehr, sehr unwahrscheinlich, dass dein Szenario die Problemursache ist. Ich vermute daher eher Einstellungen im mcHF (die bei der gleichen Person durchaus auch ähnlich sein dürften) als Ursache. Aus dem Fehlerbild und der beschriebenen Vorgehensweise läßt sich sogar noch mehr ablesen, vermutlich tritt der Fehler nur auf, wenn man gleich von Anfang an das USB Kabel dran hat mit aktivem Windows PC.
@Chris: Probiere bitte mal mit einer der bekannt problematischen Versionen, ob das Problem auch auftritt, wenn Du das USB Kabel erst verbindest, wenn der mcHF vollständig gestartet ist.
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 18. February 2018, 16:29:22
In der Tat verbinde ich Geräte erst, wenn sie eingeschaltet sind und arbeiten - rein aus Prinzip (Einschaltspikes - "Verschlucker" etc.)
Gute Idee.
Aber da die Treiber für den seriellen Port ja eben per downgeloadeter Datei installiert werden möchte ich das nach wie vor nicht als Problem ausschließen...
Nur irgendwo müssen wir anfangen. Bei "wer wird Millionär" kommt man ohne Ausschlussverfahren auch nicht weit.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 18. February 2018, 18:34:14
Hallo Danilo
Ich wollte eigentlich abschliessen mit der dieser Geschichte.
Gebe Dir aber gerne Antworten auf Deine Fragen. Ich bin ein alter Hase
was anschliessen von Transceivern an Computer betrifft. Hier stehen ein ganze Reihe SDR Transceivern, die je nach Bauart mit dem Computer verbunden sind. Lan, USB, direkt über Audiokabel und Cat. Alles ist hier vorhanden.
Ich arbeite hauptsächlich mit Digimodes jeder Art. Darum auch das grosse Interesse am mcHF der hier vollumfänglich im Einsatz ist. Eben via USB Kabel zum Rechner.
Ich liebe dieses Gerät. Grund, sehr gutes RX Verhalten, leichter Anschluss via USB.
Als ihr die USB/Cat/Audio Implementation machtet, war es so leicht, das Radio zu benutzen.
Alles lief perfekt, bis dann vor einigen Monaten die erste Hürde auftrat, die notwendigen Treiber für Cat und Audio wurden im Digiprogramm nicht mehr eingetragen, obwohl in Win10 vorhanden. Ich denke Du löstest dann das Problem, durch entfernen eines überflüssigen Speichers.
Schon damals verbrachte ich Stunden es hinzu bekommen, mit allen möglichen Einschalt Konfigurationen etc. Nichts half, Du warst dann die Erlösung.
Damals kam ich als reiner Benutzer auf den von mir erwähnten Einschaltmodus, das war nicht einfach Zufall. Ich versuchte es auch, mit eingeschaltendem mcHF, das USB Kabel einzustecken. Falsch, ich musste jedes Mal, entweder Audio oder Catport setzten.
Glaub mir ich versuchte alle möglichen Varianten. Nur meine vorher beschriebene lief stabil und erlaubte mir sofort ohne zusätzlichen Einstellungen zu arbeiten.
Ich war und bin sehr zufrieden, bis dann das leidige Problem wieder auftrat (Beschrieben)
Und das auf zwei Komplet verschiedenen Rechnern. Auch mit verschiednen Programmen.
Und zwar wird einfach der Catport nicht gesetzt. Ich bekomme es hin, bei einem neuen Start ist alles wieder dahin. Ich habe die Vermutung dass es ein Timing Problem beim Laden von Audio und Cat ist. Denn alle Treiber Daten sind in Windows vorhanden.
Für mich ist es egal, jetzt ab v2.7.93 geht’s wieder, aber ich dachte es könnte euch interessieren, allerdings bin ich nicht gerne ein schuldiger Einzelgänger und muss mich dafür noch rechtfertigen. Ich war Jahrzehnte lang in der Forschung tätig und bin mir und auch andern Gegenüber sehr Hartnäckig.
Du warst immer ein sehr kompetenter und zugänglicher Typ und dafür Danke ich Dir.
Ich kann zur Not vorläufig die kleine FW Version benutzen die ging immer, mag aber die Grössere sehr.
Aber mit Deinem frühern Beitrag bezüglich Änderung einer Zeile gebe ich Dir Recht.
Ich hätte noch ein paar wichtige Thematas, aber das lass ich lieber, der Dialog hierzu ist mir zu Gross.
Herzlichen Dank, Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 18. February 2018, 19:15:33
Hallo zusammen,
ich habe diese Diskussion gerade erst gesehen. Hier meine Testreihe:
mchf 0.6
CPU STM32F407VGT6TR (laut BOM-Liste)
FW 2.7.83
Notebook Windows 10 Home Version 1709, Betriebsversionbuild: 16299.248
COM-Treiber 10.0.16299.15
Audio-Treiber 10.0.16299.15
Vorgehen:
TRX aus
USB-Verbindung zu TRX vorhanden
Notebook neu gebootet
TRX eingeschaltet
Gerätemanager meldet "Serielles USB-Gerät an COM4"
Im Gerätemanager tauchen auch die Geräte Lautsprecher/Mikrofon mchf auf
WSJTX gestartet
In File->Settings-Radio überprüft, dass dort COM4 konfiguriert ist
In File->Settings-Audio sind als Input "Mikrofon (USB Interface mchf) und als Output "Lautsprecher (USB Interface mchf) angegeben
Bandumschaktung in WSJTX funktioniert
"Enable TX" aktiviert
"Tune" aktiviert -> sendet, also alles ok
wiederholt mit:
Versionen 2.7.84, 2.7.85, 2.7.86, ... 2.7.92 und 2.9.7
alles ok.
Nach dem Flashen, USB-Neuverbinden und Start von WSJTX erhalte ich die Fehermeldung "RIG-Control Error, Do you want to reconfigure ...". wenn ich dann WSJTX beende, USB kurz trenne und WSJTX neu starte, läuft alles. Ich nehme an, dass beim vorhergehenden Test ein Port nicht geschlossen wurde - also vermutlich ohne Belang.
Was mir aber auch schon bei früheren Versionen aufgefallen ist: Wenn ich WSPR-Betrieb über CAT gemacht hatte und nach Beendigung des WSPR-Programms die Bänder mit Band+ oder Band- durchgehe, ist die Reihenfolge strubbelig:
Wiederholtes Band+ bewirkt:
20m -> 60m -> 40m -> 30m -> 20m -> 17m -> 15m -> 12m -> 10m -> 160m -> 20m
mit Band- geht in der Liste rückwärts. Das bleibt auch so, wenn ich die USB-Verbindung trenne. Nach TRX-Reboot ist alles wieder gut.
Gruß
Peter
, |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 18. February 2018, 20:20:36
Hallo Andreas,
bitte glaube das jetzt einfach mal: das, was man von STM herunterlädt, ist ein Tool, was nichts weiter macht als eine .INF Datei zu installieren. Ehrlich. Im angehängten Bild ist das Ergebnis der Installation des Treibers zu sehen. Es werden 2 mal die gleichen 4 Dateien in jeweils ein Win7 und Win8 Verzeichnis gepackt. Die ersten beiden Dateien dp-inst... sind von Microsoft bereitgestellt Installer von Treibern. Die 3. Datei ist das signierte Zertifikat, damit Windows den Treiber akzeptiert. Und ja, die 4. Datei stmcdc.inf ist der eigentliche Inhalt, und zwar ein Treiberinstallationsbeschreibungsscript. Und da steht nun drin, dass Windows bitte den offiziellen Windows-Treiber nehmen soll, wenn es die STM USB VID/PIDs bei einem USB Device findet.
Wenn Du es nicht glaubst, hilft Dir nur noch das selbst auf einem Windowsrechner auszuprobieren. Viel Spass.
Warten wir doch mal ab, was Chris sagt bezüglich Anstecken nach dem Start.
73
Danilo |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 18. February 2018, 21:27:23
Hallo Peter,
danke für den Report. Hilft leider nicht weiter.
Aber hier kann ich helfen:Was mir aber auch schon bei früheren Versionen aufgefallen ist: Wenn ich WSPR-Betrieb über CAT gemacht hatte und nach Beendigung des WSPR-Programms die Bänder mit Band+ oder Band- durchgehe, ist die Reihenfolge strubbelig:
Wiederholtes Band+ bewirkt:
20m -> 60m -> 40m -> 30m -> 20m -> 17m -> 15m -> 12m -> 10m -> 160m -> 20m
mit Band- geht in der Liste rückwärts. Das bleibt auch so, wenn ich die USB-Verbindung trenne. Nach TRX-Reboot ist alles wieder gut.
|
|
Dazu gab es erstmal längliche Diskussionen im mcHF Forum und nun einen Wikieintrag:
https://github.com/df8oe/UHSDR/wiki/USB-CAT-and-AUDIO-Mode#please-read-understanding-and-configuring-external-frequency-control-via-cat
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 18. February 2018, 23:15:13
Peter, Welche FW Groesse wurde verwendet? Klein 264b oder Gross 451kb. Mit Grossschrift. Die kleine Version lief immer..
Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 05:34:46
Hallo Chris,
ich habe immer die /uhsdr/archive/firmware/2.7.x/mchf/fw-mchf.bin verwendet.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 07:45:38
Ich benutze seit ca. 20 Jahren kein Windows mehr. Aus meiner Erinnerung kannte ich, dass Treiber immer irgendwelche sys oder dll Dateien installiert haben. Keine Ahnung, ob sich das in der Zwischenzeit geändert hat. Bei vielen meiner Kunden liegen im Download-Verzeichnis Treiber, die sind 50...200MB groß. Das können ja nicht nur irgendwelche infs sein. Aber Du weißt das besser Danilo - Du sitzt ja direkt vor einem Gerät das mit diesen Treibern läuft....
Tja - dann können es ja nur irgendwelche Einstellungen sein. Da es bei Peter mit Win10 läuft, kann es nicht an Windows(10) liegen, und auch nicht an unterschiedlichen Treibern (wie Du sagst), dann kann es ja nur noch an Einstellungen im mcHF selbst liegen (mal wieder), die das bewirken. Da waren wir ja schon öfter.
@Peter:
Die "Verwürfelungen" kommen vermutlich dadurch zustande, dass Du die Einstellung "Cat in sandbox" nicht aktiviert hast. Dadurch verstellen deine CAT Befehle den gerade aktiven Bandspeicher und Du kannst somit auf z.B. dem 80m Bandspeicherplatz eine Frequenz aus dem 20m Band speichern. Beim manuellen Durchwechseln der Bänder kommt jetzt da, wo eigentlich was mit "80" sein sollte, eine 20m Band Freuwnz...
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 07:46:32
Aber hier kann ich helfen ..
|
|
Hallo Danilo,
vielen Dank für die Info. Den Menüpunkt "CAT Running In Sandbox" hatte ich bisher immer überlesen.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 08:20:07
@Chris
Um zu überprüfen, ob es sich eventuell um eine Einstellung in der Config handelt, die bei allen deinen Geräten gleich ist, aber die wohl fast alle anderen anders haben, könntest Du mal gegenchecken, ob das Problem auch auftritt, wenn Du den mcHF mit der fraglichen Firmware mit der "Default Config" startest. Solange Du dann nicht mit langem Druck auf die Menütaste speicherst oder den mcHF normal ausschaltest, werden deine alten Einstellungen ja nicht überschrieben (also zum Ausschalten die Betriebsspannung abnehmen). Wenn Du ganz sicher gehen willst, kannst Du ja vor dem Test deine Config einmal im virtuellen EEPROM sichern.
Wäre schon interessant zu sehen, ob das Problem dann noch da ist.
Und nochmal:
Du bist weder ein "Schuldiger", noch "ein Böser" oder irgendsowas. Das hat hier auch niemand (ich auch nicht) gesagt. Aber Du bist mit diesem Problem schon irgendwo ziemlich alleine (der erste, bei dem das Problem nicht auftaucht, hat sich ja bereits gemeldet). Und das bedeutet, dass (zumindest ein Teil des Problems) irgendwo in deiner Zusammenstellung liegt. Ich will einfach nur herausfinden, WO in deiner Zusammenstellung. Wenn man im Blindflug manövriert, muss man probieren und vermuten.
Aktuelle Vermutung: Es ist eine Einstellung.
Kann geprüft werden: nur von Dir.
Ich würde mich über weitere Berichte wie den von Peter freuen. Egal was sie für ein Resultat haben.
@Danilo
Nach Betrachtung der Installationsdatei für den STM-Treiber ist mir auch klar geworden, warum ich immer felsenfest davon ausgegangen bin, dass hier irgendwelche sys oder dll-Dateien beteiligt sind: das zip (!!) des Treibers ist 2.2MB groß, und es enthält eine 2.8MB große exe-Datei. Dass bei dieser Dateigröße nur eine ein paar hundert Byte lange inf kopiert werden könnte, auf die Idee bin ich nicht gekommen...
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 10:39:28
@Peter
Um gleiche Testbedingungen zu haben wäre es schön, wenn Du den "CAT-Test" auch nochmal mit der Default-Config machen würdest. Mit der Default-Config UND der gleichen Firmware-Version UND der gleichen RAM-Size der MCU hätten wir vergleichbare Bedingungen zu Chris.
vy73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 19. February 2018, 11:44:25
Andreas
Ich habe nie behauptet, dass ich mit der Nicht OK FW z.B v2.7.85 mein Mixw oder FLdigi nicht zum laufen bringe. Das heisst, Cat und Audio funktionieren. (Bitte nachlesen)
Aber nur durch enorm grosse Fummelei mit Rein/Rausziehen des USB Kabel.
Also ich machte wie Peter, einen mcHF start, steckte dann das USB Kabel rein, und bei ca. 50% funktioniert das, bei den andern 50% muss ich im Mixw entweder die Audio oder der Comport in Mixw neu setzten. Comport wird oft nicht erkannt. Ich beobachtete eine Wechselwirkung, zwischen den Beiden.
Diesen Versuch habe ich mit Default Setting wie Du vorgeschlagen gemacht, ja sogar mit einem Reset Config Eprom.
Resultat wie eben beschrieben: Es geht, wie bei Peter.
Nun aber habe ich in vorgängig einem längern Bericht geschrieben über was ich feststellte, und wie ich mit dem System mcHF – Computer teste und arbeite. Da zeigt sich das vieldiskutierte Problem, zwischen den z.b v2.7.85 und dann wieder der OK Version v2.9.6.
Warum diese Einstellung, weil sie mit ausser den v2.7.85 +/- bestens funktioniert und zwar seit langen, und ich das USB Kabel gesteckt lassen kann, und das geht bestens!
Keine Fummelei, alles Einschalten wie bei Icom7300. Ähnlicher Anschluss über USB.
Erinnerst Du Dich an letztes mal mit gleichem Problem, als Du oder Danilo, herumgeisternden Speicher löschten und anschliessend alles wieder bestens funktionierte. So war es auch diesmal ab v2.7.93, warum weiss ich auch nicht, und ich glaube Dir, aber auch Danilo, dass durch verändern einer einzigen Zeile alles aus dem Lot kommen kann!!
Ich jammere nicht, bin aber müde, versuchen zu helfen und immer wieder zu Hören nur bei Dir. Kann ja sein, So what. Dann komm doch mal her und ich werde es Dir demonstrieren. Es ist absolut reproduzierbar in allem und jedem und das auf zwei ganz verschiednen Rechnern bzw. Programmen, und auch mit zurückgesetzten mcHF.
Ich habe wirklich alles gemacht und versucht was Du vorgeschlagen hast.
Die Wiederholung und die Tatsache des letzten anschliessend funktionierenden Fixes wurde nie mehr in betracht gezogen, nee eher weit von sich geschoben, aber gerade das ist und war für mich Beweis genug. Verständlich, es zu testen ist sehr komplex oder fast unmöglich, ausser es findet ein Trottel wie ich so was Hi Hi
Weiter Erklärungen meinerseits braucht es nicht mehr bin Stolz alleiniger Beobachter dieser immer reproduzierenden Erscheinung zu sein.
Ciao
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 11:57:17
@Chris
Irgendwie scheinen wir verschiedene Sprachen zu sprechen, obwohl es beides Deutsch zu sein scheint :'( Es tut mir leid - ich kann mich nicht mehr anders ausdrücken als ich es jetzt schon in zig Posts geschrieben habe. Ich will jetzt nur noch wissen, warum es offenbar bei den meisten (mindestens - eventuell sogar allen) anderen ohne bemerkenswerte Auffälligkeiten gegenüber anderen Versionen funktioniert und bei Dir nicht. Wenn Du mit Tests mithelfen magst, würde das eine Suche nach eventuellen Workarounds ermöglichen - oder sogar eine Funktion finden, die fehlerhaft ist (out-of bounds o.ä.), die aber niemand außer Dir in einer bestimmten Kombination nutzt. Wenn nicht, dann höre ich auf zu suchen.
"nur bei Dir" ist keine Schuldzuweisung!!!!!!!!!!!! Gerade solche Fehler, die nicht bei allen oder sogar nur bei einem auftreten, sind extrem schwierig zu finden, da sie nicht nachgestellt werden können.
Damit bis Du weder schuldig, noch dumm, noch unfähig oder irgendwas anderes. Bei Dir ist eine Kombination, die, objektiv gesehen, wohl sehr selten auftritt. Das ist eine Tatsache (schau auf die Rückmeldungen anderer) - nicht mehr und nicht weniger!! Kennst Du sowas nicht aus deiner Tätigkeit in der Forschung?
Ich konstatiere:
Bei Dir ist auch nach einem Start mit der Default-Config ein verändertes Verhalten in der USB-Erkennung gegenüber den anderen Versionen. Also Du musst auch bei einem Start mit der Default-Config in deinen Programmen irgendwas umstellen, rumprobieren - stimmts?
Peter,
bitte sag nochmal ganz klar, ob es mit den 83ff Versionen bei Dir (mit oder ohne default) ein Unterschied in der CAT/Audio-USB-Erkennung ein Unterschied zu den anderen (vorherigen) oder der aktuellen Version ist. Also ob Du irgendwie "lange probieren musst", oder "es sich von selbst verstellt nach Neustart" etc. oder ob Du mit den ja bereits bestehenden Einstellungen bezüglich Com-Port etc. einfach weiterarbeiten kannst über die Versionen 82 --> 83 hinweg.
Wenn das bei Dir geht und bei Chris nicht, können wir weiter folgern.
Also gleiche Bedingungen bei beiden Testern auf mcHF-Seite.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 19. February 2018, 13:41:45
Ja sicher sprechen wir verschiedene Sprachen. Du diktierst das Test Vorgehen, ziehst aber meine mehrmals beschriebene Testanordnung nie in Betracht. Nee sagst, ja das macht doch jeder anders. So kommt man doch nie zu meinem wiederholbaren Ergebnis, was hier bei mir der Fall ist. Ich wiederhole mich, ich testete jeweils mit verschieden Rechnern, verschieden aufgesetzten mcHF’s sogar einem ganz neuen v07, noch Jungfräulich. Alle zeigen nach meinem Testaufbau dasselbe Resultat.
Wenn ich irgendeine andre Methode verwende, so wie Du vorgeschlagen hast, kommt jeder zu einem richtigen Resultat, wenn es nur einmal geht und das jeweilige Programm arbeitet. d.H. der TX sendet. Ist doch bestens alles sind glücklich.
Lieber Andreas das sind Einzellfälle. Ich habe hier eine wiederholbare Fehler Statistik.
Ich kenne viele Om’s die sind Happy, wenn sie in der Lage sind mit ihrem mcHF Digi Modes zu betreiben, ich auch. Aber bei mir ist er wie gesagt fest verdrahtet, und im fast täglichen Einsatz, und wenn dann etwas nach z.B einem neuen FW Upgrade nicht mehr richtig funktioniert, schaue ich nach und gehe zuerst auf die frühere Version zurück. Ich lass es mir also Bestätigen. Dann geht die Sucherei, los und ganz am Schluss melde ich mich dann im Forum. Was dann rauskommt sehen wir hier. Ich werde es in Zukunft lassen, obwohl mir sehr viel an eurer sehr guten Arbeit liegt und ich mich dafür Bedanke. Ich liebe und schätze die Grossschrift, frage mich aber, wo der Unterschied ist zwischen der grossen 451kb Version und der kleinern 264kb Version ist, die immer sauber lief
Ich bin überzeugt es liegt 100% an der FW, sei es durch Zufall zustande gekommen oder nicht, spielt doch keine Roll und niemand hat Schuld daran. Nimm es zur Kenntnis, etwas ist zwischen v2.7.85 und v2.7.96 verschieden, und das zeigt sich bei mir, ob auch bei andern kümmert mich nicht mehr. A
Ciao
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 14:16:04
Hallo Chris,
ich versuche (nur) herauszubekommen, ob es auch andere gibt, bei denen die CAT-Funktionen mit dem Übergang von der 82er auf die 83er irgendwie zu Verdruss geführt haben. Ich denke, wie gesagt, dass es mehrere gibt, die eine der betroffenen Versionen (die stable!!!) installiert haben. Und die Windows haben. Und die CAT machen. Und denen auffallen würde, wenn seit dem Wechsel auf diese Funktion irgendwas nicht mehr so läuft wie vorher. Also ein Umstellen nötig ist. Oder sich irgendwas verstellt. Oder, oder, oder.
Und wenn dem so ist, dann kann man versuchen, die Sache einzukreisen.
Aber selbst bei nur einem kann das gelingen. Wenn man genau vergleichen kann, ob es STABIL läuft oder nicht. Und wildes Herumprobieren nach jedem Neustart ist NICHT stabil.
Stabil ist: einmal einstellen und es bleibt so.
Und Peter hat bislang nicht geschrieben, dass er lange herumprobieren musste, damit CAT wieder läuft. Er schrieb nur, dass er vermutlich ein Programm offen hatte, das den CAT-Port noch in Benutzung hatte, als er ihn ausgeschaltet, upgedatet und wieder eingeschaltet hatte. Dass dabei der Comport verwürfelt werden würde, ist normal, da denke ich gar nicht weiter drüber nach. Also gehe ich davon aus, dass auch nach dem Wechsel auf die 2.7.83 alles genauso stabil lief ohne Änderungen wie vorher.
Ich habe keine Ahnung, was dabei herauskommt. Es ist eben eine Forschung.
Nochmal zu den Änderungen, damit es wieder lief:
Es wurde nur der Code etwas von nicht mehr benötigtem RAM-Verbrauch befreit. Also RAM, der irgendwann mal für irgendwas reserviert wurde, irgendwann auch mal gebraucht wurde, aber jetzt nicht mehr. Er wird also reserviert (steht damit anderen Funktionen nicht mehr zur Verfügung) aber wird für nichts gebraucht.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 14:36:33
Und Peter hat bislang nicht geschrieben, dass er lange herumprobieren musste, damit CAT wieder läuft.
|
|
Die ganze Testserie ging ratzfatz. Ich hatte abgesehen von diesem vermutlich noch offenen Port keine Probleme beim Durchprobieren der Versionen. Ich musste auch nichts an der Konfiguration es WSJTX nachkonfigurieren. Mir ist auch kein Unterschied aufgefallen, soll heißen, alle Versionen haben sich bzgl. CAT/Audio gleich verhalten.
Wenn ich es schaffe, werde ich heute abend noch mal einen Test mit der default-config machen.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 14:45:43
Das wäre schön, Peter. Damit könnten wir den vielleicht noch offen gewesenen Port als Fehlerquelle für dein einmaliges Problem auch isolieren.
Wenn dann noch ein zweiter - ebenfalls mit Win10, den betreffenden Firmwareversionen und Verhaltens-Vergleich mit der Default Config ebenfalls keine Veränderungen feststellt, deutet es darauf hin, dass es außer dem vermutlichen RAM-Problem noch eine zweite Komponente geben muss, die ebenfalls erfüllt sein muss, damit es zu einem Problem kommt.
Wir hatten vor Längerem schon mal bei einem User das Problem, dass sich der mcHF nicht einschalten ließ, wenn er mit einem PC verbunden war beim Einschalten. Das lag am USB-Kabel (!!!) Das Kabel funktionierte aber einwandfrei, wenn es im Betrieb gesteckt wurde. Auf sowas muss man erstmal kommen. Sicher - die Sachlage ist hier anders. Aber auch hier können abstruse Dinge im Spiel sein.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 19. February 2018, 15:17:23
Peter wie gross ist dein Firmware File was Du benutzt in Kb?
73 Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: Romin DB7EN on 19. February 2018, 16:16:14
Hallo und guten Tag Euch allen mcHF- Liebhabern !
Da ich meinen mcHF V0.4 mit 1MB und 192k überwiegend für WSPR und WSJT-X 1.8
betreibe und nach jeder !! neuen Firmware und Boot-Loader überprüfe, ob noch alles
funktioniert (insbesonders WSPR), muß ich sagen "in den Digital-Betriebsarten alles OK".
Ich verwende auf meinem noname-Rechner und meinem mini-SONY-VAIO-Notebook
WIN7. Das Datenkabel ist am mchf und am jeweils verwendeten Rechner angeschlossen.
Der Rechner läuft und dann schalte ich den mcHF ein. Dann wird das WSJT-Programm
gestartet und im Setup des Programms überprüft, ob alles stimmt. Es kommt gelegentlich
vor -je nach dem, was ich mit dem Rechner vorher gemacht habe -, in der Audioeinstellung
des Programms - und nur dort - berichtigen muß. Das ist aber auch alles.
Es ist einmal passiert, nach installieren eines neuen Boot-Loaders, dass die CAT-Funktion
nicht mehr klappte. Im Gerätemanager hatte sich nach Einschalten des mcHF die COM-
Schnittstelle von 13 nach 4 verlaufen. Im Setup bei WSJT nachgebessert und alles im Lot!
Also, was das anbelangt, bisher keine Probleme. Und die Sache von neulich: mcHF für
"Gehörlose" (keine NF) , hat sich ja schnellstens aufgeklärt. Danke nochmals dafür!
Für die aktuelle Problematik habe ich leider auch keine Idee und hoffe für Chris, daß es nicht
doch was mit WIN10 zu tun hat.
Weiter so und vy 73
Romin
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: OE5RKM on 19. February 2018, 18:31:55
Hallo
Nachdem ich auch user eines mchf v0.5 und WSJT-X 1.8.0 verwende und keine Probleme hatte und
habe machte ich mir die MÜHE und installierte 2.7.83 in beiden Varianten 281KB und 474KB
Meine Konfiguration :
MCU 413h
Flash 1024
Ram 192
BL 4.0.0
Win 10
Dell Latidude 6420 Laptop
Cat Schnittstelle funktioniert nicht mehr
Windows zeigt im Gerätemanager usb auf com5
in settings von WSJT-X 1.8.0 steht com 3 und 5 zur Auswahl
wobei aber com 5 gar nicht angenommen wird und com 3 nur kurz grün wird- aber CAT nicht funktioniert
nach flashen der Neuen 2.9.7 wieder alles OK ohne Probleme
WSJT-X , Fldigi , EasyPal
Ich nutze auch diese Programme mit einen anderen TRX ohne Probleme
vy 73 Rudi |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 18:44:30
Danke für eure Teilnahme - mehr davon! Es scheint beides zu geben: Leute, bei denen es mit Windows auch mit den fraglichen Versionen läuft (bisher einmal Win10, einmal Win7), und Leute, bei denen es mit Windows nicht läuft (bisher 2 x Win10). Und unter Linux läuft es egal welche Linux-Version.
Das ist noch nicht genügend "Futter" für etwas, wo man es wagen könnte, Schlüsse draus zu ziehen.
Aber so habe ich mir das im Prinzip vorgestellt. Mehr Input kann weiterhelfen.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 19:51:06
Hallo zusammen,
wie versprochen, hier noch mein Test nach Einspielen der Default Config:
Reset auf default config (F1+F3+F5)
V2.7.83 aufgespielt
Größe 462 KB (473.900 Bytes)
Größe auf Datenträger: 464 KB (475.136 Bytes)
TRX aus
USB-Verbindung gesteckt
TRX ein
Gerätemanager meldet:
USB-Gerät an COM4
Lautsprecher (USB Interface mchf)
Mikrofon (USB Interface mchf)
Start WSJTX
Meldung "RIG Control Error, Do you want to reconfigure ..."
Check unter Settings->Radio/Audio: alles so wie es sein soll
Wiederholtes Neustarten birngt immer wieder die gleiche Fehlermeldung
USB-Verbindung kurz unterbrochen und WSJTX neu gestartet -> keine Fehlermedlung mehr
dann kann ich mit Enable TX und Tune senden, also alles ok
Nach Beenden und Neustart von WSJTX alles ok, keine Fehlermeldung
Dann alternativ WSPRX gestartet:
Fehlermeldung "rigctl stderr: rig_open: error = IO error"
Check Setup->Options: sieht ok aus
Wie oben, nun USB kurz unterbrochen und WSPRX neu gestartet -> alles ok
Kurzum: abgesehen von meinem irgendwie gearteten Port-Problem läuft die CAT-Kommunikation auch mit der Default-Config.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 19:59:35
Vermutlich blöde Idee, aber: könnte das Problem evt. etwas mit den Bios-Einstellungen (USB Legacy) oder mit Windows 32bit vs 64 bit zu tun haben? Evt. sind die Treiber ja unterschiedlich. Meine Tests habe ich mit einer 64bit-Version gemacht.
Bei Bedarf könnte ich in den nächsten Tagen noch mal mit einem Asus eeePC mit Windows10 testen. |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 19. February 2018, 20:06:04
Hallo Peter,
Genau das ist der Fehler den Chris gemeldet hat. Du hast den also auch - und Du hast auch Win 10... Noch ein paar Meldungen mit Win10 und ein paar mit anderen Wins und es könnte sich ein System daraus erkennen lassen...
vy73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: OE5RKM on 19. February 2018, 20:14:49
Andreas - ich habe nun einen weiteren TEST gemacht
1.)
Version 2.7.83 geladen
Win10 hochgefahren
MCHF ein - WSJT-X ein
keine CAT Möglichkeit
USB Stecker AUS/EIN ---- CAT sofort möglich
2.)
MCHF ein
PC ein --win10 Hoch
WSTJ-X ein -----CAT OK keine Probleme
3.)
2.9.7 geladen
alle Varianten möglich ohne Probleme oder ändern von Einstellungen
vy 73 Rudi
WIN10-64Bit Version |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 19. February 2018, 22:33:20
Genau das ist der Fehler den Chris gemeldet hat.
|
|
Hmm, ich dachte, mein ;) Fehler wäre nur so ein nicht geschlossener Port, der durch das Kabelziehen behoben wird. Und ich bilde mir ein, dass ich diese Fehlermeldung gestern auch bei allen anderen Versionen hatte.
Ich habe den Test (doch heute schon) mit dem Asus eeePC unter Windows 10 wiederholt. Mal abgesehen davon, dass diese alte Möhre mit Windows10 doch etwas überfordert ist, funktionierte der CAT/Audio-Betrieb einwandfrei.
Interessant scheint somit, ob die Fehlermeldung "RIG Control Error, Do you want to reconfigure ..." auch bei der aktuellen FW-Version vorkommt.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 06:20:30
Also bei mir erhärtet sich der Verdacht, dass Windows mit der USB-Schnittstelle anders spricht als Linux. Irgendwie reden UHSDR und Windows aneinander vorbei, wodurch der RAM-Bedarf der USB-Funktionen in UHSDR ansteigt. Und dadurch kommt es zu den Überlappungen und damit auch zu dem Fehler. Alles reine Vermutungen.
Die einzige Tatsache, die ich selbst verifizieren kann, ist die, dass unter Debian stable und Debian unstable alles ohne jegliche Fehlermeldungen funktioniert.
Jetzt bräuchten wir noch Mittester, die Windows 7 haben. Das ist/war das beste Windows, das das Haus Microsoft je verlassen hat (meine Meinung).
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 20. February 2018, 07:05:40
Ein Windows7-Notebook liegt bei mir auch noch irgendwo herum. Wenn ich Zeit finde, teste ich damit mal.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 20. February 2018, 09:14:22
Status Report
Windows7 und Windows8 arbeiten perfekt mit v2..7.85. mit der grossen 460kb Version.
Das mit fest Verbundenem USB Kabel. So wie es sollte sein.
Referenz, Test Programm ist bei mir Mixw2 v2.18, weil es am besten ein Missverhalten der Einstellungen zeigt. Was heisst, ich starte in der Reihenfolge PC, mcHF dann Mixw2. bei verbundenem USB Kabel. Programm kann benutzt werden.
Dasselbe gilt auch für Windows10 32 und 64. Allerdings nicht gleich, sondern nur wenn nach den Start von Mixw2 das USB Kabel raus und wieder rein stecke, dann werden Audio bzw. Comport4 in Mixw2 gesetzt. Vorher zeigt es: Comport4 nicht gefunden
Beim raus/rein stecken kann ich direkt verfolgen wie die Ports in Mixw2 erkannt werden.
Mit der FW v2.7.96 ist eine raus rein stecken des USB Kabels nicht notwendig, es verhält sich gleich wie bei Windows7 oder 8 und arbeitet sofort korrekt.
Warum ist das so? Dafür gibt es zwei Gründe.
Der erste Grund, betrifft das differente Verhalten von FW v2.7.85 bei Windows 7,8 beziehungsweise Windows10.
Bei Windows7,8 muss der benötigte USB Treiber mit dem Programm vcp_v1.4.0_setup.exe von STMICROELECTRONIC ins Windows7,8 OS geladen werden.
Ab Windows10 32/64 wird der für USB der dazu notwendige Treiber von Windows10 OS selbst erkannt und installiert. Ich versuchte den alten Treiber von Windows7,8 in Windows10 selbst zu installieren, Ging nicht.
Ich vermute daher stark dass es damit zusammen hängt. Vielleicht sollte jemanden einen neuen USB Treiber für WIN10 schreiben, aber es funktionierte ja bestens bis zum beschrieben Happening.
Der zweite Grund betrifft das different Verhalten zwischen den Versionen v2.7.85 und v2.7.96 bei Windows10
Bei mir feststellbar bei fest eingestecktem USB Kable, also ohne USB rein raus Fummelei, und nach Monate langen perfektem arbeiten damit
Dabei viel mir eine Fehlverhalte erst auf.
Bis anhin gab es drei Vorfälle, Zwei einige Monate zurückliegend, der letzt mit v.2.7.83 kürzlich.
Die beiden letzten wurden jeweils, nach Meldung von mir, vom Softwareteam behoben.
Danach war alles wieder im grünen Bereich bis zu v2.7.83. Ab da hatte ich grosse Probleme irgendein Digi Programm zu starten. Meldung an Andreas. Er sagte der Fehler müsse bei mir liegen. Siehe Dialog hier.
Das konnte fast nicht sein. Warum sollte meine System (Es sind mehrere) plötzlich ab v2.7.83 nicht mehr, funktionieren und ab v2.7.96 ist alles wieder in Ordnung sein?
Kommt dazu dass letztes Jahr der gleich auftretende Fehler vom SW Team behoben wurde?
Ciao an alle mcHF Freunde
Chris
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 09:26:31
Hallo Chris,
der Fehler wurde niemals gezielt bearbeitet - da er nicht identifiziert wurde (und werden kann). Vielmehr wurden und werden täglich Verbesserungen und Reworks vorgenommen, und dann geht es zufällig wieder.
EDIT:
Wir VERMUTEN, dass es sich um ein Problem eines zu knapp werdenden RAMs in UHSDR handelt, der dann zu RAM-Überschneidungen, und dann zu Fehlern führt. Da das aber nicht bei allen Betriebssystemen passiert, ist der RAM nicht generell überschnitten - sondern nur im Betrieb mit Windows 10. Windows 10 scheint in seinem USB-Handling den Speicherbedarf in UHSDR hochzutreiben, und das führt dann zu dem Problem.
Es scheint sich damit zu erhärten, dass der Fehler mit dem Einsatz von Windows10 zusammenhängt.
Insofern ist meine anfängliche Vermutung doch richtig gewesen.
Inwiefern man das abstellen kann, muss noch erforscht werden. Niemand aus dem Programmiererteam verschwendet auf jeden Fall mit Absicht RAM (wenn es überhaupt daran liegt). Aber es gibt meistens nach Einbau von neuen Funktionen später, nach etwas Abstand und Nachdenken, Möglichkeiten, das Ganze noch etwas eleganter zu Lösen. Das ist dann der Feinschliff. Und in dem Zuge werden dann oft noch Optimierungen vorgenommen, die den Speicherbedarf, die Codelänge, die Ausführungszeit etwas reduzieren. Das ist tägliches Brot.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 09:44:20
Etwas fällt mir noch ein:
Es gab auch gaaaaanz am Anfang ein Problem mit einigen Linux-Distris und CAT. Die betreffenden Distris haben nach Anschluss des USB-Kabels ein im Hintergrund laufendes Progrämmchen namens "modemmanager" - bei einigen auch / oder "brailletty" gestartet und dieser hat ungefrat versucht, mit dem neuen Gerät zu kommunizieren (ob es ein Modem oder eine Baillezeile ist). Das führte dazu, dass CAT nicht funktionierte. Wenn man den Programmen dieses "Antesten" verbot, lief alles.
Vielleicht gibt es solche "Verbesserten Zugangsmöglichkeiten für behinderte Menschen" auch bei Windows10?
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 20. February 2018, 11:43:52
Andreas
Es wurde nie bezweifelt, dass das jetzt hier viel diskutiertes Happening, was ja in der Zwischenzeit wieder läuft, nur bei Windows10 auftritt. Aber es trat auf und kann nachvollzogen werden. Niemand gibt irgendwem eine Schuld, das erwähnte ich immer und immer wieder in meinen Antworten und Berichten. Aber nicht alle sind Linux Experten, das ist ein relativ kleine Gruppe, auch ich war dabei, auch mit Unix etc.
Aber an Bill Gates kommt heute halt niemand mehr vorbei, es sind Millionen die zufrieden damit arbeiten, Jedes Huhn legt mal ein schlechtes Ei.
Wir sollten es akzeptieren und versuchen Problemen die immer mal vorkommen, zu lösen. Haben wir Freude an dieser sehr guten Software und dem wirklich guten mcHF System, sei es von Chris M0NKA oder von Euch mit dem neuen System und seit bitte offen für Beobachtungen und Fehlermeldung. Ich werde weiter suchen, vielleicht finde ich noch den Draht zu Bill Gates
Ueberigens, im Forum ist auch später noch alles nachzulesen.
Das sollte es eigentlich gewesen sein
Danke und Ciao Andreas
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 13:19:11
Genau. Jetzt haben wir einen Punkt, an dem wir ansetzen können - evtl. auch mit Debugging. Und es kann durchaus sein, dass da nochwas existiert, was man bezüglich dieses Problems verbessern kann. Wo auch immer: auf Firmwareseite, oder auch auf Betriebssystemseite.
vy 73
Andreas
EDIT/Nachsatz:
Doch, an Bill Gates kann jeder vorbeikommen, der das will. Ich bin so einer und bin auch Leiter der hiesigen Linux User Group - und ich gebe Kurse an der VHS für Leute, die von Bill Gates loskommen wollen. Die Zahl derer, die das wollen, ist seit Windows 10 steil angestiegen 8) Aber das hat mit diesem Thema NULL zu tun - ist nur eine allgemeine Antwort auf deinen Nebensatz, dass da keiner dran vorbeikommt... |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: peter_77 on 20. February 2018, 16:19:10
| Bill Gates ist ja noch nicht alles es gibt ja außer Thorvalds auch noch Steve Jobs und da werkelt wenigstens auch ein Unix unten drunter 8) |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 16:49:31
Peter, kannst Du auch mal den CAT-Test mit den fragiichen Versionen machen? es würde mich interessieren, ob das Problem bei OS/X da ist.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 20. February 2018, 17:42:25
Ich habe hier gerade nochmal zwei Tests auf dem Windows10-Notebook gemacht mit 2.7.83. Wie zu erwarten:
- mit dem kleinen mchf.bin funktioniert es
- mit dem großen nicht
Für beide Fälle habe ich mit Wireshark Traces der USB-Kommunikation gemacht.
kleines mchf.bin:
Zeile 1-76: Trace nach Einschalten des mchf, vor dem Start von WSJ-TX
ab Zeile 77: Trace nach Start von WSJ-TX
beim großen mchf.bin geht der erste Teil bis Zeile 73
Ich konnte auf Anhieb nichts herausfinden, aber vielleicht spricht ja jemand fließend USB ;) Die Messages sehen zumindest ähnlich aus, evt. sind aber die Längen unterschiedlich und bringen das RAM zu Überlaufen o.ä.
(Datei in CAT_issues.zip umbenennen)
EDIT:
In den Traces gibt es u.a. ab ca Zeile 74 viele
"GET LINE CODING REQUEST" vom Notebook zum mchf, und
"GET LINE CODING RESPONSE" vom mchf zum Notebook.
In der Payload des Response-Pakets sendet der mchf seine seriellen Parameter in 7 Bytes:
Byte 0-3: Baudrate
Byte 4: Anzahl Stopbits
Byte 5: Parity
Byte 6: Anzahl databits
So steht beim funktionierenden Fall (kleines FW-File) nach einigen Requests/Responsefolgen im Payload (Zeile 104) die Bytefolge 80:25:00:00:00:00:08 (80 25 = 9600)
Im nichtfunktionierenden Fall wird aber vom mchf immer
a8:70:76:9e:6b:4a:e9 zurückgemeldet - scheinbar keine gültigen Werte. Vielleicht führt dies dann zur Fehlermeldung.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 20. February 2018, 19:57:07
Ich denke, dass Win10 beide Fälle gleich "anspricht". Im Falle des kleinen bins ist aber mehr als genug RAM vorhanden, weil freeDV ja nicht mit im Binary ist und somit auch der von freeDV reservierte RAM nicht belegt ist. Somit kann eine "unglückliche" Kommunikation (eine, die mehr RAM im UHSDR verbraucht als für die Funktion nötig ist) beim kleinen bin rumvagabundieren ohne Schaden anzurichten. Beim großen bin geht das nicht. Dort wird jedes Byte gebraucht und die Strafe für eine zu RAM hungrige Kommunikation ist Nichtfunktion :)
Im Prinzip müsste man nicht groß und klein, sondern Win7/8 und Win10 vergleichen. Dann dürfte man den Unterschied sehen.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 21. February 2018, 20:18:52
Halllo Andreas,
Im Prinzip müsste man nicht groß und klein, sondern Win7/8 und Win10 vergleichen. Dann dürfte man den Unterschied sehen.
|
|
heute habe ich den Test mit Windows7 und der 2.7.83 (großes bin) gemacht. Wie zu erwarten, funktioniert es damit ohne Fehlermeldung.
Anbei der USBTrace (Zeile 1-122: Nach Einschalten des mchf, ab Zeile 123 dann nach Start von WSJTX).
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 21. February 2018, 20:29:34
Danke für die Tests, Peter.
Jetzt müssen wir nur noch schauen, wer die Vorlage aufnehmen kann. Mich juckt es gewaltig zu schauen, was der Unterschied zwischen Win7 und Win10 ist - mich drückt allerdings die Auslieferung der OVI40 UI.
Win10 macht irgendwas "schlechter" als Win7. Nur was ::)
Deine Logs sind ein gutes Fundament.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 21. February 2018, 20:39:51
Auf die Schnelle ist mir aufgefallen, dass bei den funktionierenden Fällen (also Win10/kleines Bin und Win7/großes Bin) der Host die Message
"SET LINE CODING Request" sendet. Danach sieht man dann in den Responses, dass die seriellen Parameter (Baud, Parity, Databits) richtig gesetzt sind. Im nichtfunktionierenden Fall fehlen diese Messages.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 22. February 2018, 08:06:19
OK. Ich habe jetzt leider keine Zeit zum selbst forschen.
Wenn der Host in beiden Fällen die Frage sendet und es kommt in einem Fall keine Antwort kann das zwei Gründe haben:
1) der Client sendet tatsächlich keine Antwort
2) der Host wartet nicht lange genug auf die Antwort, die wäre noch gekommen, aber nach dem "timeout".
In Fall 1) müsste man schauen, was wurde vorher alles gesendet (Unterschiede zwischen Win10 und Win7) denn der Grund, warum keine Antwort kommt, muss davor liegen
In Fall 2) sieht es exakt genauso aus. Der Grund, warum die Antwort länger dauert muss ebenfalls in der Kommunikation vorher zu finden sein.
Im Prinzip ist das wie der berühmte blaue Bildschirm "die schwere Schutzverletzung 0E ist aufgetreten". Das ist der Punkt, an dem es gar nicht mehr weitergeht/ging und diese Meldung wurde angezeigt. Der eigentliche Fehler, das Problem selbst kann (und lag auch meistens) weit vor diesem "Ausstieg". Nur führte der Fehler nicht sofort, sondern erst nach einer längeren Kette weiterer Operationen und Befehle zu einem Absturz.
Daher denke ich auch, es ist nicht weiterführend zu prüfen, ob die Antwort ganz ausbleibt oder verzögert kommt. Das eigentliche Problem liegt VOR diesem Vorgang. Bei identischen Befehlsabläufen ist es das Timing.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: peter_77 on 22. February 2018, 08:45:42
Hallo Andreas !
Auf dem Mac erkennt Mac OS den mcHF als auch das I40 Board problemlos und auch mit mehrmaligem hin- und herstecken ohne Fehler.
mcHF (Ver. 2.9.8)
Code:
MacBook:~ user$ system_profiler SPUSBDataType
USB:
USB 3.0 Bus:
Host Controller Driver: AppleUSBXHCISPTLP
PCI Device ID: 0x9d2f
PCI Revision ID: 0x0021
PCI Vendor ID: 0x8086
USB2.0 Hub:
Product ID: 0x100f
Vendor ID: 0x05ac (Apple Inc.)
Version: 45.28
Speed: Up to 480 Mb/sec
Manufacturer: Apple Inc.
Location ID: 0x14100000 / 4
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
USB Interface mchf:
Product ID: 0x5732
Vendor ID: 0x0483 (STMicroelectronics)
Version: 2.00
Serial Number: 00000000002A
Speed: Up to 12 Mb/sec
Manufacturer: UHSDR Open Source Community (based on STMicroelectronics Drivers)
Location ID: 0x14110000 / 6
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0 |
|
I40 UI gleiche FW
Code:
MacBook:~ user$ system_profiler SPUSBDataType
USB:
USB 3.0 Bus:
Host Controller Driver: AppleUSBXHCISPTLP
PCI Device ID: 0x9d2f
PCI Revision ID: 0x0021
PCI Vendor ID: 0x8086
USB2.0 Hub:
Product ID: 0x100f
Vendor ID: 0x05ac (Apple Inc.)
Version: 45.28
Speed: Up to 480 Mb/sec
Manufacturer: Apple Inc.
Location ID: 0x14100000 / 4
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
USB Interface 40SDR:
Product ID: 0x5732
Vendor ID: 0x0483 (STMicroelectronics)
Version: 2.00
Serial Number: 00000000002A
Speed: Up to 12 Mb/sec
Manufacturer: UHSDR Open Source Community (based on STMicroelectronics Drivers)
Location ID: 0x14110000 / 7
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0 |
|
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 22. February 2018, 08:52:43
Wenn der Host in beiden Fällen die Frage sendet und es kommt in einem Fall keine Antwort kann das zwei Gründe haben:
|
|
Die Message "SET LINE CODING Request" wird im nichtfunktionierenden Fall vom Host gar nicht erst gesendet. Aber wie Du schon sagst: das kann auch an irgendwelchen Messages davor liegen.
EDIT: Ganz hilfreiche Infos zu USB: http://www.usbmadesimple.co.uk/ums_4.htm (http://www.usbmadesimple.co.uk/ums_4.htm)
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 22. February 2018, 09:27:40
Wird gar nicht erst gesendet!! OK - das habe ich missverstanden. In dem Fall ist ja ganz klar, dass das Problem davor liegt. Noch eine Frage: Ist das der Datenverkehr der passiert, wenn der mcHF vom Windows "erkannt" wird - oder ist das der Datenverkehr, wenn ein Programm gestartet wird, das auf den CAT Port zugreifen will?
Du kannst ja auch mal folgendes testen:
Win10 - mcHF anstöpseln (zum ersten Mal) --> Daten mitloggen
dann mcHF wieder abstöpseln, ohne je auf die CAT Schnittstelle zugegriffen zu haben.
nun mcHF wieder anstöpseln und den zweiten Erkennungsvorgang mitloggen.
Unterscheiden sich die beiden?
EDIT:
zweimal "Peter" - das ist genau so ein Sammelbegriff wie "Andreas" ::) @peter77: Ich dachte es mir...
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 22. February 2018, 10:06:55
| Noch eine Frage: Ist das der Datenverkehr der passiert, wenn der mcHF vom Windows "erkannt" wird - oder ist das der Datenverkehr, wenn ein Programm gestartet wird, das auf den CAT Port zugreifen will? |
|
Die Traces sind zweigeteilt. Du siehst das in Wireshark an den Zeitstempeln: Je nach Trace beschreiben die ersten 70 bis 100 Zeilen die Phase nachdem der mchf eingeschaltet wurde, das Programm aber noch nicht gestartet wurde. Dann kommt bei den Zeitstempeln ein Sprung von mehreren Sekunden, und dann beginnt die Phase nachdem ich das Programm gestartet habe.| Du kannst ja auch mal folgendes testen ... |
|
Gute Idee -probiere ich heute abend mal aus.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 22. February 2018, 10:19:30
Peter ist klar im Prinzip. Aber ich habe im Moment keine zeit, mir die traces anzuschauen. Ich tippe hier immer nur ein paar Sekunden zwischendurch ::)
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 22. February 2018, 18:04:53
Neuer Test (Windows 10, 2.7.83, großes bin)
Ich habe nun einen Trace gemacht ab dem Zeitpunkt, an dem ich die USB-Verbindung kurz unterbrochen habe und dann den USB-Stecker wieder reinstecke. Wie bekannt, läuft dann die CAT-Verbindung. Aus dem Trace habe ich allerdings (bislang) noch keine neuen Erkenntnisse gewonnen. Irgendwie habe ich den Verdacht, dass zum Anfang vielleicht ein Reset fehlt, der dann beim kurzen Ziehen des USB-Steckers simuliert wird und dazu führt, dass die folgende CAT-Kommuniation dann funktioniert.
Anstelle von WSJTX kann man übrigens auch einfach ein Terminalprogramm (z.B. putty) verwenden und versuchen, sich seriell mit dem TRX zu verbinden (also zur COMx-Schnittstelle). Bei den nichtfunktionierenden Fällen bekommt man den Port erst gar nicht auf.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: peter_77 on 23. February 2018, 19:30:31
Was ist denn "großes bin" bei Winblows ???
Hast du testweise mal eine andere USB Buchse am Rechner probiert ?
Klingt kurios aber bei der Winblows Gurke hier (Win 10, 1709) funktionieren die direkten Board USB Ports signifikant anders als die die mit einer Stecker Extension ans MB gesteckt wurden.
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 23. February 2018, 21:40:19
Was ist denn "großes bin" bei Winblows ???
|
|
Bezieht sich auf die Größe des Firmware-Files (mchf.bin).
Ich habe bislang noch keine anderen USB-Ports ausprobiert. Spielt aber auch keine Rolle, denn mit dem "kleinen" Bin ;) für die 512er CPUs des mchf funktioniert ja alles.
Ich habe im Augenblick keine weitere Idee mehr und vom USB-Stack zu wenig Ahnung, um hier weiterhelfen zu können. Da das Verhalten ja scheinbar von der Größe des Firmware-Files abhängig ist, vermute ich - wie Andreas auch schon erwähnt hat - ein Speicherproblem auf der mchf-Seite.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 24. February 2018, 07:52:01
Es muss aber eine zweite Komponente dazukommen, damit das zum Tragen kommt. Unter meinen Linux-Systemen funktionieren immer und auf Anhieb alle Firmware-Versionen: "groß" und "klein". Und bei Win7 - wie berichtet - ja auch.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 24. February 2018, 08:00:34
Hi Peter, Abdreas
Liest doch mal nach, was ich ziemlich am Anfang dieser Diskussion beobachtete und dann darueber schrieb
Gruss Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 24. February 2018, 08:12:02
Welchen Post meinst Du (Datum/Uhrzeit)?
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: hb9bdm on 24. February 2018, 08:34:46
Hallo Andreas
17.Febr. 2018 10.24.57
Mir viel das auf als ich alle grossen Files Checkte.
Ich sah eine Veraenderung der Groesse
73 Chris |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 24. February 2018, 09:27:13
Die Filesize ist in diesem Zusammenhang vollkommen unwichtig. Das hat mit dem hier vorliegenden Problem *nichts* zu tun - sie hat *keinerlei Relevanz*.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 24. February 2018, 17:30:35
Hallo nochmal,
das Problem hat mir keine Ruhe gelassen ;) und so habe ich mir heute nochmal die Traces angeschaut.
Wie schon weiter oben geschrieben, gibt es in der USB-Kommunikation u.a. eine Message vom USB-Host zum TRX:
"GET LINE CODING REQUEST"
und die darauffolgende Antwort vom TRX an den Host:
"GET LINE CODING RESPONSE"
In der Payload (7 Bytes) der Response schickt der TRX die initialen bzw. bisher konfigurierten seriellen Parameter an den Host.
Diese Payload unterscheidet sich (initial) je nach Szenario:
Windows10, kleines FW-File: 00:00:00:00:00:00:00
Windows10, großes FW-File: a8:68:3e:9e:4b:5a:a9
Windows7, großes FW-File: a8:68:3e:9e:4b:5a:a9
Im weiteren Verlauf der USB-Kommunikation wird dann mit der Message "SET LINE CODING REQUEST" dem TRX die zu setzenden seriellen Parameter übermittelt. Im funktionierenden Fall liefert eine weitere Message "GET LINE CODING RESPONSE" dann z.B. "80:25:00:00:00:00:08", wobei die 80:25 für 9600 Baud und die 8 für die Anzahl der Datenbits steht. Im nichtfunktionierenden Fall taucht die Message "SET LINE CODING REQUEST" nicht auf, folglich werden die seriellen Settings auch nicht übermittelt.
Meine Theorie ist (mit vielen Konjunktiven), dass der USB-Treiber sich an der Response mit der Payload "a8:68:3e:9e:4b:5a:a9" verschluckt. Diese Bytefolge gibt es zwar auch bei dem (funktionierenden) Windows7-Fall, allerdings wird bei Windows7 meines Wissens ein anderer Treiber verwendet, der vielleicht diese Payload akzeptiert.
Wenn also in dem mchf-Code die Struktur für diese seriellen Parameter fälschlicherweise überschrieben werden oder nicht initialisiert werden, könnte es sein, dass anstelle von "00:00:00:00:00:00:00" dort anfangs "a8:68:3e:9e:4b:5a:a9" drin steht und dann das Problem verursacht.
Gruß
Peter
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 24. February 2018, 17:37:32
Hallo Peter,
und jetzt noch eine logische sich aufzwängende Frage:
Du hast diese Tests mit der nicht funktionierenden FW gemacht - richtig?
Dann mach nochmal denselben Test mit der FUNKTIONIERENDEN großen Firmware. Dann wissen wir, ob das "der Unterschied" ist.
Ich bin sehr gespannt.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: peter_77 on 24. February 2018, 18:30:58
Hat er das nicht gemacht oben ? Da steht doch einmal gr. File und kl. unter Winblows 10
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 24. February 2018, 18:42:35
Du hast diese Tests mit der nicht funktionierenden FW gemacht - richtig?
Dann mach nochmal denselben Test mit der FUNKTIONIERENDEN großen Firmware. Dann wissen wir, ob das "der Unterschied" ist.
|
|
Genau - ich hatte die Tests u.a. mit der nichtfunktionierenden großen FW gemacht. Und hier nun das Ergebnis für die große funktionierende FW 2.9.8:
GET LINE CODING RESPONSE liefert initial nach den Einschalten:
00:00:00:00:00:00:00
Dann schickt der Host ein "SET LINE CODING REQUEST" mit der Baudrate 9600, der TRX antwortet mit
80:25:00:00:00:00:00 (Baudrate gesetzt auf 9600)
Dann ein weiteres "SET LINE CODING REQUEST",
und in der Response steht
80:25:00:00:00:00:08 Yesssss :)
Ich werde nochmal die beiden Traces der großen Firmwares 2.8.3 und 2.9.8 vergleichen - aber vielleicht sind wir nun einen Schritt weiter.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 24. February 2018, 18:50:45
Hat er das nicht gemacht oben ? Da steht doch einmal gr. File und kl. unter Winblows 10
|
|
Hallo Peter,
nein, das war die große 2.8.3, die ja nicht funktionierte.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 24. February 2018, 19:02:11
Hallo,
ich denke, wir kommen der Sache näher. Es ist gut möglich, das ungültige (oder ungünstige) Werte der Line-Codingdaten Probleme bei Windows 10 verursachen können, wenn sie zum Beispiel einer Plausibilitätsprüfung nicht standhalten. Da könnte man jetzt Windows nicht unbedingt einen Vorwurf machen. Die Werte a8:... sind keine gültige Konfiguration der serielle Schnittstelle.
Jetzt ist ja die spannende Frage, warum kommt mal 7x 0 und mal ein bestimmter Wert abhängig davon, ob FreeDV genutzt wird oder nicht, denn das ist ja der Unterschied zwischen "großer" und "kleiner" Firmware.
Erstmal ist es so, dass der Speicherbereich, der hier verwendet wird, nicht wirklich explizit im USB Treiber initialisiert wird. Das habe ich gerade geprüft. Das ist nicht gut, aber verursacht eben nur manchmal Probleme (wenn der Speicherbereich ungünstige Anfangswerte enthält). Um es genau zu sagen, wird der GET LINE CODING REQUEST im Treiber nicht wirklich richtig unterstützt, sondern einfach ein bestimmer Speicherbereich zurückgeschickt. Genau dieser Speicherbereich wird auch genutzt, wenn eine SET LINE CODING REQUEST empfangen wird. Deswegen (und nur deswegen) kommt bei einem nachfolgenden GET LINE CODING REQUEST auch die von Windows erwartete Antwort zurück.
Wenn wir hier den korrekten Support für GET LINE CODING / SET LINE CODING einbauen würden (was ich gleich erledigen werde), würden wir von Anfang an einen korrekt initialisierten Wert zurücksenden und das Problem wäre für alle Zeiten weg. Aber wir wissen dann immer noch nicht, warum das Problem bei der derzeitigen Implementierung MANCHMAL auftritt und es mit dem Nutzungsgrad des Speichers zu korrelieren scheint und wir wissen auch nicht, ob wir hier noch ein weiteres Problem schlummern haben.
Wie auch immer, jetzt kommt erstmal der Pull Request mit dem verbesserten Treiber.
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 25. February 2018, 08:40:04
Hallo Chris, hallo Peter, hallo Danilo,
danke für die wirklich gute und aufwändige Forensik und die Zusammenarbeit. Und für den Fix dafür.
Wir haben jetzt ein paar "neue Vermutungen" (oder - nur ich??)
Windows7 und Linux sind fehlertoleranter als Windows10. Das würde das unterschiedliche Verhalten erklären. Was wir noch nicht wissen ist warum das Ganze nur bei höherer Speicherauslastung auftritt. Da kann man aktuell noch wild die Glaskugel reiben (was aber nicht wirklich weiterhilft).
Ich würde das Ganze beim aktuellen Stand erstmal belassen - aber im Auge behalten. Und hier müsste ich mal wieder Dich bitten, Chris.... Du bist derjenige, bei dem die Konstellation aus Betriebssystem, mcHF und Anwendungsprofil so ist, dass Du den Fehler, sollte er erneut auftreten, als erster bemerkst. Es wäre sehr schön, wenn Du das bei Auftreten sofort melden würdest, damit wir (vielleicht wieder in Kooperation mit Dir, Peter?) die Sache weiter verfolgen können. Es ist IMMER gut, wenn man die Ursache für Fehlfunktionen kennt. Sollte es ein von oben in den ausgelasteten RAM reinwachsender Stack sein - hätten wir eine Erklärung. Aber vielleicht schlummert da noch irgendwas anderres (Danilo deutete es völlig korrekt an). Da sollte man nicht einfach zur Tagesordnung übergehen - insofern bin ich froh, dass ich hier "bissig" geblieben bin. Es hat uns einen Schritt weiter gebracht - Dank nochmal an Chris, Peter und Danilo.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 25. February 2018, 10:15:06
Ja, danke auch von mir, hat Spaß gemacht und wieder (etwas) dazugelernt. Wenn's wieder was zu tun gibt, sagt bescheid.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 25. February 2018, 11:07:09
Bis auf meine Hartnäckigkeit und meine Ideen zu den Ursachen konnte ich diesmal ja nicht wirklich beitragen. Aber dass wir alle wieder an dem Problem gelernt haben, das ist schon ein schöner Erfolg.
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 25. February 2018, 11:15:15
Hallo Peter,
wenn Du Lust hast, kannst Du nochmal ein Wireshark-Protokoll von der aktuellen Firmware (groß) machen.
Danke!
Ja, danke auch von mir, hat Spaß gemacht und wieder (etwas) dazugelernt. Wenn's wieder was zu tun gibt, sagt bescheid.
Gruß
Peter
|
|
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 25. February 2018, 16:02:01
Hallo Peter und andere,
ich kann jetzt bestätigen (da wir ja jetzt die initialen Werte im Code explizit setzen ), dass der Windows 10 Treiber mit initialen Werten a8:68:3e:9e:4b:5a:a9 fürs Linecoding keinen Spass versteht und die Schnittstelle für nicht gültig erklärt.
Mein Ubuntu 17.10 hingegen schert das nicht, funktioniert einfach. Und vermutlich macht Windows 7 auch keine Zicken.
Was lernen wir daraus? Bessere Fehlererkennung bringt nicht immer echte Vorteile...
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF8OE on 25. February 2018, 16:15:47
Und das Verhalten ist irgendwie inkonsistent. Bei Windows sind so viele Automaten integriert, die bei irgendwelchen Fehlern dem Anwender (meistens zumindest) erst gar keine Wahl lassen und einfach eigenmächtig irgendwas einsetzen, was dann funktioniert ("zuer Erleichterung des Nutzers") - aber man kann sich nicht drauf verlassen, dass diese Automaten überall sind. Sie sind an vielen Stellen - und keiner weiß wo.
Ich bin gespannt, ob das Problem jemals wieder auftaucht (wenn der RAM knapper wird)...
vy 73
Andreas |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 25. February 2018, 16:56:07
Hallo Andreas,
ich finde das Verhalten von Windows 10 grundsätzlich in Ordnung. Der Fehler lag ja eindeutig in unserer Seite der Software. Wir haben Windows Datenmüll geliefert, der in keinster Weise durch den Standard gedeckt ist. Das AUDIO Interface hat ja ohne Probleme funktioniert, auch unter Windows 10.
Und ich darf mal bemerken, das mein WSJT-X unter Ubuntu 17.10 nicht mehr bereit ist die mcHF Audio-Verbindung zu benutzen, fldigi geht aber. Das ist auch merkwürdig und ich habe damit schon Stunden zugebracht.
Dieses Rumgehacke auf dem einen oder anderen System ist einfach nicht zielführend, eine große Zeitverschwendung, und ich werde mich daran nicht weiter beteiligen. Jedes komplexe System hat, prinzipbedingt (sonst wäre es kein komplexes System), seine Schwachstellen.
So und jetzt noch ein paar Fakten: Derzeit (2.9.8) haben wir im mcHF 192k mit dem großen Binary etwa 13k "freien" Speicher, der zwischen unseren Datensegment und unserem Stacksegment liegt. Das ist nicht sehr viel und die eine oder andere Änderung, die in älteren Versionen war, könnte diesen Zwischenraum aufgebraucht haben und beliebig komische Fehler verursacht haben. Wenn ich nachher noch Lust habe, schaue ich mir mal die 2.7.83 an, was da an Zwischenraum (nicht) drin ist.
73
Danilo
|
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DF5LI on 25. February 2018, 18:17:25
| Dieses Rumgehacke auf dem einen oder anderen System ist einfach nicht zielführend, eine große Zeitverschwendung, und ich werde mich daran nicht weiter beteiligen. Jedes komplexe System hat, prinzipbedingt (sonst wäre es kein komplexes System), seine Schwachstellen. |
|
Wohl gesprochen, Danilo! Dieses überhebliche Getue von selbsternannten IT-Gurus mit Ausdrücken wie "Winblows Gurke" oder Windoofs geht mir auch allmählich auf den Zeiger... |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DL5DLA on 25. February 2018, 19:16:05
Hallo Danilo,wenn Du Lust hast, kannst Du nochmal ein Wireshark-Protokoll von der aktuellen Firmware (groß) machen.
|
|
Klar - hier ist es.
Gruß
Peter |
Title: Re:USB Treiber Probleme ab v2.7.83 - Berichte erbeten!!
Post by: DB4PLE on 25. February 2018, 20:56:50
Hallo,
jetzt nochmal die 2.7.83 Nachlese:
Die gute Nachricht: Wir haben keine Überschneidung des Datensegements mit dem Stacksegment. Es sind zwar nur ca. 10k Distanz (3k weniger als bei 2.9.8) aber trotzdem hier eher keine Gefahr.
Weitergehende USB Problemanalyse:
Bei mir kommen bei Get Line Coding zufällige Werte, die von Windows 10 aber durchgewinkt werden. Das hängt (wie angenommen) damit zusammen, das wir hier einen nicht "gelöschten", als nach dem Einschalten mit zufälligen Werten belegten Speicherbereich nutzen. Nun ist das ganze jetzt nicht so zufällig, sondern eher ähnlich. D.h. die Werte varieren ein wenig bei jedem Einschalten, aber nicht sehr stark (nur manche Bits um genau zu sein).
Das dürfte aber bei jeder Maschine anders sein, da der RAM nach dem Einschalten eben seine "zufällige" Konfiguration annimmt. Der hat keinen "alles auf Null"-Reset am Anfang.
Was ist die Essenz: Wir hatten einen Programmierfehler (danke STM, dein Code!), der sich abhängig von der jeweiligen Maschine UND der genauen Position dieser Daten im Speicher nur bei Windows 10 mal auswirkte und mal eben nicht.
Programmierfehler behoben, alles ist gut. Bis zum nächsten Fehler (der leider schon irgendwo auf uns wartet, um uns anzufallen...).
Damit ist dieser Thread wohl am Ende.
73
Danilo
|
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|