Pages: [1] 2 
|
 |
|
|
Author
|
Topic: "dies und das" zur Version vom 22.06.2017 (Read 4151 times)
|
|
dl8mby
alter Hase
 Offline
Posts: 363
Ich liebe dieses Forum!
|
 |
"dies und das" zur Version vom 22.06.2017
« 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.
|
|
 Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #1 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
|
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #2 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
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #3 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
|
|
Logged
|
|
|
|
|
|
DD4WH
positron
alter Hase
Offline
Posts: 462
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #5 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
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. 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
|
| « Last Edit: 27. June 2017, 18:15:08 by DD4WH » |
Logged
|
-----------------------------------------
Teensy Convolution SDR
https://github.com/DD4WH/Teensy-ConvolutionSDR
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #6 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #7 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #8 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #9 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.
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #10 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #11 on: 27. June 2017, 21:24:43 »
|
|
Habe noch vergessen meine Config-Anzeige
dranzuhängen. Vielleicht ist das hilfreich.
Markus
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #12 on: 27. June 2017, 21:26:27 »
|
|
Teil zwei der HW-Config.
Jetzt reicht es aber für heute - versprochen.
Markus
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 22.06.2017
« Reply #14 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
|
|
Logged
|
|
|
|
Pages: [1] 2 
|
|
|
|
|
|
|
calc_rx_dbm_sig_strength.txt
Dieses Paket musste ich nachinstallieren: libstdc++-arm-none-eabi-newlib
