RSRQ/RSRP

      Das hatte ich ja auch erst gedacht...
      aber wenn man rechnerisch auf bessere Werte kommt?

      Spannend wäre höchstens mal die Werte einer Fritzbox ebenfalls nachzurechnen.
      Klar könnte man dann noch sagen ok die Fritzbox macht keine "Rundungsfehler"

      Speziell der Punkt je besser der Wert desto mehr weicht die Berechnung und Ausgabe vom SPH ab deutet es ja schon an.

      @hefr54: stimmt schon - welchen Wert der SPH an die Funkzelle meldet können wir nicht sehen.
      Aber @Stricted konnte immerhin nachweisen, das der SPH an uns -6 meldet, obwohl es (laut seines gemeldeten RSSI/RSRP) -3 sein müsste.

      Ob in dem Moment -3 oder -6 an die Funkzelle gemeldet wurde, können wir dummerweise nicht prüfen - dafür bräuchten wir eine TestZelle/IMSI-Catcher :D

      hefr54 schrieb:

      Geht eigentlich nur darum ob vom gleichen Sender mit anderer Hardware bessere Werte (RSRQ >-6) angezeigt werden

      Das hat aber dann ja im Grunde keine Aussagekraft - das andere, meinetwegen besser geschirmte Hardware (oder andere Antenne etc.), bessere Werte haben kann, ist wohl ziemlich klar :D

      Wenn überhaupt, bräuchte man Hardware, welche bei gleichem RSSI/RSRP einen anderen RSRQ anzeigt ;)

      So oder so ist es auffällig, daß die Abweichung im guten Bereich höher ausfällt...
      (bei mir nur +/-1 bei @Stricted mit besserem SIgnal -3 Abweichung)

      mfg, emkay

      Für die Leute, welche spielen wollen...

      Mini-Script zum Umformatieren der sphfreq-Ausgabe zum loggen:

      Shell-Script

      1. #!/bin/sh
      2. # Timestamp - Freq - LTEBand - CellID - RSRP - RSRQ - RSSI
      3. echo $(date +%Y%m%d%H%M) $(sphfreq show | busybox-mips tail -n 6 | cut -d ':' -f 2)

      >> die Ausgabe kann man dann einfach in ein Log pipen. (bei mir einmal pro Minute per cron nach /opt/logdata/lte.log)

      Mini-Script zur Anzeige der bekannten (laut Log) Funkzellen:

      Shell-Script

      1. #!/bin/sh
      2. cut -d ' ' -f 4,3,2 /opt/logdata/lte.log | busybox-mips sort | busybox-mips uniq | grep ' [0-9][0-9][0-9]$'


      GnuPlot-Script, um aus /opt/logdata/lte.log den Graphen zu berechnen (als SVG - /opt/bin/ltegraph)

      Shell-Script

      1. #!/bin/sh
      3. busybox-mips tail -n 120 /opt/logdata/lte.log | sed -r 's/^[0-9]+$/& 0 0 0 NaN NaN NaN/' > /tmp/lte.dat
      4. gnuplot -e "
      5. set term svg size 1200, 1000 background rgb '#F0F0F0' font ',16' name 'LTEGraph';
      6. set grid front lc rgb 'black';
      8. set title 'LTEGraph' font ',28';
      10. intime(COL) = strptime('%Y%m%d%H%M',strcol(COL));
      11. stats '/tmp/lte.dat' using (intime(1)) name 't' nooutput;
      13. set timefmt '%Y%m%d%H%M';
      14. set format x '%H:%M';
      15. set xdata time;
      17. set key out;
      19. set autoscale yfix;
      21. set tics out;
      23. set xtics 300 nomirror;
      24. set xtics rotate by 315 offset graph -0.01;
      25. set mxtics 5;
      27. set ytics 5;
      28. set mytics 5;
      29. rmin=t_max-(2*60*60)+60;
      30. set xrange [rmin:t_max];
      32. set yrange [-120:0];
      34. set offsets 30,30,0,0;
      35. oldCell=NaN;
      37. set style line 1 pt 7 ps 0.5 lc rgb 'blue';
      38. set style line 2 pt 7 ps 0.5 lc rgb 'green';
      39. set style line 3 pt 7 ps 0.5 lc rgb 'yellow';
      40. set style line 4 pt 7 ps 0.4 lc rgb 'pink';
      42. set boxwidth 60;
      44. rsrq(rb,rsrp,rssi) = 10*log10(rb*10**(rsrp/10)/10**(rssi/10));
      46. plot '/tmp/lte.dat' using 1:(\$3>=0?-120:0):(\$3<20?(\$3==0?0xFF0000:0xA0A000):0xA000A0) w boxes fill solid lc rgb variable notitle, \
      47. '' using 1:(\$6<0?\$6:NaN) w lp ls 1 t 'gRSRQ', \
      48. '' using 1:(\$6<0?rsrq(\$3==20?50:100,\$5,\$7):NaN) w lp ls 4 t 'bRSRQ', \
      49. '' using 1:(\$7<0?\$7:NaN) w lp ls 2 t 'RSSI', \
      50. '' using 1:(\$5<0?\$5:NaN) w lp ls 3 t 'RSRP', \
      51. '' using 1:(0):((\$4!=oldCell&&intime(1)>=rmin)?oldCell=\$4:'') w labels left rotate offset screen 0,0.005 font ',10' notitle;
      52. "
      53. rm /tmp/lte.dat


      Und das CGI, um es im WebBrowser darzustellen:

      Shell-Script

      1. #!/bin/sh
      2. echo "Content-type: image/svg+xml"
      3. echo ""
      5. ltegraph

      EDIT: hab' die SED-Zeile nochmal optimiert.

      und im Anhang mal rund 500k Logdaten... (umbenannt, weil .log im Forum nich geht...) :D

      mfg, emkay
      Dateien

      • ltelog.txt

        (501,15 kB, 379 mal heruntergeladen, zuletzt: )

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

      Also ich hätte knapp 17000 Datensätze falls wer möchte?
      Mein Export ist nun nur etwas anders aufgebaut.


      timestamp lteband zellfreq zellband zellid rsrp rsrq rssi


      Die Werte von gestern Abend/Nacht sind Werte wo die Leitung dauerhaft am Limit lief also nicht wundern :)
      Dateien

      • sph_data.txt

        (836,53 kB, 392 mal heruntergeladen, zuletzt: )

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

      Hab' dann auch nochmal 'nen Graph - mit mehreren Zellwechseln und einem Reboot (graue Lücke)
      Man sieht da recht schön, daß in meiner 800er-Zelle (die 354 - in violett) zwar der RSRP ordentlich hochgeht, aber eben dummerweise auch der RSSI (inkl. Störungen) - weshalb sich der RSRQ kaum bessert...

      mfg, emkay

      EDIT: BIld nochmal gewechselt - hier sieht man zusätzlich, daß der SPH manchmal Zelle '0' meldet - konnte noch nicht sicher belegen, ob das dann auch ein echter Zellverlust ist. (bei 'normalem' kompletten Zellverlust sind auch die RSRQ/RSRP/RSSI-Werte weg)
      Bilder

      • Bildschirmfoto vom 2016-04-06 15:17:10.png

        139,06 kB, 1.600×900, 342 mal angesehen

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

      hefr54 schrieb:

      Wie soll sich der Wert bessern wenn immer die gleiche Antenne am gleichen Standort ist?

      ...weil es verschiedene Funkzellen mit verschiedenen Frequenzen in unterschiedlicher Entfernung und Position (die 1800er ist hinter der Antenne und wird per Reflektion empfangen) sind... :D
      Es ging dabei um den Wechsel von 1800MHz zu 800MHz (mit 800er Dabendorf) - da ändern sich die Werte sehr wohl - aber eben (bei mir) nahezu parallel...

      Was die LTE-FW betrifft: keine Ahnung, wie Du da 'ne XML erhalten hast...
      Per Binwalk die .053 zerlegen - dann deren RootFS per unjaffs2 mounten - dann einfach die drei LTE-FW-Dateien (lte_need_update.ini, lte_fota.bin, lte_version.ini) kopieren. ==> dann könnte man den Versuch starten, die Dateien auf dem SPH umzubenennen und die extrahierten in den Ordner zu schmeißen.

      mfg, emkay

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

      so hier mal beide graphen als vergleich

      ziemlich interessant wie weit die berechnung vom wert den der sph ausgibt abweicht

      habe teilweise das gefühl der sph berechnet den wert nicht live sondern periodisch und speichert den irendwo zwischen
      Bilder

      • lteinfo-1h.png

        19,06 kB, 696×301, 348 mal angesehen

      • ss+(2016-04-06+at+03.48.26).png

        176,37 kB, 1.111×923, 375 mal angesehen

      hefr54 schrieb:

      Das meinte ich, das Verhältnis bleibt gleich von 800 zu 1800 - kann ja auch nicht anders sein wenn sich
      an der Position nichts ändert.

      könnte eben schon - wenn an meiner Position im 800er-Bereich weniger Störungen wären, als im 1800er-Bereich oder die Dabendorf schmalbandiger auf die 800MHz wäre...
      Stattdessen ist es genau umgekehrt: trotz 800er-Antenne und obwohl die 1800er-Zellen nur per Reflektion zu empfangen sind - ist der RSRQ in der 1800er-Zelle ('142') besser/stabiler ;)

      Ich schätze mal fast, daß gerade der Umstand, daß ich 3 Zellen erreichbar habe, die Störungen hochtreibt - Besserung könnte ich eventuell bekommen, wenn ich auf eine 1800er-Antenne Wechseln würde (weil diese die 'Störstrahlung' der starken 800er Zelle benachteiligen würde)
      --- leider bedeutet das 'Festnageln' auf eine Frequenz durch sphfreq nicht, daß der Empfänger des SPHs die anderen Frequenzen wirklich filtert - er ignoriert die Zellen nur auf logischer Ebene. (ein 'Hardware-Filter' ist da im Vorteil - damit könnte man wirklich Störstrahlung vom SPH fernhalten.)

      Was BinWalk betrifft: habe jetzt auch nicht alle Parameter im Kopf. Habe aber doch oben den Vorgang kurz erklärt.
      Ich seh' aber gerade: das ist gar nicht im RootFS - ist ein eigenes Mount auf /dev/mtdblock13 ==> damit auch nach BinWalk ein eigenes File, welches dann aber eben trotzdem per unjffs2 entpackt werden kann.
      (alternativ könnte man es eventuell auch direkt auf dem SPH temporär mounten und so an die Daten kommen)

      Also erst per BinWalk (am besten per Paramter auf jffs2 beschränken) zerlegen - dann könnte man das betreffende JFFS2-Image aus dem BinWalk-Lauf per unjffs2 mounten und die 3 Dateien daraus kopieren.

      mfg, emkay

      Stricted schrieb:

      ziemlich interessant wie weit die berechnung vom wert den der sph ausgibt abweicht

      Da sieht man jetzt schön, wie der 'blaue' gemeldete RSRQ an eine -6db-Grenze stößt....
      ...und das es Rundungsfehler gibt - denn -2db ist unmöglich :D

      mfg, emkay

      EDIT: ich seh' grad' - mein Mini-Script zur Anzeige bekannter Funkzellen würde bei Dir so nicht funktionieren - der letzte grep-Befehl beschränkt auf 3-Stellge CellIDs und deine haben nur 2 stellen...

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

      hefr54 schrieb:

      Funktioniert so leider nicht /var ist leer

      Ich weiß... deshalb schrieb' ich:

      eMKay77 schrieb:

      Ich seh' aber gerade: das ist gar nicht im RootFS - ist ein eigenes Mount auf /dev/mtdblock13 ==> damit auch nach BinWalk ein eigenes File, welches dann aber eben trotzdem per unjffs2 entpackt werden kann.

      :D

      EDIT: Ich lass' grad' mal folgenden Befehl durchlaufen:

      Quellcode

      1. sudo binwalk -er -D JFFS2 Firmware_Speedport_Hybrid_v050124.01.00.057.bin

      dauert halt ein wenig - aber ist dann schon auf JFFS2 beschränkt.

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

      hefr54 schrieb:

      Auf dem SPH sind die Dateien sowohl in /var wie auch in /dev/mtdblock13 weil das Image von da gestartet wird.
      Aber wenn die Firmware extrahiert wird gibt es kein /dev/mtdblock13
      Wo find ich die Dateien den im Extrakt?


      Nee - das ist ein wenig anders...

      /var/lte_fota ist kein echter Ordner, sondern nur ein Mount-Point.
      Beim Boot wird /dev/mtdblock13 auf /var/lte_fota gemounted.

      Es gibt also zwei Wege, an eine ältere LTE-Firmware zu kommen:
      1. man kopiert einfach den /dev/mtdblock13 eines SPHs mit älterer Firmware per 'dd'
      2. man extrahiert per binwalk alle JFFS2-Images aus dem BIN-File (eins davon ist das RootFS, aber ein zweites ist der MTDBLOCK13...)

      Der Befehl oben müsste eigentlich alle JFFS2-Images innerhalb der BIN finden und entpacken - braucht allerdings eben sehr lang.
      (das RootFS hat er bei mir schon entpackt - den Rest sucht er noch)

      Das BinWalk für JFFS2 so lange braucht, liegt daran daß der JFFS2-Header so kurz ist ==> viele falsch-positive Meldungen...

      mfg, emkay

      hefr54 schrieb:

      In dem von mir extrhierten 053 gibt es nur 2 jffs2 Files.
      20607.jffs2 64,7 MB
      20607.jffs2.le 43,9 MB

      Das ist beides das gleiche (nämlich das RootFS)...

      20607.jffs2 ==> das originale in BigEndian - so wie's ein MIPS braucht.
      20607.jffs2.le ==> Binwalk-Arbeitskopie in LittleEndian - so wie's ein Intel braucht.

      Natürlich ist es möglich, das das LTE-JFFS2 zusätzlich nochmal komprimiert ist - das würde die Suche erschweren. Aber es muß da sein.
      (wie gesagt - notfalls könnte man es per Telnet aus einem SPH extrahieren ==> 'dd if=/dev/mtdblock13 of=lte_img.jffs2' )

      naja, mal sehen... Binwalk wird bei mir noch'n Moment brauchen :D

      mfg, emkay

      Nochmal zur Veranschaulichung:

      Quellcode

      1. # cat /proc/mtd
      2. dev: size erasesize name
      3. mtd0: 05000000 00020000 "rootfs"
      4. mtd1: 10000000 00020000 "all"
      5. mtd2: 00aa0000 00020000 "config"
      6. mtd3: 000a0000 00020000 "equip"
      7. mtd4: 000a0000 00020000 "upgflag"
      8. mtd5: 00020000 00020000 "blrom"
      9. mtd6: 000a0000 00020000 "rootfstag"
      10. mtd7: 00940000 00020000 "reserved"
      11. mtd8: 05ea0000 00020000 "html"
      12. mtd9: 001a0000 00020000 "wlanrf"
      13. mtd10: 0fea0000 00020000 "kernel"
      14. mtd11: 0aea0000 00020000 "kernelbak"
      15. mtd12: 00280000 00020000 "configbak"
      16. mtd13: 04600000 00020000 "module"

      und den letzten brauchen wir ;)

      EDIT: mal so am Rande... in der busybox-mips scheinen auch NAND-Flash-Tools zu sein... :D
      (aber da der SPH die MTDs rw-mounten kann, nicht ganz so wichtig)