cl-

Welche Version von KiCad nutzt ihr? Auch Version 7? Wenn ich die kicad-libraries (euer git) in meine Library Path hinzufüge, bekomme ich den folgenden Fehler. Dieser Fehler macht aber eigentlich keinen Sinn, weil ich eine Version habe, die nach dem 20.11.2023 veröffentlicht wurde.

Hi all, based on the specifications documented on your website, the Laser Range Finder Bricklet 2.0 should be able to measure distances lower than 5 cm. In my first tests, I couldn't measure distances lower than 5 cm though. Is this a technical limit? Cheers Claudio Technical specifications: Distance (Range, Resolution): 0-40m, 1cm Accuracy <5m: ±2.5cm (nonlinearity present below 1m)

We would need the POE functionality to make our application possible (in terms of flexibility with cable lengths and infrastructural boundary conditions). The ESP32 Ethernet Brick is great (we use it in various use cases). However, the required/additional wiring for the power supply would make it impossible in our new use case. Extending the ESP32 Ethernet Brick with POE would also be a solution, but I understood that this is not priority for you at the moment. We are trying to match your POE hardware with the high data throughput capabilities of the accelerometer for vibration analysis.

Hi! I have a question that came up the other day. It is related to this one here. My current setup is: Master brick with POE Master Extension with one AccelerometerV2 Bricklet. For some reason, I don't reach the maximum possible data throughput of the Accelerometer (25600 Hz). I get around 12800 Hz without optimizing and between 13300 and 13400 Hz with an optimized setup (constant SPI baudrate set to 2.000.000 at the Master Brick). I repeated the same with the ESP32 Ethernet Brick and got the full 25600 Hz. The Master Brick itself (without a Master Extension) can also handle the 25600 Hz. Is it that the POE Master Extension cannot handle the continuous data stream of the accelerometer bricklet? Cheers Claudio

Wir haben das gleiche Problem gerade mit dem Accelerometer V2. @batti Welche Version verwendet ihr selber? Dann nutzen wir die auch einfach. Danke

Hi, your documentation states: "The Ethernet Extension can be used together with a Step-Down Power Supply." Does it mean that, when powering the stack with your Ethernet POE Extension and adding a Step-Down Power Supply to the bottom of the stack, I get stable 5V output voltage of the Step-Down Power Supply? Cheers Claudio

Ok. Problem wurde behoben durch ein sudo apt --fix-broken install Hmm, das hatte ich noch nie vorher.

Hallo zusammen, Mit einer frischen Raspberry Pi OS Installation (64-bit) mit Hilfe des Raspberry Pi Imager Tools kriege ich eine Fehlermeldung bei der Installation des Brick Daemons. Ich bin dabei eurer Doku gefolgt (https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Brick.html). sudo apt-get install libusb-1.0-0 libudev1 procps Reading package lists... Done Building dependency tree... Done Reading state information... Done libusb-1.0-0 is already the newest version (2:1.0.26-1). libusb-1.0-0 set to manually installed. libudev1 is already the newest version (252.19-1~deb12u1). procps is already the newest version (2:4.0.2-3). 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded. sudo dpkg -i brickd_linux_latest_armhf.deb (Reading database ... 125310 files and directories currently installed.) Preparing to unpack brickd_linux_latest_armhf.deb ... Unpacking brickd:armhf (2.4.5) over (2.4.5) ... dpkg: dependency problems prevent configuration of brickd:armhf: brickd:armhf depends on libc6 (>= 2.9). brickd:armhf depends on libusb-1.0-0 (>= 2:1.0.20). dpkg: error processing package brickd:armhf (--install): dependency problems - leaving unconfigured Processing triggers for man-db (2.11.2-2) ... Errors were encountered while processing: brickd:armhf Was mache ich falsch? Beste Grüße Claudio

Hi Jan, Ich kann es selber nicht testen, weil ich kein Stepper Bricklet habe. Meinst du den folgenden Fehler? Err(BrickletRecvTimeoutError::SuccessButResponseExpectedIsDisabled) Wenn ja, was passiert, wenn du ss.set_response_expected(SILENT_STEPPER_V2_BRICKLET_FUNCTION_SET_MOTOR_CURRENT, true) zu Beginn ausführt? Wenn nein, dann weiß ich auch nicht so genau ;-) Ist das auch bei den anderen recv() Aufrufen?

