Title: "dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 06:58:01
Hallo werte OM's und Foristen,
ich habe einige Anmerkungen/Beobachtungen zu der Software zu machen,
die am 22.06 zum Download bereitgestellt wurde. Die neuste Version vom
25.06 habe ich noch nicht aufgespielt.
Mach dem ich am Wochenende eine weiteren mchf Empfänger-Mäßig in
Betrieb genommen habe, sind mir beim Messen der Empfindlichkeit einige
Dinge aufgefallen, die ich hier zur Diskussion stellen möchte.
1) Beim Zuführen des Messender-Signals (-130dBm bis -30 dBm) stellte ich
fest, dass die maximale Anzeige am mchf in dBm und am S-Meter nicht
in der Filterposition im Spektrum, sondern direkt auf der eingestellte QRG
angezeigt wird.
Stelle ich das Filter z.B. auf 500-750 bei CW-U im 30m Band, QRG 10.110kHz,
dann habe ich nicht mein Empfangs-Maximum bei 10.110+0.625kHz, sondern
bei 10.110kHz. Der RX steht fest auf 10.110kHz und der Messender (R&S SMY01) wird in 10Hz Schritten von 10.109kHz bis 10.111kHz durch gestimmt.
Die größte Empfangsfeldstärke wird aber bei 10.110kHz angezeigt und nicht dort,
wo das Sendesignal auf das Filter trifft. Das verwirrt mich und ich frage mich,
ob ich einen Denkfehler mache oder noch an der Software nachjustiert werden muss.
2) Bei dem o.g. Messungen ist mir auch aufgefallen, dass wenn man ein
Empfangssignal mittels DSP/Peek hervorheben will und die Peek-Audio-Frequenz
durchstimmt, kurz vor der Position an der das Signal in den Peek hineinpasst,
die Software des mchf's sich aufhängt. :-(.
Beim Notch passiert dies nicht. Vielleicht können die SW-Entwickler mal das
nachprüfen, ob Sie das gleiche Verhalten reproduzieren können.
Meine erreichte Empfindlichkeit bei der unter Punkt #1 geschilderten Messung
lag bei -133dBm bei einer Bandbreite von 1,4kHz (LPF).
Bei den CW-Bandbreiten ist dieser Wert aus dem o.g. Grund 6 bis 12 dB
schlechter. Nur Filtereinstellungen, die das (LPF) in der Anzeige haben
reichen bis knapp an den Träger heran und haben damit den größten Aus-
schlag am S-Meter.
vy73
Markus
DL8MBY
PS.: Ich habe die Beobachtung nicht bei den Issues im github reingestellt,
weil ich erst Eure Meinung dazu wissen wollte.
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 12:53:21
Hallo OM's,
Hallo OM Frank DD4WH,
ich habe mich etwas durch den mcHF Code vom 25.06
gekämpft und quer gelesen, siehe Anhang.
Dabei bin ich auf die Procedure UiSpectrum_CalculateDBm()
gestoßen, die den Feldstärkewerte berechnet.
Noch bin ich nicht ganz vertraut mit der Funktion.
Fremden Code muss man ja erst folgen können.
@Frank,
vielleicht kannst Du ja ein paar Deiner Überlegungen beim
Erstellen/Erweitern der Subroutine hier posten, damit ich
es besser verstehen kann, was da passiert.
Vielen dank im Voraus
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 27. June 2017, 12:56:52
Hallo werte OM's und Foristen,
ich habe einige Anmerkungen/Beobachtungen zu der Software zu machen
...
1) Beim Zuführen des Messender-Signals (-130dBm bis -30 dBm) stellte ich
fest, dass die maximale Anzeige am mchf in dBm und am S-Meter nicht
in der Filterposition im Spektrum, sondern direkt auf der eingestellte QRG
angezeigt wird.
|
|
Das ist zur Zeit richtig. Da das Filter für die Anzeige der Feldstärke und das gewählte NF-Filter nicht das gleiche ist (genauer gesagt: die haben zur Zeit nichts miteinander zu tun) ist das Im Moment so. Aber wir werden irgendwann mittelfristig den ganzen Audio-Pfad umkrempeln, dann kommt das ins Lot.2) Bei dem o.g. Messungen ist mir auch aufgefallen, dass wenn man ein
Empfangssignal mittels DSP/Peek hervorheben will und die Peek-Audio-Frequenz
durchstimmt, kurz vor der Position an der das Signal in den Peek hineinpasst,
die Software des mchf's sich aufhängt. :-(.
Beim Notch passiert dies nicht. Vielleicht können die SW-Entwickler mal das
nachprüfen, ob Sie das gleiche Verhalten reproduzieren können.
|
|
Eben nachgestellt: Kann ich nicht reproduzieren. Bei meinen mcHFs stürzt nichts ab.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 13:19:06
Hallo Andreas,
ich werde das heute mit der Version vom 25.06 nochmals versuchen.
Signal bei mir war bei (-90dBm und -70dBm) ich habe das CW Filter
an mit 500-750 im CW-U auf 30m und drehe den Peek von 1000Hz
runter gegen 550Hz. Dann bleibt der mcHF hängen und ich muß ihn
hart von der Versorgung nehmen.
Werde heute ein Bild machen, wenn es bei der neusten Firmware
auch so sein sollte.
Derweil danke für die Mühe.
vy73
Markus
DL8MBY |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 27. June 2017, 13:45:35
Hallo Markus,
ich habe fast das gleiche Szenario verwendet, nur habe ich auf 3600 KHz in CW-L getestet. Filter war das gleiche. Auf zweien der mcHFs ist die FW vom 22.06., auf dem dritten die neueste vom 25.06.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DD4WH on 27. June 2017, 18:13:59
Hallo Markus,
vielen Dank für Deine Messungen und Beobachtungen!
ich musste da selber erst mal nachschauen, das ist schon eine Weile her, seit ich den dBm-code gebaut habe. Hier sind erste allgemeine Infos zu finden:
https://github.com/df8oe/mchf-github/wiki/S-Meter-&-dBm-Hz-display (https://github.com/df8oe/mchf-github/wiki/S-Meter-&-dBm-Hz-display)
Der code ist -wie Du ja schon herausgefunden hast- im ui_spectrum.c in
static void UiSpectrum_CalculateDBm()
Die Basis ist die FFT der eingehenden I&Q-Werte, die ja sowieso schon für das spectrum display/waterfall berechnet wird. Aus dieser FFT nehme ich dann die bins innerhalb der Filterbreite und berechne die Summe dieser bins und skaliere und logarithmiere, bis daraus die Leistung innerhalb der Filterbandbreite geworden ist:
Lbin ist das unterste bin innerhalb der Filterbandbreite
Ubin ist das oberste bin innerhalb der Filterbandbreite
// determine the sum of all the bin values in the passband
for (int c = (int)Lbin; c <= (int)Ubin; c++) // sum up all the values of all the bins in the passband
{
sum_db = sum_db + sd.FFT_Samples[c];
}
Und hier folgt nun mein Fehler bei der Berechnung von Lbin und Ubin: Du hast völlig recht, ich habe nur den lowpass-Fall implementiert:
switch(ts.dmod_mode)
{
case DEMOD_LSB:
bw_USB = 0.0;
bw_LSB = width;
break;
case DEMOD_USB:
bw_LSB = 0.0;
bw_USB = width;
break;
case DEMOD_CW:
if(ts.cw_lsb)
{
bw_USB = 0.0;
bw_LSB = width;
}
else
{
bw_LSB = 0.0;
bw_USB = width;
}
break;
case DEMOD_DIGI:
if(ts.digi_lsb == true)
{
bw_USB = 0.0;
bw_LSB = width;
}
else
{
bw_LSB = 0.0;
bw_USB = width;
}
break;
default:
bw_LSB = width;
bw_USB = width;
}
// calculate upper and lower limit for determination of signal strength
// = filter passband is between the lower bin Lbin and the upper bin Ubin
Lbin = (float32_t)posbin - roundf(bw_LSB / bin_BW);
Ubin = (float32_t)posbin + roundf(bw_USB / bin_BW); // the bin on the upper sideband side
Im code wird also in SSB/CW bw_USB bzw. bw_LSB = 0.0 gesetzt, hier müsste man jedoch auf jeden Fall die jeweilige untere/obere Grenze des Bandpass-Filters ansetzen. Die Werte stimmen also nur für den lowpass-Fall.
Markus, hättest Du Lust/Zeit, das zu ändern und dazu einen pull request zu machen?
Ich bin arbeitsmäßig noch die nächsten Wochen sehr stark eingespannt, daher wird das bei mir erstmal nix . . . Aber sehr gut ist, dass der Fehler erstmal identifiziert ist! Wenn Du keine Zeit hast, mache ich das gerne, aber wie gesagt, nicht in den nächsten Tagen ;-).
[Einnschränkend möchte ich aber auch noch sagen, dass die dBm-Anzeige nur bei magnify == 1 wirklich genau und konsistent anzeigt. Das liegt an den decimation-Filtern, die in der ZoomFFT verwendet werden, die haben aus Gründen der Recheneffizienz nur eine stopband attenuation von 50dB --> gilt nur für die Anzeige, nicht für die Audio! mehr dazu hier: https://github.com/df8oe/mchf-github/wiki/Spectrum-display-Magnify-mode-=-Zoom-FFT (https://github.com/df8oe/mchf-github/wiki/Spectrum-display-Magnify-mode-=-Zoom-FFT). Und bei der Genauigkeit auch immer an die frequenzabhängig unterschiedlichen Dämpfungen durch die Bandpass-Filter denken! ]
Have fun with the mcHF!
73 de Frank
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 20:29:10
Hallo Andreas,
ich habe es nochmals versucht und es hat zwar einige Male
gedauert, bis ich den Zustand wieder erreicht habe mit der
FW vom 22.06 alias 2.2.10.
Siehe Bild.
Leider läuft bei mir die FW vom 25.06 alias 2.3.9 erst gar nicht
an. Bildschirm friert sofort ein.
Fortsetzung siehe nächsten Beitrag.
Markus |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 20:38:06
Fortsetzung.
Die FW 2.3.9 versuche ich gerade zu kompiliere, dauert etwas auf
meinem Notebook.
Das einfrieren passiert mit der originalen FW vom OV I40.
Meine mchf's verwenden als MC den ST32F429 und den ST32F439.
Das EEPROM ist der 1025-Type.
Man sieht zwar den Startbildschirm, dann bleibt aber die folgende
Darstellung hängen.
Siehe Bild. #1 vom Update auf FW 2.3.9
Markus |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 20:40:39
Fortsetzung
Beim Abhängen vom Akku und Wiedereinschalten nach einigen
Minuten, bleibt der TRX wieder leider hängen.
Nun sieht man einen geringfügig anderen Bildschirm.
Siehe Bild #2.
Markus |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 20:55:13
Fortsetzung
Leider ist mein Kompilerlauf mit einem Fehler ausgestiegen:
Jemand eine Idee, worans liegt?
Diskspace ist ausreichend vorhanden und /tmp ist auch
ausreichend groß.
[CC] basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/BasicMathFunctions/arm_sub_q7.o
[LD] fw-mchf.elf
arm-none-eabi-g++: error: nano.specs: No such file or directory
Makefile:245: recipe for target 'fw-mchf.elf' failed
make: *** [fw-mchf.elf] Error 1
Hat wohl was mit dem Eintrag
LDFLAGS_F4 := $(MACHFLAGS_F4) -flto --specs=nano.specs
in dem Makefile zu tun.
Nachdem ich das "--specs=nano.specs" auskommentiert habe,
ist ein fw-mchf.bin erzeugt worden.
Als Toolchain habe ich
arm-none-eabi-gcc (openSUSE 5.4.0_20160622-3.19) 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715]
installiert.
Werde jetzt meinen Build testen.
Bis gleich.
PS.: @Frank
Frank ich melde mich Morgen via PN, falls es das QRL zulässt.
Wiir können dann die einzelnen Schritte, die notwendig sind
besprechen. Danke derweil für die jetzigen Infos.
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 21:21:55
So da bin ich wieder ;-)
Gute Nachricht, ich konnte die FW erfolgreich via USB Stick
einspielen, was jetzt übrigens sehr gut klappt, dank Andreas
tollem Bootloader.
Bis dato habe ich mich mit dem STLink Flasher abgemüht.
Nun zum Problem Peek, das weiterhin besteht aber eine etwas
andere Historie zeigt.
Siehe neues Bild.
Ich wollte wieder den Peek Einstellen, der aber schon im Menu
eingestellt war. Bevor ich den zu verändern beginne, dachte ich
stell doch erst mal das Filter auf 500-750 und dann erst den
Peek variieren.
Bevor ich überhaupt soweit war, bleibt der Bildschirm bei der Wahl
des Filters (von 1.4k LPF zu 500Hz-750Hz) eingefrohren stehen.
Leider.
Was mir noch aufgefallen ist, das meine FW nach dem
Compilieren im Display die Version 2.3.8 und nicht 2.3.9 zeigt.
So nun habe ich Euch genug für heute genervt.
Jetzt gehe ich ins Bett.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 21:24:43
Habe noch vergessen meine Config-Anzeige
dranzuhängen. Vielleicht ist das hilfreich.
Markus |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 27. June 2017, 21:26:27
Teil zwei der HW-Config.
Jetzt reicht es aber für heute - versprochen.
Markus
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 28. June 2017, 06:46:03
Hallo Markus,
der Fehler mit dem "nano" deutet auf eine fehlende Bibliothek hin - hatte ich auch auf meiner am WE gerade neu eingerichteten 64 Bit Maschine ::) Dieses Paket musste ich nachinstallieren: libstdc++-arm-none-eabi-newlib
EDIT:
Diese hier hast Du ja hoffentlich schon:
libnewlib-arm-none-eabi
Zu den sonstigen von Dir geschilderten Dingen kann ich nur sagen, dass sich keiner meiner mcHFs im Peak (oder sonstwo) aufhängt oder abstürzt und dass alles einwandfrei läuft. Ich kann hier also nicht wirklich etwas zu einer Fehlersuche beitragen.
Ich verwende die gleichen Prozessoren und den gleichen EEPROM. Auf einem der mcHFs läuft noch das olle 2.8" LCD im parallel-Mode, auf den anderen läuft das 3.2" im parallel und im SPI Mode. Alles läuft, nichts stürzt ab. Eventuell doch ein Hardwarefehler?
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 28. June 2017, 07:15:31
Hallo Andreas,
danke für Deine Erläuterung und Hinweise.
Werde weiter suchen und wenn ich was konkreteres finde,
dann werde ich berichten.
Zu dem Linkerswitch "--specs=nano.specs" kann ich sagen,
dass mein Fehler verschwand, als ich diesen deaktiviert habe.
Ich kann mich aber wage erinnern, das bei mir die newlib für
ARM Controller installiert ist.
Es war ja auch seltsam, daß die original FW 2.3.9 von Deinem
Server sich nach dem Flashen via USB-Stick aufhing und ich
nicht mal in der Lage war die Vorgängerversion (2.2.10) wieder
zum Laufen zu bringen.
Kann man eigentlich die Configwerte innerhalb des Bootvorgangs
auf Defaultwerte zurücksetzen? Habe leider dazu nichts gefunden.
Nachdem ich mein Compilat eingespielt habe (2.3.8), läuft der TRX
wieder durch den Bootvorgang durch und zeigt das gewohnte Bild
der GUI.
Leider ist das Peek-Problem immer noch vorhanden.
Ich muss aber dabei erwähnen, das meine Wasserfalldarstellung im
Zoom-Mode (2x) läuft. Kannst Du bitte mal damit noch einen Versuch
machen.
Danke im Voraus.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 28. June 2017, 07:21:20
Hallo Markus,
Du brauchst die BEIDEN von mir erwähnten newlibs! Eine fehlt bei Dir (bin ich mir fast sicher).
Habe eben gerade in magnify x2 probiert: alles ok, läuft. Kein Absturz.
Hier gibt es Infos zum Setzen einer default-config beim Booten:
https://github.com/df8oe/mchf-github/wiki/Operating-Manual
Recht weit unten bei der "Key Press Map".
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 28. June 2017, 12:08:40
Hallo Andreas,
danke für Deinen erneuten Test.
Was den Reset der Config auf die default Werte
angeht so habe ich entweder Tomaten auf den Augen,
oder Du hast mich missverstanden.
Ich meine einen Reset der Config, der nachdem man die
FW neu geflasht hat, durch eine bestimmte Key-Kombination
ausgelöst werden kann, wenn man quasi das erste mal mit der
neuen FW bootet.
Wenn der mchf schon erfolgreich gestartet ist, kann man die
Config im Menu resetten.
Oder meinst Du die Kombination F1+F3+F5 "Ask for Reset to
Default Config" - habe ich gerade entdeckt.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 28. June 2017, 12:39:38
Ja, genau die meine ich. Dann wird eine Default-Config geladen BEVOR der mcHF gestartet ist. Und die bestehende Config im EEPROM wird erst überschrieben, wenn Du entweder den mcHF (mit Abspeichern) ausschaltest oder Du mit langem Druck auf die Menü-Taste speicherst.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 28. June 2017, 13:11:02
Danke,
wieder was gelernt.
PS.: Ist eigentlich ein Treffen (offiziell/inoffiziell) der mchf Fans/Nutzer
auf der HAM-Radio geplant?
vy73
Markus
DL8MBY |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 28. June 2017, 14:23:23
Bis jetzt noch nicht. Da Friedrichshafen für mich immer eine "Weltreise" ist, bin ich leider nicht mit dabei. Aber es sind sicher viele andere dort! Am Beten machst Du einen eigenen Thread auf und ihr verabredet euch. Hat mit Kassel prinzipiell auch geklappt - nur war der Treffpunkt nicht eindeutig genug beschrieben. Da ist/war noch Platz für Optimierungen ::)
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 05. July 2017, 13:59:17
Hallo Andreas,
hallo Danilo,
mir scheint, dass Ihr schon den Bug, der in Github unter
https://github.com/df8oe/UHSDR/issues/930
"S-meter not working with small bandwidth filter in CW"
steht, Bereits behoben habt - ist das richtig?
Frank, DD4WH hat mich motiviert mir diese Codepassage
anzusehen und mal zu versuchen dieses Problem zu fixen.
Dies scheint allem Anschein nach jetzt gefixt zu sein.
Werde mir das Daheim an meinem Messequipment ansehen
und bestätigen, falls es dem so ist.
Danke das das so schnell gegangen ist.
Da kann ich leider nicht mithalten :-).
vy73
Markus
DL8MBY |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DB4PLE on 07. July 2017, 11:32:05
Hallo Markus,
so ist es. Die Geschichte wurde von mir nach bestem Wissen und Gewissen erledigt. Kannst Du gerne prüfen, denn nicht jede richtige Idee wird auch so implementiert, das es immer richtig funktioniert....
73
Danilo |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 08. July 2017, 13:52:34
Hallo Danilo,
ich kann bestätigen, dass beim Messen mit dem
Signalgenerator nun die maximale Signalstärke
in der Mitte des Filters angezeigt wird.
Bei meinem mchf kann ich nun von -110dBm bis
-30dBm mit einem Korrekturfaktor von -5dBm im
Menu auf +-1dBm genau messen. Tolle Sache.
Meinen besten Dank dafür - und wie man so schön
sagt - "well done"
vy73
Markus
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 08. July 2017, 14:02:22
Hallo Markus,
stürzt dein mchf immer noch bei der Funktion "Peak" ab? Wenn ja: Bist Du weitergekommen?
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: dl8mby on 08. July 2017, 14:54:34
Hallo Andreas,
ja leider habe ich immer noch das Problem mit dem Peek.
Dabei gibt es vier Varianten - siehe 1 bis 4:
Ich habe dieses Phonemen nur im CW-L/CW-U und
bei den Filterbandbreiten bis 1.4kHz von unten kommend
ausprobiert. Andere Bereiche/Modes habe ich nicht getestet.
1: kein Signal im Empfangsbereich, Menu Peek ausgewählt.
Default wert der Peek-Frequenz wird angezeigt.
Ich verändere die Peek-Frequenz nicht, sondern nur
den Frequenz-Abstimknopf.
Meist passiert dabei kein Hänger, egal ob schnell oder
langsam gedreht wird.
2: kein Signal im Empfangsbereich, Menu Peek ausgewählt.
Verdrehen der Peek-Frequenz.
Meist passiert dabei kein Hänger, egal ob schnell oder
langsam gedreht wird.
3: Signal im Empfangsbereich, nicht zu stark, Menu Peek ausgewählt.
Ich verändere die Peek-Frequenz nicht, den Frequenz-Abstimknopf
verdrehe ich zum Signal hin bis es in den Filterdurchlass-
bereich hineinläuft..
Sehr oft passiert dabei der Hänger, egal ob schnell oder
langsam gedreht wird.
Dabei wird ein Dauerton ausgegeben, der nicht mit dem
zuvor gehörten Ton im Filterdurchlasbereich gleich ist.
4: Signal im Empfangsbereich, nicht zu stark, Menu Peek
ausgewählt. Signal steht bereits im Filterdurchlassbereich.
Ich verändere die Peek-Frequenz , den Frequenz-Abstimknopf
lasse ich auf der eingestellten QRG stehen.
Sehr oft passiert dabei der Hänger, egal ob schnell oder
langsam gedreht wird. Meist wenn man von der Default-
Peek-Frequenz runter dreht. Bereich um 750 bis 550 Hz.
Dabei wird ein Dauerton ausgegeben, der nicht mit dem
zuvor gehörten Ton gleich ist.
So ich hoffe durch Cut&Paste keine Fehler reingebracht zu haben,
aber das sind meine Beobachtungen.
Da ich aber gerade kurz vor dem Aufbruch mit meiner XYL ins
Wochenende bin, werde ich diesmal nicht "Spielen" können ;-)
vy73
Markus
DL8MBY
PS.: Ich hätte noch ein Paar Anmerkungen zum neuen TRX
des OVs I40, schaffe es aber erst am Montag hier zu posten.
Bis dahin allen ein schönes und/oder produktiver WE.
|
Title: Re:"dies und das" zur Version vom 22.06.2017
Post by: DF8OE on 08. July 2017, 15:22:40
Hallo Markus,
viel Spaß!
Ich habe eben nochmal 20 Minuten lang versucht anhand deiner Beschreibung das Problem bei mir zu reproduzieren. Keine Chance. Bei mir hängt sich nichts auf und nichts bleibt stehen / stürzt ab / erzeugt einen Dauerton. Alles "works as expected"...
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|