Hallo Heino,
danke für Deine schnelle Rückmeldung, dann liege ich ja mit meiner Beobachtung, was die verbesserte CPU-Auslastung anbelangt nicht verkehrt.
Zu meinen klappernden Relais ist zu sagen, dass ich in dieser Phase auch noch keine Verbindung zum Red Pitaya über die OpenHPSDR Software bekomme, sprich ich kann die Software nicht starten.
Meine These, der Prozess Boot oder anders gesagt die Initialisierung des Red Pitaya dauert mit der neuen Version länger (35-40 Sekunden, alte Version nur 1-2 Sekunden), somit sind bei mir die BCD Ausgänge in einem undefinierten Zustand, was dazu führt, dass der nachfolgende BCD/Dezimaldecoder undefiniert schaltet und meine Relais vom Tiefpassfilter anfangen zu klappern.
Ist der Vorgang am Red Pitaya abgeschlossen sind die Relais stabil und ich kann dann den Start Button ohne Fehlermeldung drücken.
Es liegt vermutlich auch an meiner Hardware Konstellation, dass dieses Verhalten der Software sich bei mir so zeigt. Auch in der alten Version haben die Relais kurz geklappert, aber nur 1-2 Sekunden.
Bevor ich aber was an der Hardware ändere (Pullup/Pulldown-Widerstände oder eine Select-Freigabe der BCD/Dezimaldecoder), warte ich nochmal was der ein oder andere zu berichten hat.
Viele Grüße
Jörg, DD8JM
Dieser Beitag wurde von einem OM in Github veröffentlich, was meine Beobachtung zum längerem Bootvorgang bestärkt.
Hello Pavel,
Thanks for unifying the Alpine "SD card" so the same can be used for the 125-14 and 122.88-16 model. It is really handy for people who like me own the two type boards
Unfortunately the work-around covered by this ticket does work any-longer as the structure of the start.sh file of the hpsdr transceiver for the 122.88-16 file has changed to be unified with the 125-14 one. The bottom line is that I can't change the eth0 (damaged on one of my boards) to the eth1 port (an external USB2 Ethernet adaper) manually in the start.sh file (as I used to do it before). Out of deduction, I found a work-around by simply ADDING the line below in the start.sh file
ip link add mvl0 link eth1 address $address type macvlan mode passthru
....but the establishment of the network connection is slow; much slower than on my other healthy boards (even when using the OTG port) and also slower than with the work-around that I used before you unified the two sd_cards . It looks the system keeps trying to use eth0 and only when it gives up it tries eth1.
I am wondering if you could advise something else (smarter) to speed-up the establishment of the connection on the eth1 port on that specific board ?.
Thanks
Regards
PS: Please note that on the healthy boards, for both the 122.88-16 and the 125-14 boards, I can use either the OTG or Ethernet port without having to fiddle around with the start.sh file..
. Auch hier würde mich interessieren wie es bei Euch ist.
