Show Posts
Pages: [1] 2 3 ... 234
1  International / Deutsch / Re: Hardware passwordmanager mit Display, Knopf und Endlosimpulsgeberpoti on: Today at 01:37:26 pm
Selber was Sicheres hinzubekommen ist wirklich ***sehr schwierig***. An der Rechenleistung würde es aber nicht scheitern. Sowas würde man mit symetrischen Algorithmen absichern und dafür braucht man nicht annähernd die Rechenleistung wie für Public Key Algorithmen.

Das schon genannte Keepass ist für die meissten Leute mehr als genug.
Wer Google Mail nutzt braucht sich um Passwortsicherheit eh keinen besonderen Gedanken zu machen.
Wer Rechner am Internet hängen hat und darauf Keepass am Start hat, der hat auch weniger Sicherheit als er sich vorstellt.

Umfassende Standardliteratur gibt es sogar kostenlos zum Download: http://www.cl.cam.ac.uk/~rja14/book.html ist ein exzellenter Startpunkt für Einsteiger.
2  International / Deutsch / Re: Zeitschaltuhr mit DCF77 on: September 18, 2014, 10:56:21 am
Interessant sind auch die korrekte Behandlung von Schaltsekunden sowie Sommer-/Winterzeit Umstellung . Soll die Schaltuhr in UTC schalten oder in CET/CEST? Und immer dran denken, es ist NICHT richtig, daß jeder Tag 86400 Sekunden lang ist, denn es gibt Minuten die  61s haben (und theoretisch auch welche mit 59s).

