Beiträge von hns

    1. das wird normalerweise ganz tief versteckt im Kernel gemacht. OTG geht so: Kurzschluß am ID pin erkennen (das macht Hardware und löst einen Interrupt aus), Wandler von Akkuspannung im Gerät auf 5V einschalten und warten dass sich das angeschlossene Gerät per USB-Protokoll meldet (dann wird ausgehandelt wie schnell es ist, welchen Strom es haben will und was für ein Gerät es ist). Das alles bekommt man in Android selbst auf der Kommandozeile (adb) nicht mit. Nur das Ergebnis dass z.B. ein USB-Speicherstick erkannt wurde. Falls Du extrem viel Glück hast, gibt es bei Deinem Kernel im /sys eine Möglichkeit das gezielt zu schalten.


    2. Bits auf USB-Bus schreiben geht auch nur wenn Du einen Kerneltreiber für den USB-Controller auf Deinem speziellen Prozessor hast. Dann gibts entweder einen Test-Mode wo man gezielt Spannungen auf D+ oder D- schalten kann (0, floating, 3,3V). Oder man kann den USB-Port auf UART schalten (falls das eingebaut ist). Aber alles das geht nicht auf Android-Ebene sondern Du mußt ein Cyanogenmod installieren und den Kernel hacken.


    3. Es gibt Bluetooth-Module z.B. mit RS232-Interface für ca. 10€ (schaue mal auf Aliexpress). Das ist nicht sooo viel mehr als ein USB-Stecker + Kabel kostet und Du kannst über stty den RTS "fernsteuern". Und das Risiko das Handy zu beschädigen ist kleiner. Du mußt im Schaltplan nämlich S mit GND vom USB (also dem Gerät) verbinden - sonst ist die Gate-Source-Spannung undefiniert.


    Zum MOSFET: am Gate zieht der gar keinen Strom, das reicht eine Steuerspannung (Gate-Source-Spannungsdifferenz). Das ist ja der Witz an FETs gegenüber bipolaren Transistoren.


    Also in Summe scheint mir für den Anwendungsfall ein Microcontroller-Modul mit eingebautem Bluetooth besser geeignet zu sein. Da kannst Du dann auch Sicherheitsmechanismen einbauen.

    Ich wollte gerade mehr oder weniger das Gleiche schreiben wie Marco.


    Das Problem ist dass Du "Bewegung" von "Nicht-Bewegung" trennen mußt. Das geht prinzipiell durch Bildvergleich. Also das aktuelle mit dem vorherigen Bild vergleichen. Und z.B. die Pixel zählen deren Farbwerte sich um mehr als 5% geändert haben. Wenn das "viele" sind, ist es eine Bewegung. Wenn nicht, ist das Bild in Ruhe.


    Aber Du siehst schon das sind recht unpräzise Definitionen. Warum 5% und nicht 3% oder 10%? Im Prinzip damit Du im Raum auch herumlaufen kannst und Schatten erzeugen. Oder Wolken vor dem Fenster ändern auch die Gesamthelligkeit. Das Zweite: was sind "viele"? Da mußt Du experimentieren und ab und zu ist es dennoch falsch (Fehlalarm eines Mustererkenners).


    Außerdem kommt wohl nochwas dazu: wenn Du langsam bist, legst Du ein Blatt hin. Wenn das Bild in Ruhe ist wird ein Foto gemacht. Wenn Du es dann wegnimmst, ist da der leere Tisch. Das ist auch ein Bild in Ruhe. Oder wenn Du schnell bist hast Du schon das zweite Blatt hingelegt. Wie soll das unterschieden werden? Ohne dass das System versucht den Inhalt (Blatt oder nicht-Blatt) zu erkennen ist das unmöglich.


    Also mir schiene die einfachste Lösung ein Knopf den Du jedes Mal drückst wenn Du ein Foto haben willst... Also blatt unter die Kamera und Knopf drücken. Dann nächstes Blatt usw. Denn einen so guten Mustererkenner wie der hinter deinen Augen kann man nicht programmieren.


    Wie man das alles mit Android löst weiß ich leider auch nicht - da kenne ich mich viel zu wenig aus und würde es gerne lernen wenn Du es schaffst.

    ggf. kannst Du auch versuchen die ARP-Tabellen auszulesen. Da sollten alle in letzter Zeit auf dem Netz gesehenen IP-Adressen drin stehen. Details und Limitierungen kenne ich aber auch nicht.


    Noch ein Ansatz: ZeroConf. Da gibt es wohl auch einen Broadcast-Reply-Mechanismus. Allerdings müssen da alle Teilnehmer irgendwelche Dienste aktiv präsentieren wenn sie gefunden werden wollen.

    Vielen Dank für die Info.
    Also ist es als Zeitgeber für mich eher uninteressant.
    Das permanente Auf-nen-Knopf-drücken-zum-Uhrzeit-lesen nervt mich bei meiner binären Armbanduhr schon gewaltig – und einmal im Jahr die Batterien auswechseln lassen ebenfalls.


    Wenn sie die Dinger irgendwann so hinbekommen, dass das elektrische Feld des (tragenden) Körpers die Geräte induktiv mit permanenter Spannung versorgt können wir noch einmal darüber reden. ^^


    Ja richtig. Genau das ist m.E. das Problem mit den Smartwatches. Als Computer/Handy im Vergleich zu einer Standarduhr zu unbequem, klein, unpraktisch und Akku zu schnell leer.
    Ich hatte vor 15 Jahren noch eine Casio-Armbanduhr mit 7 Jahre ohne Batteriewechsel. Als die Batterie leer wurde habe ich gemerkt wieviele Uhren um einen herum existieren und habe seither gar keine.

    Ich frage mich ja immer, wofür man solche Gadgets braucht.
    Kamera an der Uhr? 8|


    Wie lange ist denn die Akkulaufzeit des Geräts?


    Kamera in der Uhr hat halt etwas von "007".


    Im Ruhezustand (also als Armbanduhr) ca. 3-5 Tage. Wie es mit aktivem UMTS ist weiß ich nicht genau. In diesem Modus ist der Bildschirm schwarz und man muß eine Taste drücken damit man für 30 Sekunden das Ziffernblatt sieht.
    Aktiver Betrieb (z.B. Video abspielen, GPS-Karte, Telefonieren) habe ich nicht getestet aber ich denke mehr als 2-3 Stunden werden es nicht sein können.

    Würdest du alles in allem sagen, dass es sich gelohnt hat, dafür Geld auszugeben und hast du mittlerweile eine Idee, was du damit programmieren willst bzw. schon ein Projekt umgesetzt ?


    "Gelohnt" ist relativ und bezieht sich immer auf das was man damit vor hat.


    Also ich wollte es als Spielzeug um herauszufinden was man technologisch erreichen kann. Und bin absolut beeindruckt, dass man auf diesem winzigen Raum alles unterbringen kann wenn man sich anstrengt:
    * dual core CPU mit viel RAM&Flash
    * WLAN, UMT, Bluetooth, GPS
    * Kamera (macht erstaunlich gute Bilder)
    * volles Android 4.2.2


    Es ist schon beeindruckend wenn man auf dem winzigen Screen eine Webadresse eintippt und man seine Webseite als winziges Bildchen sehen kann (sofern die Augen gut sind und die Brille noch paßt :)


    Schön finde ich die Auswahl an Ziffernblättern. Man kann da richtig interessante Designs finden (z.B. find eich eines gut wo man goldene Zahnrädchen sieht). Im Prinzip sind das dynamische Lock-Screens wofür man eigentlich keinen Dual-Core braucht...


    Insgesamt gibt es sehr wenig auszusetzen, eigentlich Kleinigkeiten:
    * wenn die Uhr in der Docking-Station ist wo man sie laden kann (und per USB auf den adb kommt) dann kann man die Tasten nicht bedienen. Das macht es etwas schwierig Software zu installieren und on Board zu testen
    * bei leerem Akku landet die Uhr in einem chinesischen Boot- und Systemtestmenü - wo ich nur schwierig wieder herauskomme
    * das Teil ist ziemlich schwer und damit "belastend" (hatte ich schon geschrieben)


    Aber vom praktischen Nutzen fehlt mir immer noch die Idee...


    Vor allem eine die mich dazu bringen würde das schwere Teil permanent am Arm zu tragen.

    Naja, wie geschrieben ist es den meisten zu teuer. Daher ist das Interesse zu gering. Und wegen dem geringen Interesse kann man es nicht billiger herstellen. Daher gibt es momentan keine Aktivitäten (denn die kosten Zeit & Geld das nicht da ist).


    Natürlich kann man es aufleben lassen und mit moderneren Bauteilen ausstatten. Also im Prinzip ein http://www.pyra-handheld.com/specs.html mit ca. 7-Zoll-Touch versehen. Das könnte in wenigen Monaten fertig sein.


    Vielleicht hat ja jemand Interesse und das Geschick über einen Kickstarter genügend Interessenten zu finden. Wir bauen das dann gerne.

    Die Syntax steht z.B. hier:
    http://greenbytes.de/tech/webd…pbis-p5-range-latest.html oder http://tools.ietf.org/html/rfc2616#section-14.35


    demnach bytes=500-600,701-999


    Zu beachten scheint mir dass es ein optionales Feature des Servers oder von Proxies ist. D.h. nur wenn man einen 206-Status bekommt, war es wirklich ein Range. Und wie mehrere (vielleicht sogar überlappende?) Ranges in einer Antwort zusammengefasst werden habe ich jetzt nicht nachgelesen.

    Gestern habe ich meine Truesmart aus dem Developer-Kisckstarter (Seriennummer 0098) bekommen und gleich ausprobiert.
    Anfangs was die Bedienung etwas gewöhnungsbedürftig (Power-Button ist oben, Home-Button unten. Und der mittlere Button ist keiner sondern die Kamera). Und manchmal muß man wischen oder auf dem Screen tippen damit was passiert.
    WLAN war recht schnell eingerichtet und dann konnte ich sogar schon surfen :) Es ist allerdings nicht so einfach auf dem kleinen Screen etwas zu tippen, vor allem eine Webadresse. Aber man muß trotzdem sagen: es geht.
    Natürlich kann man eine Webseite fast nicht lesen, weil der Screen so klein ist und mit 240x240 auch nicht mehr alle Pixel einer für SXGA entwickelten Webpage darstellt :)
    Insgesamt ist das Ding robust, aber auch etwas klobig und richtig schwer... Also etwas für richtig harte Kerle :)
    Tja, und mir fehlt eigentlich die Idee was ich damit programmieren könnte.
    Installiert ist momentan Android 4.2.2. Es gibt WiFi, Bluetooth, Kamera, UMTS (wenn man eine SIM reinmacht wozu man winzige Kreuzschlitz-Schräubchen mit einem mitgelieferten Schrauber öffnen muß).
    Soweit mal meine ersten Erfahrungen.
    -- hns

    Ob Game oder was anderes ist uns prinzipiell völlig egal, solange es gut umzusetzen und interessant ist.


    Ich denke Ihr müßt diese Bedingungen in zwei Schritte zerlegen:
    1. was findet Ihr (also Ihr selber!) interessant? da kann Euch niemand helfen und "egal" sind keine Interessensschwerpunkte
    2. was ist gut umzusetzten? dazu kann das Forum weiterhelfen


    Also macht an einem Tag eine Liste was Euch alles einfällt (Brainstorming ohne Bewertung, also alles auch noch so blöde reinschreiben). Dann am nächsten Tag macht Ihr eine Reihenfolge, was Ihr am interessantesten findet, am zweitinteressantesten usw. Und ab dem dritten Tag versucht Ihr herauszufinden, was jewals der Aufwand ist, d.h. stellt die Liste hier vor. Dann am Schluß könnt Ihr zwischen Interesse und Aufwand abwägen. Wichtig: vorher wird aus der Liste nichts herausgestrichen, sonst kann man Ideen nicht untereinander vergleichen!

    Ich hoffe, du benutzt nicht die SecureRandom Klasse von Android.


    Genau solche Themen sind es, warum ich nach Open Source frage...
    Dann kann man immerhin selber reinschauen und sich eine Meinung bilden ob man der Software (in diesem Fall sogar Programm + Systemfunktionen) vertrauen will oder nicht.
    Das hat auch nichts mit Mißtrauen gegenüber dem Autor zu tun, sondern mit Lebenserfahrung, dass selbst der allerbeste Wille und die allerbesten Absichten nicht ausreichen um 100% Perfektion zu erreichen.


    Die App ist Closed Source. Ich kann dir aber versichern das ich 15 Jahre Programmiererfahrung besitze und bei der Entwicklung der App die Sicherheit eine große Rolle gespielt hat. Closed Source bedeuted nicht automatisch Security through obscurity..


    Nix gegen Deine Erfahrung, aber es hat auch schon Programme gegeben wo Leute erst nach 30 Jahren einen Fehler entdeckt haben. Und auch ich mache nach vielen Jahren noch Fehler, d.h. kann nicht garantieren, dass ich den Algorithmus wirklich 100% verstehe und vor allem fehlerfrei implementiere. Dafür gibt es dann eine Qualitätskontrolle.
    Zum Einwand von Lucas de Vil: Auch Verschlüsselungsalgorithmen können völlig offengelegt sein. Z.B. ist ja bekannt wie DES oder RSA gehen. Und es gibt sogar Open-Source-Versionen. Der Trick der Sicherheit liegt dann doch darin, dass man die Umkehrung einfach nicht berechnen kann, außer wenn man den richtigen Schlüssel kennt.
    Bei einem PNG-Bild könnte man z.B. die einzelnen Bits nacheinander in den niederwertigsten Bits von Pixeln verstecken. Aber die Sequenz der Pixel-Koordinaten vom Schlüssel abhängig machen. Z.B. wenn die Pin 1234 ist, dann wird z.B. mit Pixel n=1234 angefangen. Dann kommt z.B. n := (2*n + 1) % zahl-der-pixel. Oder etwas komplizierteres (z.B. der Schlüssel einmal mit sich selber durch DES gedreht). Der Algorithmus wäre offen und wenn der Code auch noch offen ist, dann könnte man nachschauen ob ein Implementierungsfehler vorliegt. Dennoch würde der Schlüssel selbst nicht gespeichert bzw. kann nicht (einfach) herausgefunden werden. Außer der hier beschriebene Algorithmus taugt nichts und verrät (z.B. über statistische Eigenschaften) wo der Schlüssel anfängt.

    Es besteht die Möglichkeit einen individuellen Schlüssel zu vergeben.


    Der Empfänger der Nachricht muss diesen Schlüssel dann kennen, andernfalls besteht für ihn oder Dritte keine Möglichkeit die Nachricht zu lesen.


    Ok, aber ist es Open Source so dass ich prüfen kann was genau passiert? D.h. was mich umtreibt ist die Frage woher ich weiß, dass der Schlüssel überhaupt und korrekt verwendet wird? Mit 3 Beispielübertragungen geht das vermutlich nicht... Und warum sollte man Dir (als Black-Box-Programmierer) mehr vertrauen als irgendjemand sonst?

    Ja, finde ich interessant (auch wenn das Verfahren nicht wirklich neu ist und als digitales Wasserzeichen schon lange verwendet wird).
    Was mir noch nicht klar ist, wie das insgesamt abgesichert ist.


    Ist das z.B. Open Source, damit ich prüfen kann was da eigentlich passiert und ob das Verfahren auch wirklich sicher ist?


    Und kann ich das z.B. mit einem nur mir und dem Empfänger bekannten Schlüssel irgendwie so verändern, dass nur wir beide die Daten extrahieren können falls das Bild irgendwie öffentlich wird?