Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.
D

digital_wadik

Well-known member
#601
#601
Grade geschaut was so geht mit den Ubis usw.

bin darauf gestoßen.

https://github.com/sabueso/UbntInfo


Ist ein kleiner pyhton script mit dem man eig. so ziemlich das wichtigste auslesen kann.
Fürs erste konnte ich auch Daten ziehen. hat auch alles gepasst. muss noch kucken wie die Performance des script ist und ob man den irgendwie ins programm mit einbauen kann (Pyhtoninterpreter)

Wers auch mal testen möchte:

http://docs.python-requests.org/en/latest/user/install/

oder so:

die Daten einfach irgendwo auf den Pi speichern
python-requests werden benötigt!
mit "sudo apt-get install python-requests" installieren.

cd /Verzeichniss/.../...
python ublogin.py -i 192.168.137.20 -u ubnt -p ubnt -d frequency

Daten können von beiden ubis geholt werden. einfach die IP ändern.
 
Zuletzt bearbeitet:
A

aargau

Erfahrener Benutzer
#602
#602
Cool wäre halt wenn man eine eigene kleine Seite auf dem Webserver liegen haben könnte welche die wichtigsten infos direkt per Semikolon getrennt ausgibt.. Aber ich denke für sowas ist die AirOS Firmware dann doch zu stark beschränkt. Sowas wäre Performance mässig perfekt und man könnte es in jeder nur erdenklichen Programmiersprache auswerten.
 
Lonestar78

Lonestar78

Erfahrener Benutzer
#603
#603
Hey hexakopter:
sind die OIDs korrekt?


Uptime - 1.3.6.1.2.1.1.3.0
RSSI - 1.3.6.1.4.1.14988.1.1.1.1.1.4.6
Signal Strength - 1.3.6.1.4.1.14988.1.1.1.1.1.4.7
TX Data Rate - 1.3.6.1.4.1.14988.1.1.1.1.1.2.7
RX Data Rate - 1.3.6.1.4.1.14988.1.1.1.1.1.3.7
Frequency (eg 5180....) - 1.3.6.1.4.1.14988.1.1.1.1.1.7.7
last number .7 is interface index.

CPU usage:
1 Minute Average - 1.3.6.1.4.1.10002.1.1.1.4.2.1.3.1
5 Minute Average - 1.3.6.1.4.1.10002.1.1.1.4.2.1.3.2
15 Minute Average - 1.3.6.1.4.1.10002.1.1.1.4.2.1.3.3

Memory:
Total memory - 1.3.6.1.4.1.10002.1.1.1.1.1.0
Free memory - 1.3.6.1.4.1.10002.1.1.1.1.2.0
 
S

senseless

Benutzer
#604
#604
Moin zusammen,

hier ist die Urlaubsvertretung von hexakopter ;)

Ja, die OIDs sehen ganz gut aus. Einzig dass es 'richtiges' RSSI meines Wissens nicht direkt gibt, sondern nur die Signalstärke in dBm. Aber das ist ja denke ich eh besser als irgendein vom Hersteller willkürlich festgelegter RSSI-Wert.
In deiner Aufzählung ist es dann so, dass RSSI und Signal Strength genau das gleiche sind, nur auf einem anderen IF. Wie da auch schon steht ist die letzte Ziffer immer die IF-Nummer. Bei mir war es zB glaube ich die 5. Geht aber auch zumindest in meinem Python Skript ohne Angabe der letzten Ziffer, da der RSSI-Node dann quasi nur ein 'Blatt' hat.
Ansonsten kann man aber auch herausfinden, welche Ziffer die richtige ist, falls das nötig ist.

Mein Skript könnt ihr hier finden, aber seid gewarnt, es ist wirklich nur auf die Schnelle in ein paar Minuten zusammengehakt worden: snmp-logger.py
Da sind auch die OIDs drin, die ich verwendet habe. Bei euch funktionieren wird es nicht, weil ich gleichzeitig noch über BT die GPS-NMEA-Strings einfangen möchte, und ihr das entsprechende tty-Device nicht haben solltet, sodass irgendeine Exception geworden wird. Ansonsten muss natürlich Net-SNMP mit dem Python-Wrapper installiert sein.


