Search the Community

Hello, For a Master Brick 3.1 (HW version 3.0.0, FW 2.5.1, Ruby bindings 2.1.29), it seems #get_usb_voltage always returns 0 (zero). The documentation says "Returns the USB voltage. Does not work with hardware version 2.1". I am asking because I have a stack powered via USB by a power pack.

Hello, I have a WIFI Master Extension 2.0 mounted on top of a Master Brick 3.1 As per the documentation I can control the green status LED of the WIFI Extension 2.0 with two methods: #enable_wifi2_status_led #disable_wifi2_status_led When I call the disable method, the led turns off, and #is_wifi2_status_led_enabled returns false, as expected. When I call the enable method, the led does not turn back on, but #is_wifi2_status_led_enabled returns true. Only when I reset the Master Brick does the green LED turn on again. Am I doing something wrong or is this a bug? (Edited to clarify #is_wifi2_status_led_enabled returns expected result)

Hello, The documentation says #get_chip_temperature returns chip temperature in units of 1/10 °C for Master Bricks. I assume this is a typo, and it actually returns 1/100 °C.

Hello, I have a problem with a brand new LCD 128x64 Bricklet connected to a HAT Brick with a brand new cable. The Bricklet is responding normally to API calls. brickd.log shows thousands of errors like this: 2020-12-18 08:52:06.937629 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5721) 2020-12-18 08:52:24.206204 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5722) 2020-12-18 08:52:41.476851 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5723) 2020-12-18 08:52:58.746923 <E> <bricklet_stack.c:478> Message checksum error (port: G, count: 5724) Question #1: Can you point me to a document somewhere outlining what to do in a case like this? How do I diagnose and solve this problem? Both the Brick and the Bricklet do not seem to report these errors through the API (this is Ruby): > hat.get_identity => ["S2c", "0", "i", [1, 0, 0], [2, 0, 2], 111] > hat.get_spitfp_error_count => [0, 0, 0, 0] > lcd.get_identity => ["R3S", "S2c", "g", [1, 0, 0], [2, 0, 9], 298] > lcd.get_spitfp_error_count => [0, 0, 0, 0] Question #2: Using the API, how can I check for problems like the above (excessive checksum errors) ?

Hello, Maybe I'm wrong, but I have a suspicion BrickletSegmentDisplay4x7V2#get_segments does not return correct values. I think the Bricklet responds with correct data, but the data is mangled when unpacked. To be precise, when data is unpacked for the first segment (8 values), too much data is slurped so nothing remains for the other 27 values. Here is a quick & dirty debug helper: module Tinkerforge class BrickletSegmentDisplay4x7V2 def debug_get_segments puts ' |.......|.......|.......|.......|.|' puts 'get_segments : ' + get_segments.flatten.map { |b| b ? '1' : '0' }.join puts 'actual response: ' + (send_request FUNCTION_GET_SEGMENTS, [], '', 14, '?35' ).map { |b| b ? '1' : '0' }.join puts '' end end end

Hello, I have a question about discovery of devices with Ruby. Enumeration supplies the numeric device_identifier for each device, for instance 2103 for a 'LED Strip Bricklet 2.0'. See documentation. Next steps would be to load the file defining the matching class, and to initialize an instance of that class: require 'tinkerforge/bricklet_led_strip_v2' Tinkerforge::BrickletLEDStripV2.new ... In other words, I need the name of the matching class for a '2103 device' and the file which defines that class. Tinkerforge::DEVICE_DISPLAY_NAMES only maps device_identifier to device_display_name. How do I map numeric device_identifier to class and file? One way would be to load all 139 device classes, and than loop through all Tinkerforge::Device descendants until I find the one with the matching DEVICE_IDENTIFIER constant. That sounds like a really bad idea. Has anyone figured this out yet?