RSRQ/RSRP

      @hefr54: dann ersetz doch mal die LTE-Firmware-Datei durch die der alten .053 :D
      (die wird, wenn ich mich nicht irre, erst beim Boot aus dem Linux-System in das LTE-Modul geladen....)

      mfg, emkay

      EDIT: zur Erklärung: nicht jede FW-Version bringt auch ne LTE-FW mit. Weshalb ein Downgrade eventuell die LTE-FW nicht 'zurück' überschreibt. Aber die .053 dürfte die Ur-LTE-FW haben...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()

      Im SPH-RootFS gibt's unter /var/lte_fota 'ne LTE-FW - wenn man die Dateien dort ersetzt (evtl. das 'needs-update-flag' auf 1 setzt) und rebootet, könnte das was werden...

      Wenn sich der RSRQ aus RSSI und RSRP berechnet - kann doch der rsrq nich als einziger limitiert sein.... (kennt jemand den passenden 'Resource-Blocks'-Wert? - dann würd' ich meinen LTE-Graphen mal um den berechneten rsrq ergänzen, um Abweichungen sichtbar zu machen.)
      EDIT: ok, hab' die Werte/Formeln ;)

      mfg, emkay

      @hefr54: das war damals ein Problem von BinWalk - hab' ich gemeldet - sollte behoben sein. Der 'Aufräum-Parameter' sollte jetzt auch für jffs2-be funktionieren...

      Im Anhang mal ein Screen - Blau ist RSRQ wie gemeldet, Pink ist berechnet. (pink-punkte bewusst etwas kleiner, damit man besser sieht, wenn auf anderem Punkt)

      Leider sind meine Werte nicht gut genug, um sicher zu sagen, daß es nich nur Rundungsfehler des LTE-Moduls sind.

      mfg, emkay

      EDIT: die pinkfarbenen sind nicht gerundet.
      Bilder

      • Screenshot_2016-04-05-20-14-51.png

        222,16 kB, 1.280×800, 385 mal angesehen

      Um ein künstliche Grenze zu finden - bräuchte ich 'bessere' Messdaten. => wenn blau und pink dann auseinander triften....

      Der RSRP in den 1800er Zellen is mies, reicht aber in der '142' trotzdem noch. Lustig ist, das etwa auf der Hälfte ein Zellwechsel stattfand (die kleine Zahl am oberen Rand ist die Zelle) - die Signalwerte aber fast gleich bleiben.
      Nur meine 800er ist stärker - dafür ist die immer voll....

      mfg, emkay

      @hefr54: das Graphen lesen üben wir noch mal... :D

      unten von inks nach rechts => Uhrzeit
      oben, die kleinen, 3-stelligen Zahlen => Funkzelle (nur dort, wo wechsel)

      also ist klar, das die Bilder sich 'überlappen', weil der zeitliche Abstand unter 2 Stunden ist - aber gleich sind sie nicht. (zur selben Zeit sind natürlich die gleichen Daten... neuere Daten sind rechts)
      Das 2. zeigt insgesamt 3 verschiedene Zellen: 142, 419, 354 (800er, deshalb Hintergrund violett)

      Der Graph zeigt also keine Kurzzeitmessung, sondern immer die letzten 2 Stunden meines minütlichen LTE-Logs. (das Log läuft bei mir immer mit - schon seit Tagen :D )

      mfg, emkay

      EDIT: hier sieht man's besser... die 419 links ist 1800er etwa 3km, 354 mitte ist 800er in Sichtweite, 142 rechts ist 1800er in 9km...
      Bilder

      • Screenshot_2016-04-05-22-17-49.png

        212,04 kB, 1.280×800, 383 mal angesehen

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()

      nee, mein rsrq geht bis -7/8 wenn's nacht is und wetter gut :)
      und bis -12 bei Last...
      und im Graph ist ein Strich=2db ist nur ne 5er-Unterteilung (wenn man genau guckt, sieht man Punkte 'zwischen' Strichen), werde die Y-Achse noch splitten, damit mittig nich so viel Platz verschwendet wird...

      EDIT:

      Quellcode

      1. 201604052201 18150 3 142 -105 -9 -75
      2. 201604052202 18150 3 142 -105 -11 -74
      3. 201604052203 18150 3 142 -105 -9 -76
      4. 201604052204 18150 3 142 -105 -9 -76
      5. 201604052205 18150 3 142 -105 -10 -75
      6. 201604052206 18150 3 142 -105 -11 -74
      7. 201604052207 18150 3 142 -105 -10 -75
      8. 201604052208 18150 3 142 -105 -9 -76
      9. 201604052209 18150 3 142 -105 -10 -75
      10. 201604052210 18150 3 142 -105 -9 -75
      11. 201604052211 18150 3 142 -105 -12 -73
      12. 201604052212 18150 3 142 -105 -9 -76
      13. 201604052213 18150 3 142 -105 -10 -75
      14. 201604052214 18150 3 142 -105 -9 -76
      15. 201604052215 18150 3 142 -105 -9 -76
      16. 201604052216 18150 3 142 -105 -9 -76
      17. 201604052217 18150 3 142 -105 -9 -76
      18. 201604052218 18150 3 142 -104 -12 -73
      19. 201604052219 18150 3 142 -105 -9 -76
      20. 201604052220 18150 3 142 -105 -10 -75
      21. 201604052221 18150 3 142 -105 -10 -75
      22. 201604052222 18150 3 142 -105 -10 -75
      23. 201604052223 18150 3 142 -105 -10 -76
      24. 201604052224 18150 3 142 -105 -10 -74
      25. 201604052225 18150 3 142 -105 -9 -76
      26. 201604052226 18150 3 142 -105 -10 -75
      27. 201604052227 18150 3 142 -105 -8 -76
      28. 201604052228 18150 3 142 -104 -9 -76
      29. 201604052229 18150 3 142 -105 -8 -76
      30. 201604052230 0 0 0 -105 -9 -76
      31. 201604052231 18150 3 142 -105 -8 -76
      Auszug...

      EDIT2: nöö, 800er Zellen haben nur 10MHz, statt 20MHz Kanalbandbreite... deshalb weniger Resource-Blocks (50 statt 100)... deshalb ist die Formel leicht anders... und RSRQ ist im Grunde das Verhältnis von rssi und rsrp zu resource-blocks - gehen rssi und rsrp gleich hoch (wie bei meiner 800er), bleibt der rsrq fast gleich - und der blaue RSRQ wird ja vom SPH so gemeldet....

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „eMKay77“ ()

      Moin!

      hefr54 schrieb:

      Das ist leider keine neue Erkenntnis und dazu hatte ich ja den Link zu "LTE-Info" angefügt. Da fehlt letztlich immer noch
      die Erklärung, warum als größter Wert -6 angezeigt wird - sowohl beim SPH wie auch beim e3272

      Nein - das war die Antwort auf

      hefr54 schrieb:

      Die 800MHz mit RSSI bei -40 müßte ja einen anderen Wert bei RSRQ ergeben, scheint aber nicht so

      => und das ist eben nicht gegeben, weil eben nicht nur der RSRP, sondern auch der RSSI (in fast genau dem geichen Maße) höher ist in der 800er...

      Deshalb meinte ich ja, ich bräucht' bessere Meßwerte - also eigentlich welche, bei denen der RSRP höher ist, aber der RSSI eben nicht so hoch, wie bei mir...

      Wenn man genauer darüber nachdenkt, könnte das ganze durchaus auch einen baulichen Grund haben - nämlich dann, wenn der SPH so schlecht geschirmt ist (oder so schlechte Bauteile nutzt), daß RSSI (mit Störstrahlung) und RSRP (Nutzsignal) einfach nicht nah genug zusammen kommen, um einen besseren RSRQ zu ergeben.

      Quellcode

      1. rsrq(rb,rsrp,rssi) = 10*log10(rb*10**(rsrp/10)/10**(rssi/10));

      Wie Du hier siehst ist es der Abstand zwischen RSRP und RSSI der den RSRQ ausmacht...
      (ich könnt' mal schauen, ob ich die Formel einzeln plotten kann - daraus könnt' man eventuell ablesen, wann der RSRQ besser als -6 werden müsste)

      Ich hab' übrigens noch mal weitere Messwerte angeschaut, und während der berechnete RSRQ bei unverändertem RSSI/RSRP logischerweise auch unverändert bleibt - schwankt der gemeldete RSRQ manchmal trotzdem.

      Entweder der SPH rechnet also intern mit höherer Auflösung (Nachkommastellen) und es ist einfach ein Rundungsproblem (durchaus möglich, weil die Berechnung ja in Watt gemacht wird, aber in dbm ausgegeben, welche ich wieder in Watt umrechnen muß und am Ende wieder in dbm...) - oder der SPH nutzt intern eben doch vielleicht die Einzelwerte der beiden Antennen-Anschlüsse...

      mfg, emkay

      @Stricted: nönö - ich glaub' Dir das :D
      Auf den zweiten Blick hatte ich's auch schon gesehen, daß Du den sphfreq-Output genommen hattest...
      Also lügt der SPH bewusst oder verrechnet sich.

      Ich hab' jetzt nochmal den Graphen geplottet - auf RSRQ <=-6 beschränkt - das ist eher eingängig.

      mfg, emkay
      Bilder

      • Bildschirmfoto vom 2016-04-06 12:09:31.png

        47,02 kB, 1.600×900, 370 mal angesehen

      eMKay77 schrieb:

      ...
      Also lügt der SPH bewusst oder verrechnet sich.
      ...
      mfg, emkay


      Das ist sehr naheliegend!
      Bei allem was wir so bisher wissen :)
      es ist eine unnatürliche Drossel...

      also wenn die Bauteile so schlecht geschwirmt wären??? Dann müßte man sie nachträglich besser schirmen?
      Aber dann käme man ja rechnerisch nicht auf diese Unstimmigkeit?
      An Rundungsfehler glaube ich nicht -3 und -6 sind ja nun wirklich Meilen auseinander!

      Heiko schrieb:

      An Rundungsfehler glaube ich nicht -3 und -6 sind ja nun wirklich Meilen auseinander!

      Naja - diese Berechnungen werden ja in Watt und nicht in dBm gemacht...

      Bedeutet: der SPH berechnet die Werte in Watt, wandelt nach dBm. Diese Werte nehmen wir nun, wandeln wieder nach Watt, berechnen selbst und wandeln wieder nach dBm... bei dem ganzen hin & her könnte sich schon so einiges summieren :D

      Es scheint jetzt aber so zu sein, daß diese Abweichungen im guten Bereich größer werden...
      (ob das jetzt auch einfach daran liegen könnte, daß die Berechnung in Watt stattfindet - also mit postiven Werten - müßte man mal durchdenken ;) )

      mfg, emkay