I have another problem that is related to my previous question: In your documentation, you say that "If the measured magnetic flux density goes above the high threshold or below the low threshold, the count of the counter is increased by 1." In the screenshot, I have a signal that ranges between 300 and 1200 uT (approx). This configuration works for the shown signal. For some reason though, that does not work anymore, when I change the low threshold to -7000 uT, for instance. The counter should still be incremented by the high threshold. However, doing that causes the counter to stand still for as long as I keep the low threshold to -7000 uT. Changing back to 350 uT makes the counter increase again. Now what's weird, the other way does work indeed, that is changing the high threshold to 7000 uT (instead of the 1150 uT). In this case, the counter works as expected, as the low threshold is still "active". What am I doing wrong? Why does the low threshold causes this weird behaviour? Any ideas? Cheers, Claudio

Once again (in short) As it's not allowed to call tf_hall_effect_v2_get_counter() inside the callback handler, one possible approach would be to set a flag inside user_data to trigger a manual counter reset outside the callback handler. However, if the delay between the callback handler was triggered and the subsequent, manual counter reset outside the callback is too long, one might in theory miss counters when the counter frequency is very high (or am I wrong?). I doubt that might ever play a role in my special use case (20 counters per second), but if one would approximate the maximum of 10 kHz? What's the right approach to reset the counter with the periodic callback? Or is it done automatically anyway, but it's just not "visible" in the source code?

I edited previous my post and wrote more details, but the forum kicked me out because it took "too long" to write. All my changes were lost somehow, which is strange.

Hi, I was wondering how to reset the Hall Effect V2 counter when using the periodic callback instead of the tf_hall_effect_v2_get_counter() function. I use the uc bindings. tf_hall_effect_v2_get_counter() has an input parameter for that purpose, but the counter callback configuration does not. I could not find out whether the callback resets the counter automatically by scanning through the uc bindings (I assume it does not though). I like to always reset the counter when the periodic callback was triggered to measure the RPM of a wheel. Any chance it can be done with the callback too? Cheers, Claudio

That's a very good point. I adapted my code so it can be safely executed on multi-core platforms as well. I will look into that for sure. At the moment though, to get the (say 10) highest peaks of the full spectrum, I have to collect all peaks anyway. Thanks a lot for the valuable input!

Thank you very much! Just one more question to understand the spectrum callback in the uc binding in more detail: To fill up the spectrum buffer using the tf_sound_pressure_level_register_spectrum_callback, one has to define a handler even if it can be an empty function? What if I don't have any user data that needs to be input into the callback handler? Should I define the handler in any case? Or is there another approach? Background: I tried to use NULL as handler, because I thought the buffer and handler are given to the callback separately and the spectrum data is being filled up (independent of my callback function handler ever touching the buffer). However, given no handler (NULL) doesn't work. // register spectrum callback to function spectrum_handler tf_sound_pressure_level_register_spectrum_callback(&bricklet_spl, NULL, // <- that does not work spectrum_buffer, &spl_data); By scanning your code (bricklet_sound_pressure_level.c, uc bindings) I see that there is a difference between line 1421 sound_pressure_level->spectrum_handler = handler; and line 1390 sound_pressure_level->spectrum_low_level_handler = handler; I understood that if the handler is not present (NULL), the low level stuff is not being done (that is streaming out the data). So it seems that I have to use an empty handler just to make sure the buffer is filled with the current spectrum data, right? // callback function for the sound pressure level spectrum callback void spectrum_handler(TF_SoundPressureLevel *device, uint16_t spectrum_length, uint16_t spectrum_chunk_offset, uint16_t spectrum_chunk_data[30], void *user_data) { // avoid unused parameter warning (void)device; // receive user data as SplData struct SplData *spl_data = (struct SplData *) user_data; // nothing to do here } // register spectrum callback to function spectrum_handler tf_sound_pressure_level_register_spectrum_callback(&bricklet_spl, spectrum_handler // <- that works, even if the function body is empty, spectrum_buffer, &spl_data); I am currently postprocessing the spectrum data (getting the ten highest peaks, converting to db(A), etc.) outside the handler function and it works as expected. I just want to make sure I understand your bindings properly so I don't do functions calls that are actually not required to get the same "result". Thanks a lot and cheers, Claudio