agp8x Geschrieben June 15, 2012 at 11:58 Share Geschrieben June 15, 2012 at 11:58 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) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
thunderbird Geschrieben June 15, 2012 at 20:14 Autor Share Geschrieben June 15, 2012 at 20:14 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben November 10, 2012 at 21:00 Share Geschrieben November 10, 2012 at 21:00 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
thunderbird Geschrieben November 11, 2012 at 10:46 Autor Share Geschrieben November 11, 2012 at 10:46 @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?? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben November 11, 2012 at 20:29 Share Geschrieben November 11, 2012 at 20:29 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben November 11, 2012 at 20:46 Share Geschrieben November 11, 2012 at 20:46 Was war ncohmal das Problem bei den anderen Frequenzen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben November 11, 2012 at 20:52 Share Geschrieben November 11, 2012 at 20:52 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben November 13, 2012 at 06:56 Share Geschrieben November 13, 2012 at 06:56 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.