Jump to content

cl-

Members
  • Gesamte Inhalte

    95
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von cl-

  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.
  16. I'm happy to confirm that Brick Viewer 2.4.21 displays the 3D view on macOS (12.1) now. Thank you!
  17. 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.
  18. 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.
  19. 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.
  20. After running import ctypes.util print(ctypes.util.find_library('OpenGL')) I get It seems that it does find the library though.
  21. 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
  22. Bei mir unter Big Sur auf MacBook Pro (Mid 2015) läuft alles problemlos
  23. Sorry! Das ist nicht so leicht zu verstehen. Vielleicht brauche ich noch einen Kaffee! Wenn das Accelerometer Bricklet einen kontinuierlichen 8bit Callback für eine Achse eingestellt hat, dann bekomme ich nach dieser Rechnung 1000 Pakete mit jeweils 60 Werten pro Sekunde. Das macht dann 60.000 Samples pro Sekunde, obwohl der Accelerometer nur 25600 pro Sekunde konvertiert. Heißt das in diesem Fall, dass keine 1000 Pakete pro Sekunde, sondern eben nur 427 gesendet werden, um die 25600 Samples auszuliefern? Das meine ich so, dass wenn man alle Signale zeitlich miteinander korrelieren will, haben alle Samples mit dem gleichen Index in den jeweiligen Arrays/Vektoren im besten Fall den gleichen Zeitstempel. Da das beim nacheinander Pollen nicht möglich ist, ist signal[1].time[0] immer die (beispielsweise) 300 µs älter als signal[0].time[0], signal[2].time[0] immer die 300 µs später als signal[1].time[0], etc. Ich greife ja nacheinander, um eben die 300 µs verschoben, auf den gleichen Index zu, wenn ich einzelne Werte der Reihe nach speichere. Das ist soweit auch nicht schlimm, als ich den Zeitversatz ja dann kenne und beim Vergleichen der Samples entsprechend des resultierenden Zeitversatzes (Indizes werden verändert) kompensiere. Somit vergleiche ich immer Daten mit möglichst identischen Zeitstempeln miteinander. Oder habe ich hier was nicht verstanden?
  24. Ah ok. Ich verstehe! Ich habe noch ein paar Fragen dazu. Hat ein Bricklet nicht immer Daten zu versenden? Kann dieser Zustand nicht nur am Anfang passieren, wenn das Bricklet gerade erst konfiguriert wurde? Wenn ich in deinem Beispiel nun nach ca. 900 µs wieder bei Bricklet X angelangt bin und es befrage, bekomme ich dann die zeitlich jüngsten Daten des Bricklets oder noch die alten Daten von vor ca. 900 µs, die ich fast hätte kriegen können? Oder in anderen Worten: Aktualisieren die Bricklets ihre Daten für den Ausgang, auch wenn sie nicht angefragt werden? Die Frage geht in die gleiche Richtung wie oben. Es ist klar, dass die entsprechende Bricklet Konfiguration gewährleisten muss, dass die Samplingrate/Datarate des Sensors hoch genug ist, um auch wirklich aktuelle Daten zu generieren. Sagen wir, während der Zeit von 900 µs hat der Sensor des Bricklets (KX122 in meinem Fall) mehrmals neue Messwerte generiert. Ja genau! Mir geht es primär um den Takt, die immer gleiche, zeitliche Abfolge von Samples. Wenn ich gewährleisten kann, dass es beispielsweise immer um die 300 us sind, die zwischen zwei aufeinanderfolgenden Pakten liegen, dann kann ich das programmatisch kompensieren. Besten Dank!
  25. Ich habe jetzt auch mal das aktuelle Raspberry Pi OS genommen, wieder den aktuellen Kernel 5.4.51+ geladen, die core_freq auf 250 gestellt und vier Accelerometer V2 Bricklets angeschlossen. Ich nutze das hal_raspberry_pi (Beta 6) und diesmal habe in dieser Konfiguration keinerlei Fehler mehr bei der Kommunikation. Das ist absolut top! Scheinbar war irgendetwas nicht richtig an meiner vorherigen Konfiguration und/oder Software Zusammenstellung. Ich komme bei 1,40 MHz SPI Speed jetzt auf ca. 2020 bis 2030 PPS (mit vier Accelerometer V2 Bricklets). Channel 0: Packet counter is 2535 after 5.000476 seconds. Channel 1: Packet counter is 2535 after 5.000476 seconds. Channel 2: Packet counter is 2535 after 5.000476 seconds. Channel 3: Packet counter is 2536 after 5.000476 seconds. Combined: 2028.006958 packets per second Mit 1,95 MHz SPI Speed kriege ich jetzt ca. 2750 bis 2770 PPS (mit vier Accelerometer V2 Bricklets). Channel 0: Packet counter is 3461 after 5.000326 seconds. Channel 1: Packet counter is 3458 after 5.000326 seconds. Channel 2: Packet counter is 3461 after 5.000326 seconds. Channel 3: Packet counter is 3452 after 5.000326 seconds. Combined: 2766.219482 packets per second Die 1,40 MHz SPI Speed laufen aber runder, weil ich für alle Kanäle die (fast) identische Anzahl von Paketen bekomme, während ich bei den 1,95 MHz starke Abweichungen erkennen kann. Die Error Counts der Accelerometer V2 Bricklets geben keine Auskunft über einen möglichen Grund. Für beide SPI Speeds bekomme ich folgende Werte: Channel 0: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 1: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 2: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 3: Ack Checksum: 0, Message checksum: 1, Count frame: 0, Count overflow: 0 Ich gucke in den nächsten Tagen mal, warum die Abweichungen bei 1,95 MHz zu erkennen sind. Oder liegt es einfach an der Tatsache, dass die Performance des BCM2835 chips für mehr nicht ausreicht?
×
×
  • Neu erstellen...