Das erstmal dazu. Was ich noch ganz interessant fände, wäre zu wissen, ob ihr schon mit verschiedenen MCS-Einstellungen rumgespielt habt. Der Rangetest wurde nämlich zB mit höchstem MCS-Index gemacht, den meine Module bieten. Prinzipiell sollte es aber ja cleverer sein, wenn man nicht viel mehr an Datenrate möglich machen würde, als nötig, und stattdessen von 64-QAM auf zB QPSK zurückgeht.
Die BER sollte sich dann ja erheblich verringern sodass denke ich höhere Reichweiten drin wären.
Oder hab ich da jetzt nen Denkfehler drin? Solange es im IEEE-Standard nichts gibt, was automatische Fallbacks erlauben würde, sollte das doch stimmen? Kennt jemand den Standard genau genug um da was zu sagen zu können?
Dazu fand ich übrigens die Tabelle hier ganz gut.
 
Lonestar78

Lonestar78

Erfahrener Benutzer
#605
#605
Danke! Ich habe 2kanal mimo mit reduzierter Datenrate laufen. Um die 30 Mbit meine ich. Aus genau dem Grund den du beschreibst. Hab aber nie was anderes getestet
 
Overtuner

Overtuner

Gesperrt
#606
#606
dass RSSI und Signal Strength genau das gleiche sind
Zum Vergrößern anklicken....
nehmt doch die Namen wörtlich
Remote Signal Strength Indicator, also die Signalstärke der "anderen" Seite.
 
S

senseless

Benutzer
#607
#607
Overtuner hat gesagt.:
nehmt doch die Namen wörtlich
Remote Signal Strength Indicator, also die Signalstärke der "anderen" Seite.
Zum Vergrößern anklicken....
Ich weiß ja nicht, wo diese Definition her ist, aber ich kenne das als Received Signal Strength Indication. Und das ist ja auch garnicht das Problem. Man kann ja problemlos von beiden Seiten her SNMP verwenden. Ich meinte nur, dass es kein RSSI - wonach ja gefragt worden war - im Sinne von Werte zwischen zB 0 und 100 gibt, sondern eben nur als 'echte' Leistung in dBm.
 
I

indu

Benutzer
#608
#608
Lonestar78 hat gesagt.:
@Indu: Was heißt denn für dich verlässlich? Wir haben in diversen Posts gezeigt, dass 115 bis 220 Millisekunden stabil gehen. Je nach Hardware fürs Abspielen.
Zum Vergrößern anklicken....
Mit verlässlich meinte ich das jemand eine Konfiguration mit RPi als Ground Station einen 720p Stream o.ä. mit einer nachvollziehbaren Latenz gestestet hat.
Würde nämlich gerne einen Monitor oder eine Brille als Wiedergabegerät nutzen anstatt eines Notebook oder Android-Handys.

Und da ich selbst nicht rausbekomme welche technischen Vorraussetzungen eine bessere Wiedergabe des Streams ermöglichen fragte ich nach.
Es gibt ja schon einige Clone vom RPi, nur welcher besser geeignet ist zur Wiedergabe eines H.264 Streams und warum hab ich nicht rausbekommen. Außer das vielleicht der Grafikprozessor einen Anteil daran hat...
 
D

digital_wadik

Well-known member
#609
#609
Dachte wir wären mit dem Thema latenz soweit durch :) sobald du einen notebook oder desktop PC als abspiel gerät nutzt. (Kannst ja Monitor anschließen) sind bei HD auflösung 110ms möglich das haben hier schon einige getestet und auch Bilder reingestellt. Meiner meinung nach genug zum fliegen.

Ich denke es ist egal welche RPi clone man verwendet. Die haben alle den gleiche chip den gleichen hardware h264 encoder.

Edit:
Habe den Pi auch mal als Ground verwendet. Scheinbar hat der aber keinen Hardware h264 decoder.
Habe bessere ergebnisse erziehlt als ich den CPU auf 1Ghz getaktet habe. (Latenz war sehr gut nur die Framerate macht der nicht mit) Also so ein Cubieboard oder banan Pi würde das besser hinbekommen ;)
 
Zuletzt bearbeitet:
I

indu

