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

Ok thanks! Sorry, I thought the C/C++ and C/C++ bindings for microcontrollers would have the same methodology (just different function names) for the callbacks. I'm actually trying to set the sound pressure level spectrum callback on your ESP32 Ethernet Brick using your bindings. In the corresponding section on your website, it is documented that " []... is the period with which the Spectrum Low Level callback is triggered periodically". And the "Spectrum Low Level" links to the tf_sound_pressure_level_register_spectrum_low_level_callback. This is why I was wondering how the low level callback works. So I understand that the uc bindings are working differently. I use the tf_sound_pressure_level_get_spectrum() to get the frequency spectrum. Perfect! Cheers

Ciao a tutti, I'm preparing some test code for the Sound Pressure Level Bricklet, after I purchased it today. Would it be possible to get an example (C/C++) on how to use the tf_sound_pressure_level_register_spectrum_low_level_callback? Your API documentation doesn't show how to use it and I can't find anything related to that (neither in your forum nor in your GitHub repos). Does the "spectrum_chunk_offset" indicate which part of the spectrum, that is which 30 (of the 512 at max) bins the callback has shipped? Say spectrum_chunk_offset is 0 (what I assume for the first chunk of data): do the 30 bins correspond to bins 1 to 29 (the first it reserved for the DC offset)? And, say spectrum_chunk_offset would be 1 (or 30?): does it mean the data corresponds to bins 30 to 59? It would also be great to see an example of the tf_sound_pressure_level_get_spectrum function in your documentation, although its usage is clear. One more question: your Brick Viewer screenshot of the spectrum (on the Bricklet website) shows the decibel value above the spectrum. The decibel value (69 dB in that case) is close to the highest peak of the spectrum. If I want to know both parameters, that is the current sound pressure level and the spectrum, is the current decibel value included in the spectrum as its maximal value? Can I use both callbacks at the same time (tf_sound_pressure_level_register_decibel_callback and tf_sound_pressure_level_register_spectrum_low_level_callback)? Cheers, Claudio

The erroneous graphs are gone now. Great! What I do it (macOS 12.2) now is dark vertical lines in the plot whenever I switch to another tab in the Brick Viewer. I used two Accelerometers here for example and switched from the one to the other Bricklet many times. Each time the tab changed, the graphs plotted new vertical lines at the correlated time point. Or is that a feature that I don't understand? Cheers!

There are two small things which might be worth improving in the next version, I guess: The dark mode uses bright font colours in the plot area, but the plot background does not adapt to the dark mode settings (it should be dark too). Hence, you cannot read the labels and measurements anymore, especially for magnetic field, Euler angles, etc. (see the arrow in the screenshot) One small problem with macOS: I cannot change the window dimensions while the plot is being filled with data. For the period of dragging the window to the new size, the plot stays unreadable, also after the dragging was done (see the rectangle in the screenshot) I can empty the plot, of course, and the data is ok again.

I'm happy to confirm that Brick Viewer 2.4.21 displays the 3D view on macOS (12.1) now. Thank you!

I did. The resulting .dmg in brickv/src/dist/macos/ doesn't have the OpenGL problem. It works just fine and renders the 3D view. So at least in my local case, packaging seemed to work all right.

Sorry, you are right, tzlocal was not the problem indeed. I changed the PyQt5 dependency in requirements.txt to PyQt5 and that fixed it. I can now see the 3D view for the IMU v3 Bricklet. Yes that was exactly what it said.

Unfortunately, I can't run Brick Viewer from source, as installing the requirements (pip3 install -r src/requirements.txt) fails. It has a problem with tzlocal I'm using a Homebrew Python3 version and it seems that the dependencies cannot be made compatible. I'll try fixing it and get back to you asap.

After running import ctypes.util print(ctypes.util.find_library('OpenGL')) I get It seems that it does find the library though.

The current macOS Brick Viewer version (2.4.20) can't find the OpenGL library to display the 3D view of the IMU 3.0 Bricklet. I'm on macOS 12.0.1. What OpenGl library are you looking for? PyOpenGL or something else? In the source I could only find QT packages which I'm sure I have installed. Cheers Claudio