Geschrieben June 15, 2012 at 11:5815. Jun 2012 Jetzt lass ich mal mit 30s laufen, und ich wollte noch sagen, das die temp-bricklets bis zum 23.5. alleine liefen (in der Zeit kamen auch keine Fehler, allerdings lief bis dahin noch ein php-skript, seitdem logge ich mit Python)
Geschrieben June 15, 2012 at 20:1415. Jun 2012 Autor Die Programmiersprache ist somit wohl egal ich hab ein Javaprogramm wo der Fehler aufgetreten ist. Ist das Temp. Bricklet alleine sind bei mir auch keine Fehler aufgetreten.
Geschrieben November 10, 2012 at 21:0010. Nov 2012 Ich hab mal auf die Schnelle eine Firmware gemacht welche die Temperatur mit 100khz statt 400khz ausliest: http://download.tinkerforge.com/_stuff/temperature-bricklet-100khz.bin Dann sollten wir wohl noch was zu Kabellänge und I2C in die Doku schreiben. Ich habe ein weiteres Temp.Bricklet und eine Humidity Bricklet - jeweils an einem 2m-Kabel. Nun gibt deas Temp.Bricklet Fehlerwerte aus: z.B.: -127 / -90, ... Da wollte ich in Erfahrung bringen ob es nun doch mit der Leitungslänge zu tun hat und ob die 100KHz implementiert sind. Oder ob es an was anderes liegen kann.. Oder noch einmal andersrum gefragt: Kann ich an einen Master 4 Sensoren mit jeweils 200cm Kabellänge anschließen?? Danke
Geschrieben November 11, 2012 at 10:4611. Nov 2012 Autor @jan Also bei mir besteht das Problem auch immer noch wenn ich eine "normale" Firmware nehme. Die mit 100khz funktioniert dagegen super. Grundsätzlich sollte es möglich sein alle 4 Bricklets an einem Master mit 2m Kabeln zu betreiben. Soweit ich weiß ist die Grenze 12m gesamt. @borg Kann dieser Fehler mit dem Protokoll 2.0 auch noch auftreten??
Geschrieben November 11, 2012 at 20:2911. Nov 2012 Protokoll 2.0 hat damit soweit erstmal nichts zu tun. Ich habe die Hoffnung, dass die neuen geschirmten Bricklet Kabel das Problem endgültig lösen. Falls diese nichts bringen, können wir da mit Hardware wohl nichts gegen unternehmen. Wir müssen dann wohl eine Firmware bauen mit der man zwischen den 100 und 400khz umstellen kann.
Geschrieben November 11, 2012 at 20:4611. Nov 2012 Was war ncohmal das Problem bei den anderen Frequenzen?
Geschrieben November 11, 2012 at 20:5211. Nov 2012 Bei hohen Frequenzen können (Bit-)Fehler nicht gut genug kompensiert werden. Vielleicht kann man das mit der I2C-Frequenz mit Softwareseitig "tunen", so wie die Baudrate beim RS485.
Geschrieben November 13, 2012 at 06:5613. Nov 2012 Ok. bin dem angepassten Plugin funktioniert es ohne Fehler. Vielleicht kann man das ganze bis zur Fehlerbehebung mit in die Doku mit aufnehmen inkl. Downloadlink. Dann muss man sich nicht durch die Untiefen des Forum graben ;-) Danke
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.