Benutzer
#610
#610
digital_wadik hat gesagt.:
Ich denke es ist egal welche RPi clone man verwendet. Die haben alle den gleiche chip den gleichen hardware h264 encoder.

Habe den Pi auch mal als Ground verwendet. Scheinbar hat der aber keinen Hardware h264 decoder.
Habe bessere ergebnisse erziehlt als ich den CPU auf 1Ghz getaktet habe. (Latenz war sehr gut nur die Framerate macht der nicht mit) Also so ein Cubieboard oder banan Pi würde das besser hinbekommen ;)
Zum Vergrößern anklicken....
Hmm - leider finde ich keine Infos dazu warum ein Cubieboard oder Banana Pi das besser hinbekommen.
Die erste Info dazu ist diese hier: http://forum.golem.de/kommentare/op...eschleunigung/84996,3826952,3826952,read.html
und die sagt dazu das es scheinbar mit denen nicht besser ist...

Möchte ungern als Anfänger mir da was zulegen, rumprobieren und dann feststellen das es ein Griff ins Klo war ;-)
 
D

digital_wadik

Well-known member
#611
#611
Hol dir 2×RPI und ne pi Cam. Die sind ihr Geld sowieso wert. Fals was kannst den einen Pi noch für andere zwecke verwenden. Es gibt tonnen an anderen verwendungszwecken. Ob als Internetradio oder Mediacenter(xbmc) homeserver etc. Das Teil ist einfach genial in jeder hinsicht.

Aber ich kann dir versichern das man mit dem Pi als ground auch schön fliegen kann. Habs ja auch schon gemacht. Nur auf einen stärkeren Notebook bekommst bessere Auflösung hin ;)
 
D

digital_wadik

Well-known member
#612
#612
@Lonestar

Bin endlich dazu gekommen und habe den gst-rstp-server-1.4.0 installiert bekommen.

Das war meine Eingabe:

pi@RpiAirStation ~ $ /home/pi/gst-rtsp-server-1.4.0/examples/test-launch "(rpicamsrc bitrate=6500000 hflip=true vflip=true preview=false ! video/x-h264,width=1280,height=720,framerate=49/1,profile=high ! h264parse ! rtph264pay name=pay0 pt=96 )"
stream ready at rtsp://127.0.0.1:8554/test

Also der RTSP server starten schon mal nur kann ich jetzt auf meinem Rechner den Stream nicht starten. Mit deinem Image hat es funktioniert :/

Habe ich irgendwas vergessen oder muss ich noch irgendwas starten/installieren ?
 
H

hornetwl

Erfahrener Benutzer
#614
#614
Habe gerade mal das Image runtergeladen. Gibt es eigentlich einen Grund, warum dieses auf 4G zugeschnitten ist (mit 66% freiem Platz)? Scheint locker auf 2G zu passen und natürlich fliegt gerade keine 4G-Karte herum :)

Beim Verkleinern bin ich dann noch über ein paar (nicht schlimme) fsck-Fehler in der zweiten Partition gestolpert - also einfach mal wieder fscken ;)
 
Lonestar78

Lonestar78

Erfahrener Benutzer
#616
#616
@scritch: ist ne 3 Euro leselupe von amazon. So eine fresnel folie. Abstand Stirn zu Handy ist 8.5cm
 
Lonestar78

Lonestar78

Erfahrener Benutzer
#617
#617
Zum Hardware decodieren auf dem pi geht wohl zumindest 720p mit dem OMX Decoder für gstreamer. Gabs aber noch nicht probiert
 
H

hornetwl

Erfahrener Benutzer
#619
#619
Hat eigentlich schon mal jemand über den Ubiquity Wifistation-EXT nachgedacht? Das Teil hat direkt ein USB-Interface (wie der originale Raspi-Ethernet-Anschluss auch) und damit wären sämtliche POE-Kabel-Lötereien überflüssig.

Weiterhin würde das hervorragend zu diesem hier passen und die Flugtauglichkeit erheblich steigern:
http://www.pollin.de/shop/dt/OTQ2OT...inplatinen_Computer_ARM11_700_MHz_512_MB.html

Der Haken: offenbar ist das Ding hier (nicht mehr) zu bekommen...
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten