Jump to content

cl-

Members
  • Gesamte Inhalte

    95
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

cl-'s Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • One Month Later
  • One Year In

Recent Badges

1

Reputation in der Community

  1. Wir haben das gleiche Problem gerade mit dem Accelerometer V2. @batti Welche Version verwendet ihr selber? Dann nutzen wir die auch einfach. Danke
  2. 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
  3. Ok. Problem wurde behoben durch ein sudo apt --fix-broken install Hmm, das hatte ich noch nie vorher.
  4. 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
  5. 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?
  6. 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
  7. 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?
  8. 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.
  9. 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
  10. 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!
  11. 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
  12. 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
  13. 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
  14. 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!
  15. 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.
×
×
  • Neu erstellen...