Was passiert wenn die Uhr lange nicht synchronisiert hat? (Wobei das bei meiner Library: http://blog.blinkenlight.net/experiments/dcf77/dcf77-library/ eher selten bis gar nicht vorkommen sollte.)
3  International / Deutsch / Re: switch case "umgehen" on: September 14, 2014, 05:03:19 am
Na dann fragen wird doch mal den Compiler:

Am Beispeil von  http://blog.blinkenlight.net/experiments/basic-effects/persistence-of-vision/

Mit Progmem:
Code:
/tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.eep
avr-objcopy -O ihex -R .eeprom /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.hex
Binary sketch size: 1066 bytes (of a 30720 byte maximum)

Ohne Progmem:

Code:
void blink() {
    static uint16_t index = 0;

    PORTC = pov_pattern[index++];
    PORTB = pov_pattern[index++];
    PORTD = pov_pattern[index++];

    if (index >= sizeof(pov_pattern)) { index = 0; }
}

Code:
/tmp/build3560765376939368227.tmp/core.a -L/tmp/build3560765376939368227.tmp -lm
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.eep
avr-objcopy -O ihex -R .eeprom /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.hex
Binary sketch size: 1082 bytes (of a 30720 byte maximum)

1082 - 1066 = 16

--> Man sollte bei Optimierungen IMMER den Compiler fragen und nicht irgendwelche Halbwahrheiten aus dem Internet zitieren. Das Problem ist, daß die oben zitierte Stelle verschweigt, daß das initiale Umkopieren vom Flash in den SRAM auch Platz braucht.

Es hängt immer von der jeweiligen Programmstruktur ab was mehr oder was weniger Platz braucht.
4  International / Deutsch / Re: switch case "umgehen" on: September 14, 2014, 02:58:42 am
Wenn Du die Daten "aus dem SRAM liest", was glaubst Du wie die da hinkommen? Der Compiler generiert Code damit die da hinkommen. Und wie liest Du Daten aus dem SRAM? Auch das kostet Platz. Würde mich wundern wenn PROGMEM mehr Platz kostet.
5  International / Deutsch / Re: switch case "umgehen" on: September 14, 2014, 01:27:31 am
Zeig uns doch den vollständigen Code, da gibt es sicher noch mehr zu holen. Die Arraylösung ist nicht schlecht belastet aber das SRAM unnötig. Lies mal unter PROGMEM nach wie man das noch besser macht: http://arduino.cc/en/pmwiki.php?n=Reference/PROGMEM. Und hier ein Beispiel wie man das einsetzen kann: http://blog.blinkenlight.net/experiments/basic-effects/persistence-of-vision/.
6  International / Deutsch / Re: Windows Problem mit dem Großschreiben on: September 09, 2014, 12:04:58 pm
Da ich Caps Lock NIE haben will entferne ich das einfach immer per Registry Eintrag http://johnhaller.com/useful-stuff/disable-caps-lock. Vieleicht hilft das ja auch bei einem WIndows in einer VM.
7  International / Deutsch / Re: Arduino in der Schule on: September 09, 2014, 12:02:53 pm
Ich hätte auch noch ein paar Punkte:

- Zu jedem Arduino wird man auch einen Computer benötigen auf dem die IDE installiert ist. Hat die Schule die Computer?
- Arduinos sind zwar "relativ" robust, aber Schüler werden nicht unbedingt pfleglich mit dem Material umgehen. Das muss nicht einmal böser Wille sein. Für einen Kurzschluss reicht es ja aus die nakte Platine auf eine Schere oder einen Stift aus Metall zu legen.
Wie sieht es mit Ersatzbeschaffung aus? Wie sieht es bei Shields aus wenn die öfters umgesteckt werden? Die Kontakte sind für sowas definitiv nicht ausgelegt.
8  International / Deutsch / Re: Tips für Layout zur Platinenherstellung on: September 07, 2014, 04:43:29 am
Ja, Eagle ist nicht super einfach zu lernen. Sobald Du aber den Bogen raus hast ist es klar, daß Eagle die bessere Wahl ist smiley-wink
9  International / Deutsch / Re: Habe eine Frage zu Library verwendung on: September 07, 2014, 04:42:17 am
Schau Dir mal meine Seiten an. Meine DCF77 Library ist garantiert besser als jede andere Arduino DCF77 Library und Beispiele sind auch jede Menge dabei:  http://blog.blinkenlight.net/experiments/dcf77/dcf77-library/.
10  International / Deutsch / Re: DCF77 – macht keinen Spaß on: September 02, 2014, 11:33:21 am
@RudiRabbit: der Link ist aktiv.

@SkobyMobil: ich werte die Daten schon aus. Nur eben nicht "direkt" sonder "statistisch". Und deshalb wird meine Library auch mit Rauschen fertig. Warum das einen Unterscheid macht hat Uwe ja schon erklärt. Die Sache mit den "minimalsten Mitteln" ist genau der Punkt wo die Leute dann frustriert sind weil ihr "super einfacher" Dekoder sich schon von einem Monitor oder anderen leichten Störern aus der Ruhe bringen laesst.
11  International / Deutsch / Re: DCF77 – macht keinen Spaß on: September 01, 2014, 10:30:38 am
@uwe: bei 1 bit pro Jahr braucht es bei optimaler Dekodierung trotzdem mehrere Jahrzehnte um die genau Zeit zu finden. Aber theoretisch ist sowas machbar ... falls man eine gute genuge Zeitbasis hat .... Falls man aber eine so gute Zeitbasis hat, daß man über ein paar Dekaden nur 1/100s abweicht, dann ist man vermutlich eh an der Quelle smiley-wink

@Jurs: das was Du erklärst reicht um kurze Transienten wegzubüglen. Dein Ansatz würde immer noch eine sehr hohe Bitrate brauchen. Mein Ansatz drückt die notwendige Bitrate. D.h. mit Deiner Methode engst Du die Empfängerbandbreite auf um die 10 Hz ein. Mein Ansatz führt zu einer effektiven Bandbreite weit unterhalb von 1 Hz. Oder anders: ich werde mit einem 10-20 dB schlechteren SNR noch ziemlich gut fertig.  Der Preis dafür ist die aufwändigere Dekodierung.

Oder nochmal anders: stellt Euch einen verrauschten 4 Bit Zähler vor. Der Zähler zählt

Code:
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

Der Empfänger sieht aber wg. Rauschen


Code:
0010
0101
0010
1011
0110
0101
1110
0101
1001
1101
0010
1011
1101
1111
1010
1110

Was tun? Einfach beim Empfänger auch zählen und schauen bei welchem Phasenversatz die Fehlerquote am niedrigsten ist. Das nennt der Statistiker "Korrelation". In der Signalverarbeitung berechnet man stattdessen sogenannte Faltungen die eben bei der korrekten Phasenlage ein Maximum haben. Um die Performance in den Griff zu bekommen muß man gewaltig tricksen, daber das ist die Grundideee.
12  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 12:26:34 pm
Das Prinzip ist wie folgt:

Seit Herr Shannon das vorgerechnet hat, ist bekannt, daß man bei einem verrauschten Kanal weniger Daten übertragen kann als in einem unverrauschten Kanal. Das ist qualitativ klar, Shannon hat es aber quantifiziert.

Das Problem ist nur: wie komme ich mit weniger Informationen auf die Zeit?

Die Erkenntnis ist, daß das vollständige Signal lokal synthetisiert werden kann (von Schaltsekunden mal abgesehen). Ergo: ich muss es gar nicht dekodieren, ich muss nur wissen "wo" in der Zeichenfolge der Sender gerade steht. D.h. mein Dekoder versucht überhaupt nicht das Signal zu dekodieren, er kennt es schon vorher. Stattdessen versuch er die Phase zu detektieren. Oder anders ausgedrückt: statt ~40 Bits pro Sekunde kommt dieser Ansatz mit weniger als 1 Bit pro Sekunde aus. Folglich sind 10 Bitfehler pro Minute noch überhaupt kein Problem.

Wenn genug Speicher da wäre und eine ausreichend genaue lokale Uhr, dann würde auch eine Rate von 1 Bit pro Jahr reichen. Aber mit einem Arduino kannst Du das vergessen.

Theoretisches Grundprinzip: verschiebe die lokale Zeichenfolge so lange bis sie optimal zur ausgesendeten passt. Die Phasenlage erlaubt dann die Zeit zu ermitteln.

Praktische Implementation mit schlappen 2k RAM: das ganze wird implementiert als "gestackter matched Filter". Mit fällt keine bessere Beschreibung dafür ein.


Wenn Du das nicht verstehst, mach Dir nichts draus. Auf solche Ideen kommt man nicht ohne entsprechende Vorbildung. Falls solche Begriffe wie "Faltung", "FFT", "Filterkern" Dir nichts sagen, dann hast Du wenig bis gar keine Chancen sowas zu entwickeln. Dann musst Du einfach glauben, daß ich ganz genau weiss was ich tue smiley-wink Oder Du nimmst einfach meine Library und freust Dich, daß Sie gut funktioniert smiley
13  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 06:38:25 am
Danke, das ist mir doch glatt entgangen. Auf die Funktion der Uhr hat das aber keine Auswirkung. Hat hier jemand einen Vorschlag wie man das auf Englisch nennen sollte? Call Bit? Bleep?
14  International / Deutsch / Re: finde den Fehler on: August 31, 2014, 03:56:28 am
Warum nicht gleich

Code:
 digitalWrite(relay3, !(myRTC.hours >=  8 && myRTC.hours < 13 ||
                         myRTC.hours >= 15 && myRTC.hours < 20));
15  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 03:49:30 am
Mir fallen zu dem DCF77 Problem ein paar Dinge ein:

1) Nachschauen ob das Signal sauber ist. Z.B. damit: http://blog.blinkenlight.net/experiments/dcf77/dcf77-scope/

2) Die Sache mit dem Störnebel wird immer gerne übertrieben. Häufig kommt aus den Modulen noch ein Signal raus. Die Wahrheit ist, daß die meissten DCF77 Libraries keine brauchbare Fehlerkorrektur haben. Meine Library: http://blog.blinkenlight.net/experiments/dcf77/dcf77-library/ hingegen hat das Ziel die Entstörung soweit zu treiben wie man es auf einem Arduino hinbekommen kann. Hier http://blog.blinkenlight.net/experiments/dcf77/the-clock/ könnt Ihr Euch Videos anschauen wie eine ältere Version (die neue Library ist besser) damit fertig wird, wenn die Antenne direkt auf einem Motor liegt. Mittlerweile lege ich zum Testen oft ein Smartphone auf die Antenne --> überhaupt kein Problem.

3) Wem die Library zu fett ist kann das auch komplett in ein extra Modul auslagern: https://blinkenlightblog.wordpress.com/experiments/dcf77/super-filter/ (Der Link steht erst am 1.9. zur Verfügung, ich schreibe noch smiley-wink

-Udo
Pages: [1] 2 3 ... 234