Jump to content

borg

Administrators
  • Gesamte Inhalte

    3.592
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    58

Alle erstellten Inhalte von borg

  1. Tinkerforge auf Messen 2016 Blogeintrag
  2. Tinkerforge at Trade Fairs in 2016 Blog Entry
  3. Indeed, that looks different. Does the flat value recover after a while or do you definitely have to reset? I just looked through the code, if "is_sensor_connected()" returns true during the flat time, it means that the MAX31865 IC that we use on the PTC Bricklet does return the same resistance for the whole time. If you reset the Master Brick, the MAX31865 will be reinitialized. But during initialization we only configure the default values again. For testing, could you try to call "set_noise_rejection_filter" (it does not matter if you turn it on or off). Internally this will also set the whole configuration again. Does this also fix the problem? If it does fix the problem, we may have to set the configuration periodically in the firmware? Sounds strange, but i currently have no other idea .
  4. Good to know that it works now. As long as the resistance from the PTC sensor is in a "possible range" it can't tell that it isn't connected correctly. I think that was probably the problem here .
  5. Die 10 Kontakte an dem Bricklet Port müssen definitiv gelötet werden, nur mit kleben funktioniert das nicht . Am besten du schickst den Master Brick (inklusive abgerissener Buchse) ein, dann gucken wir uns das an ob da eventuell etwas nicht korrekt angelötet war und tauschen den Master Brick entsprechend aus.
  6. Huch? Das ist komisch, ich kann mir gar nicht erklären wie das überhaupt passieren kann. Gucke ich mir an, wird auf jeden Fall gefixt . Edit: Der Fehler ist in der Tat im Brick Viewer, ein einfacher Copy/Paste-Fehler natürlich . Das wird in der nächsten Version gefixt.
  7. Update of Ethernet Extensions, new Accessories Blog Entry
  8. Update der Ethernet Extensions, neues Zubehör Blogeintrag
  9. Uhm, das ist noch bei uns in der Forschungsabteilung, da haben wir noch keine genaueren Informationen zu .
  10. Uh, that is indeed a little misleading. What we mean is that the API returns mV, but the resolution is 10mV. Which does not mean that it has a absolute precision of +-10mV. Nevertheless, by increasing the averaging you can increase the resolution and precision (although we do always round to full 10mV in the firmware).
  11. Wird noch ca. einen Monat dauern, kommt aber .
  12. Um dein Problem nochmal zusammenzufassen: Wenn du einen "Schreibtischtestaufbau" hast geht alles und sobald du es verbaust kommen die Fehler. Richtig? Wie genau verbaust du es? Ist die Kabellänge im verbauten Zustand anders? Das sollte irrelevant sein.
  13. Das ist komisch, ich versuche das mal hier nachzustellen. Kannst du zum testen die Periode runterdrehen? Also z.B. auf 250Hz (alle 4ms)? Tritt das Problem dann nicht mehr auf?
  14. Sweet!
  15. Das würde ja bedeuten, dass die Step-Down Power Supply das Remote Switch Bricklet irgendwie stört? Kannst du zum testen das Bricklet weiter vom Stapel entfernen (mit einem längeren Kabel)? Macht das einen Unterschied?
  16. Mhh, wie sieht denn das Programm aus welches die Werte abfragt? Einfach eine Endlosschleife die Getter aufruft? Das sollte eigentlich unproblematisch sein. Bei Bitfehlern auf der Leitung würde ich eher erwarten das es Ausreißer bei den Werten gibt, nicht das es zu einem Timeout kommt.
  17. Wie sieht das Programm aus, welche Einstellungen hast du gewählt?
  18. Eine einfache Anleitung wie man die Bindings auf dem RED Brick updated fehlt in der Tat noch. Grundsätzlich kann man sie so updaten wie es auf den jeweiligen Bindings-Seiten beschrieben ist. Ein Button im Brick Viewer wäre natürlich optimal.
  19. Eigentlich sollte da nichts gegen sprechen. Ich könnte mir vorstellen das irgendwann die Stromversorgung nicht mehr mitmacht (wenn die Servos alle exakt gleich angesteuert werden, ziehen sie natürlich auch zur exakt gleichen Zeit ihren Anlaufstrom). Aber du kannst ja zum Testen erst mal mit 2 Servos an einem Port anfangen bevor du gleich 8 Stück dranklemmst .
  20. So the wrong values disappear immediately if you restart the Master Brick? That is very strange, it implies that there is some kind of "bad state" that is lost after a restart of the Master Brick. Do you have to disconnect the power or is it enough to press the reset button?
  21. Perhaps the sensor is not screwed into the terminal tightly enough and there is a loose connection?
  22. Wichtig ist, das die Luft die du messen willst auch durch das Loch im Dust Detector strömt. Ich denke das Bricklet im Ansaugbereich von einem Lüfter zu installieren wäre schon genau richtig.
  23. We now have samples for Java, C# and Python: http://www.tinkerforge.com/en/doc/Hardware/Bricklets/OLED_128x64.html#usage
  24. Nein, wird aktuell nicht unterstützt. Wenn es da interesse gibt könnte ich allerdings gucken ob wir das implementieren können auf dem LED Strip Bricklet. Bei Adafruit gibt es auch "NeoPixel". Die werden vom LED Strip Bricklet unterstützt (WS2812).
  25. We will add more examples for the OLED API, they are already in the making. Let me explain this a bit more: Each Bricklet has 4kb flash and 256 byte RAM to implement the API. So having a function like drawLine(xy, xy) on the Bricklet is simply not possible. Just saving the whole 128x64 image would use 1kb of RAM. The fixed size 7x5 font that we provide already uses up 1.25kb of the available flash (https://github.com/Tinkerforge/oled-128x64-bricklet/blob/master/software/src/font.inc). So it is technically just not possible to add much more API to the Bricklet. Knowing the above, we obviously need to draw to a buffer on the PC and then transfer the buffer to the Bricklet. Now again, it doesn't make any sense to implement an image draw API in all of the programming languages that we provide. Every high level language already has a image drawing library that is much better then anything we could provide. So the way to go is to provide more complex examples for the languages that use image libraries which are native to the language, which is what we intend to do. I hope this explanation makes it more understandable why the API is how it is. For example the whole drawing code for this video ( ) is this: # Create angle text angle_str = str(angle) + u'°' if angle >= 0: angle_str = ' ' + angle_str # Draw servo position line img = Image.new('1', (128, 64), 0) draw = ImageDraw.Draw(img) draw.line(line_at_angle(32, 32, angle - 90, 32), 1, 6) # Draw bar graph draw.line((90, 4, 90 + angle*30//90, 4), 1, 6) # Draw angle text font = ImageFont.truetype("./share/fonts/truetype/dejavu/DejaVuSans.ttf", 25) draw.text((70, 22), angle_str, font=font, fill=1) # Move data from PIL image into matrix of bools data = img.load() pixel_matrix = [[False]*SCREEN_WIDTH for i in range(SCREEN_HEIGHT)] for x in range(SCREEN_WIDTH): for y in range(SCREEN_HEIGHT): pixel_matrix[y][x] = data[x, y] == 1 After that the pixel_matrix is drawn to the display with the draw_pixel_matrix function that we have as an example for all of the available programming languages. This seems very much high level to me .
×
×
  • Neu erstellen...