RSRQ/RSRP

      Dann hat er die beim Downgrade also nicht ersetzt...
      Eventuell einfach, weil die Versions-Nr. höher war.

      Vielleicht müsste man die lte_version.ini vorher patchen - also die Versions-Nr. auf einen Wert unter den der .053 setzen.
      (damit der SPH denkt, die LTE-FW der .053 ist höher und macht beide Updates)

      kann man nur raten - schön wär's gewesen :(

      mfg, emkay

      Ich glaub' nicht, das es da Probleme geben kann:
      wie gesagt ist /var/lte_fota nur ein Mount-Point ==> wohin der zeigt, bestimmt die gerade aktive Firmware...
      Also auch wenn der Bereich sich verschieben würde, würde der Moint-Point trotzdem an die richtige Adresse zeigen.
      (das ganze scheint auf eher hoher Ebene - also nich so hardware-nah zu sein)

      Im Grunde scheinen das 2 voneinander getrennte Firmwares in einer Datei zu sein - aber nur bei der MIPS-Firmware können wir direkt bestimmen, wann die ersetzt werden soll - die LTE-Firmware wird ersetzt, wenn 1. in der Gesamt-Datei eine LTE-FW vorhanden ist und 2. diese neuer ist als die Installierte.

      Deshalb müsste man wohl vor dem Einspielen der .053 dafür sorgen, das der SPH denkt - die installierte LTE-FW ist älter.

      mfg, emkay

      Soo... ich war mal so frei und hab' versucht die alte LTE-FW in meinen SPH(.012) einzuspielen...
      ...leider ohne Erfolg.

      1. Versuch: einfaches Austauschen ==> passiert gar nix - Router bootet normal - LTE-FW laut WebUI unverändert.
      2. Versuch: zusätzlich lte_need_update.ini auf '1' gesetzt ==> beim Boot blinken für eine Weile alle LTE-LEDs - LTE-FW aber unverändert.
      3. Versuch: LTE-FW-Versions-Strings angepasst (in der lte_fota.bin) von SPH-FW .053 auf .010 und LTE-FW .112 auf .112z ==> Ergebnis wie 1.
      4. Versuch: zusätzlich lte_need_update.ini auf '1' gesetzt ==> Ergebnis wie 2.

      Also: setzt man lte_need_update.ini auf '1', scheint der SPH beim Boot wirklch zu versuchen, eine neue LTE-Firmware aus dem LTE-Netz zu beziehen - währenddessen blinken die LTE-LEDs. Sonst passiert dabei aber nix.

      Uns fehlt noch ein Schritt: wir können zwar die lte_fota.bin an die richtige Stelle schreiben - aber irgendwie muß man danach auch den Flash-Vorgang starten... (irgendwo ist evtl. noch ein Flag oder Binary - welches das anstößt)

      mfg, emkay

      eMKay77 schrieb:

      hefr54 schrieb:

      In /var/lte gibt es noch einen Wert Signallevel "5" vielleicht ist das die Schraube

      Nöö, das is nur die gecachte 'Balken-/LED-Anzahl' für's WebUI...

      ich schätze mal, irgendwas mit upg und/oder cwmp - also den Router-Upgrade-Tools von Huawei.

      mfg, emkay


      also als mal meinen Upgrade Vorgang (mit der 10er Version) beobachtet habe hab ich in der Console folgendes gesehen:
      Vielleicht hilfts:
      upg -v -f /var/image.head.bin -c web

      Brainfuck-Quellcode

      1. Verify head ok. 0
      2. web head check ok .
      3. ************************Write db to flash now ...
      4. done sync
      5. UPG_PrepareUpgFlag::current is SLAVE, change to MAIN_FF
      6. ulupgSize 0x20000
      7. uloffset 20000
      8. .Upgrading finished
      10. ulupgSize 0x213c000
      11. uloffset 160000
      12. ..........................................................................................................................................................................................................................................................................Upgrading finished
      13. --- Upgrade LTE module, data length is 23005936, version is H1331.11.994.13.112c ---
      14. LTE module sw version is H1331.11.994.13.112c
      15. LTE module's version not change, do not update LTE
      16. ATP_UPG_Upgrade :: change upg flag to ss
      17. UPG_ChangeUpgFlag::change to SLAVE_SS


      Da hatte ich das Update allerdings schon drauf und hatte die Haupt-FW noch mal neu ausgelöst.... daher kein erneutes Upgrade des LTE-Teils....

      @hefr54: die rote LED des SPHs hab' ich zum Blinken gebracht, beim Versuch die .053er-LTE-FW in den SPH zu prügeln... :D
      das richtige Tool ist wohl upg - die Frage ist aber mit welchen Parametern. (und der wichtigste -m funktioniert scheinbar nicht, der setzt den FW-Typ - also ob rootfs oder lte zB.)

      da aber mittlerweile scheinbar klar ist, das der SPH wohl durchaus einen niedrigeren RSRQ erreichen kann - ihn nur nicht anzeigt, bin ich erstmal wieder davon ab gekommen.

      mfg, emkay

      findest Du denn die UPGAPI-libupgapi.a-V1.01-svn88146-dirty im Quellcode?

      ich finde so etwas wie:
      1 Firmware Upgrade Image /var/upg.bin
      3 Vendor Configuration File /var/tmpcfg.xml
      1 Vendor Configuration File /var/tmpcfg.bin
      /var/log.txt cwmp mic /var/upgradestatus upgrading atpv
      %s.

      echo 1 > /var/restoreflag
      echo %s > /var/upgupgradeflag


      PG_PrepareUpgFlag::current is SLAVE,
      change to MAIN_FF

      UPG_PrepareUpgFlag::
      change upg flag to ss

      UPG_ChangeUpgFlag::
      change to SLAVE_SS

      UPG_ChangeUpgFlag::
      change to MAIN_SS

      Moin @hefr54:

      hefr54 schrieb:

      Mit der Berechnung kann es nicht zusammenhängen den RSSI und
      SINR sind ja voll am Anschlag

      Wir wissen ja längst, das der SPH (vielleicht dann auch andere Huaweis) sich da verrechnen und den Wert bei -6dB kappen...

      Dazu kommt aber, das es für manche Messwerte verschiedene Wege gibt, diese zu erhalten - also mehrere AT-Kommandos mit gleichen oder überlappendem Funktionsumfang.
      Manche dieser Befehle geben die Werte direkt aus - die älteren jedoch geben einen Index zurück, welcher zurückgerechnet werden muß. Diese Tabellen sind dummerweise für manche Werte ungenau (zB. eine Index-Stufe==2dB) und sind unten und oben gekappt (alles was besser/schlechter als diese festen Grenzen ist - wird nicht mehr genau angezeigt, sondern eben nur der Grenzwert)

      Die Genauigkeit ist also auch davon abhängig, welche der verschiedenen AT-Kommandos das jeweilige Messprogramm nutzt.

      mfg, emkay

      hefr54 schrieb:

      Ich sage es mal so, es wird bei Huawei einfach der in der SW festgelegte größte Wert angezeigt und fertig.

      da hast Du mich falsch verstanden - das mit dem Grenzwert war nicht direkt auf den RSRQ bezogen, sondern eher allgemein.
      Ein Teil der älteren AT-Kommandos haben eine Mindest-/Maximalwert - was besser oder schlechter ist, wird dann einfach auf die Grenze gesetzt.
      Der RSRQ wie er zB. von sphfreq ausgelesen wird, ist allerdings kein Index - er sollte eigentlich stimmen. Ist aber nun nachweislich auf -6dB limitiert. (wir haben ja im Graph gesehn, das der anhand RSRP/RSSI selbst berechnete RSRQ sehr wohl bis -3dB geht)

      Allerdings kann auch der RSRQ von sphfreq aus solch einem Index berechnet worden sein - von der API selbst:

      Quellcode

      1. 0 rsrq < –19.5 dB
      2. 1 –19.5 dB ≤ rsrq < –19 dB
      3. 2 –19 dB ≤ rsrq < –18.5 dB
      4. …
      5. 32 –4 dB ≤ rsrq < –3.5 dB
      6. 33 –3.5 dB ≤ rsrq < –3 dB
      7. 34 –3 dB ≤ rsrq

      Ist die eigentliche Tabelle des AT^HCSQ - wie Du siehst ist die Genauigkeit rund 0.5dB im Bereich von -19.5 bis -3...
      Nutzt der Router/das Messprogramm intern diesen Befehl - ist die Ausgabe schon recht genau. Es gibt aber eben auch ältere/kompatiblere Befehle mit anderen/ungenaueren Wertebereichen. (dafür funktionieren sie bei einer größeren Zahl an unterschiedlichen Sticks/Modulen)

      mfg, emkay