Jump to content

arminiusdc

Members
  • Gesamte Inhalte

    60
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von arminiusdc

  1. Hallo Borg, ich habe mal ein Buch über dem Bricklet zusammen geschlagen ( bin in einer Bibliothek ) dann kommt was. Ich hätte nicht gedacht, daß unsere Klimaanlage so gut ist. Welche Partikelgröße wird noch detektiert? Vielleicht hätte ich doch mal die Datenblätter durchschauen sollen. Also bei euch im Büro zeigt er was von 0 verschiedenes an ( wenn gerade keiner raucht ) ? mfg Armin
  2. Habe eine Bleistift reingesteckt dann zeigt er 500 an. Im BrickViewer kann ich das nachverfolgen. Bleistift rein 500 dann wieder raus 0. mfg Armin
  3. Hallo, habe gerade meine neuen Dust Detector Bricklet in Betrieb genommen aber er zeit immer 0 µg/m³ an. Getestet mit master 2.0 Firm: 2.3.4 über usb und Brickviewer 2.3.3 und mit Stack Red-brick Master Extension TCP mit POE master 1.0 2.3.4 Humindity Bricklet 2.0.2 Barometer Bricklet 2.0.2 Temperature Bricklet 2.0.3 LCD 20x4 Bricklet 1.0 2.0.6 master 2.0 Firm: 2.3.4 Dust Detector Bricklet 2.0.0 Im Stack weder über tcp noch über usb kommt ein von 0 verschiedenes Ergebnis. Im Progrom mit Callback kommt nichts ( ist ja klar keine veränderung ) und mit $dust->get_dust_density() kommt immer 0. Was soll ich machen mlg Armin
  4. Hallo Borg, alles klar dann hoffen wir auf die Zukunft. Sonst scheint bis jetzt alles zu gehen. Was ich so benötige. Stellt ihr noch jetzt das Image um oder muss man jetzt immer von Hand den link erzeugen wenn man ethernet hat ? mfg Armin
  5. Hallo Borg, ja damit geht es deutlich besser . Wie testet ihr eigentlich die Images ? ;D mfg Armin
  6. Hallo Jungs, mit dem 1.4 Image wird die Ehternet( mit POE) nicht mehr erkannt. Im brickv unter Red-Brick / Settings wird No Interfaces available angezeigt. Mit dem 1.3 Image kein Problem. Über die Console ifconfig bringt nur lo Was ist zu tun ?? mfg Armin
  7. Hallo Proton, wäre es nicht besser die Funktion doch so wie is_backlight_on vom LCD zu implementieren und nicht auf einmal so eine komische Logik mit 0 is True und 1 ist False zu definieren ? mfg Armin
  8. Hallo Proton, die Doku sagt BrickletColor.is_light_on Funktions ID: 12 Anfrage: keine Nutzdaten Antwort: light -- uint8 Gibt true zurück wenn die LED aktiv ist, sonst false. http://www.tinkerforge.com/de/doc/Software/Bricklets/Color_Bricklet_TCPIP.html#color-bricklet-tcpip-api Welche Doku hast du denn ? mfg Armin
  9. Hallo kann es sein das is_light_on negiert ist ? im Code void is_light_on(const ComType com, const IsLightOn *data) { IsLightOnReturn ilor; ilor.header = data->header; ilor.header.length = sizeof(IsLightOnReturn); ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask ? 0 : 1; BA->send_blocking_with_timeout(&ilor, sizeof(IsLightOnReturn), com); } die Zeile ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask ? 0 : 1; dreht die Logig um. Besser währe ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask ? 1 : 0; oder gleich ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask; mfg Armin
  10. Morgen bin mal wieder dazu gekommen. Anbei Perl für Proto 2.0. Wie üblich der Generator (brick_gen) um aus den configs das Modul (brick.pm) zu bauen und ein Beispiel (t8.pl) eine Wetterstation mit Joystick . Armin brick.pm brick_rumpf.pm brick_gen.pl t8.pl
  11. Also mein Display ( 3 Knöpfe ) geht nicht mit der force firmware. Nur wenn ich 2.0.2 flashe gehts.
  12. Danke für den Hinweis. bin ja mal gespannt wann die Doku dafür kommt. Ist aber doof wenn ich das Proto 2.0 implementiere und erst meine Fehlerbehandlung zeigt mir das die Doku noch ergänzt werden muss . Bin selbst Informatiker und kenne das Problem: Hauptsache es läuft Doku später. Armin
  13. Nochwas Da ich gerade beim implementieren von 2.0 bin: Wenn ich den Stack über wlan ansprechen kommen ständig Packete 0x00000000,0x08,0x00,0x08,0x00 was ist das ? Über USB kommen diese Pakete nicht. Wo ist die Doku dazu ? Sieht aus wie keep-alive oder so. Beim Proto 1.0 gab es diese Pakete nicht. mfg Armin
  14. Hallo was will uns uint16_t device_identifier; sagen ? Wirklich device_identifier – uint8 oder doch device_identifier – uint16 ??? Ich glaube nicht. Dann implementiere ich das mal als device_identifier – uint16. mfg Armin
  15. Hallo ich habe noch mal die sourcen durchgeschaut und Oh Wunder in packet.h vom brickd typedef struct { PacketHeader header; char uid[8]; char connected_uid[8]; char position; uint8_t hardware_version[3]; uint8_t firmware_version[3]; uint16_t device_identifier; uint8_t enumeration_type; } ATTRIBUTE_PACKED EnumerateCallback; also nicht immer was behaupten ohne es zu prüfen. Könnt ihr bitte die Doku entsprechend ändern ? mfg Armin
  16. Hallo, also ich habe ein brickd 2.0.4. mit einem Master 2.0.6 dann kommt im dump 2 * char[8] und nicht uint32 Ich habe zum Testen nur die IPConnection gemacht mit syswrite ein enumerate pack("LCCCC",0,8,254,0x10,0) geschickt und dann dumpe ich mir die Antwort vom brickd und die ist auf keinen Fall uint32 sondern char[8]. Kannst du dir mit tcpdump gerne mal anschauen. auf Windows 7 64bit Prof. mfg Armin
  17. Hallo batti, bin gerade bei 2.0 Implementation. Hab ihr aktuelle Doku z.B für CALLBACK_ENUMERATE Funktions ID: 253 Antwort: uid – uint32 connected_uid – uint32 position – char (as ascii) hardware_version – uint8[3] firmware_version – uint8[3] device_identifier – uint8 enumeration_type – uint8 die von der TCP/IP Doku ist auf jeden falsch!!!!! ich rate mal uid – char[8] connected_uid – char[8] position – char (as ascii) hardware_version – uint8[3] firmware_version – uint8[3] device_identifier – uint8 enumeration_type – uint8 kann das sein ? und wenn das richtig ist was soll das hoffe auf Antwort. mfg Armin
  18. Danke für die schnelle Antwort das wars. Warum liefert ihr ungeflashte bricklets aus ? mfg Armin
  19. arminiusdc

    GPS Bricklet will nicht

    Morgen, habe laut Anleitung GPS mit Master 2.0 verbunden. Alles auf neuster Firmware ( gerade frisch bekommen ). Effekt ist : 1. Master bootet nicht ( kein Lauflicht ) 2. beim GPS Bricklet blinkt Fix und sonst nichts 3. brickv findet nichts Bootet der Master nur wenn eine Position auf dem GPS Bricklet erkannt wurde ? Was ist zu tun ? mfg Armin
  20. Hallo Leute mal wieder neu Perl-Bindings. Ich würde mich über etwas FeedBack freuen. Gibt es noch andere die Perl benutzen. Armin brick.pm brick_rumpf.pm t6.pl brick_gen.pl
  21. die Konstante ist sizeof(Header). head = read(sizeof(header)); payload = read(head[4]); mfg Armin Mhh, ich weiß nicht. Du musst ja erstmal über den Socket die komplette length empfangen. An der Stelle muss ja eigentlich keine Konstante drauf. also ich denke an sowas wie (Pseudocode) bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); }
  22. Hallo Borg, also ich hätte da noch was. Da ich das Protokoll auch wieder implementieren muss ( Perl ) würden folgender Punkt die Arbeit erleichtern 1. length bitte nur von der PayLoad und nicht wieder vom ganzen Packet, beim Senden Konstante drauf, beim Empfangen Konstante wieder runter. mfg Armin
  23. das ist doch mal ein Hinweis. Dann nimm doch bitte ActivePerl das ist mit Threads oder übersetze dein Perl mit Threads. Ich habe extra für TF auf Threads umgestellt hatte es vorher ohne threads gelöst. Armin
  24. Hä Was willst du uns sagen ? Also diese Threads funktionieren ganz gut, in Linux besser als in Windows. Aber da es ja nur über USB oder WLAN geht, ist die Geschwindigkeit mehr als ausreichend. Was hast du denn in Perl schon versucht zu steuern und was hat nicht funktioniert ? Armin
  25. sieht gut aus, Läuft jetzt ca 1h und max Delta ist 0,038 mit 500 ms Abtastung. Armin
×
×
  • Neu erstellen...