Is accelerometer digital data output rate always variable ? - Page 1
Forum section: electronics / beginners

author: metebalci
author_rank: Frequent Contributor
timestamp: October 17, 2023, 06:08:31 pm
content: I am trying a few accelerometers, for example one is ADXL335 which has analog output, other is LIS3DHH which has digital output (accessed through SPI, it has a FIFO etc.). Analog output is externally sampled so I have a natural time reference (I can have 50 samples/s etc.) but the digital one does not say in spec a fixed sampling rate, it gives a typical data output rate value of 1.1kHz. I plan to have long records, so how will I know the times of samples ? I keep another list mapping some sample points to seconds etc. I guess, and it will give at least approx. time reference for samples. Are all digital output accelerometers like this or are there ones with fixed data output rate ?

author: JustMeHere
author_rank: Frequent Contributor
timestamp: October 17, 2023, 06:43:14 pm
content: Looks like your answer is in Table 17

author: metebalci
author_rank: Frequent Contributor
timestamp: October 17, 2023, 06:49:02 pm
content: Quote from: JustMeHere on October 17, 2023, 06:43:14 pmTable 17 of LIS3DHH datasheet ? Can you explain ?

author: JustMeHere
author_rank: Frequent Contributor
timestamp: October 18, 2023, 12:31:51 am
content: That Table explains how to set the filter rate. I found the actual sample rate in the app note listed below. See section 3.https://www.st.com/resource/en/application_note/an5139-lis3dhh-threeaxis-digital-ouput-accelerometer-stmicroelectronics.pdf

author: JustMeHere
author_rank: Frequent Contributor
timestamp: October 18, 2023, 12:54:28 am
content: Anyway, go with the SPI bus one. You don't have to worry about EMI. It can take 32 samples while your MCU is doing other work.The SPI bus runs much faster. Read all samples. Throw out the highest and lowest (possible the next highest and lowest) then average the rest.

author: golden_labels
author_rank: Super Contributor
timestamp: October 18, 2023, 02:20:40 am
content: Discarding the highest and lowest may pose some trouble: higher dimensions have no natural ordering.One has to first define, what outliers would be, and the definition is always domain-dependent. Such calculations are often not trivial. So, unless this is directly fed to a control system, I would suggest recording it as-is and only clean up as needed later.If you need to deal with bad data in real time, you may determine the expected range of valid values and blindly discard everything outside it. Perhaps even ignore some datapoints after detecting unexpected data. This is cheap and easy to implement. If your data is logged, remember to also mark these events.

author: JustMeHere
author_rank: Frequent Contributor
timestamp: October 18, 2023, 03:06:35 am
content: With 32 samples losing the highest and lowest won't cost any useful resolution. But if there's a glitch, it will be one of those. It it's a good sample, it's close to the rest of the numbers and won't affect the math.I use this for a thermocouple with only 10 samples. The reading is consistent and I never see a glitch.These are numbers. Their natural order is they spread over only.a few units. This chip isn't for measuring helicopter blades.This is a digital interface. The expected range of value is the bitwidth defined in the digital protocol. So is the entire domain of error values. There are no out of range values like you may see in an analog interfsce.. As mentioned above, this approach actually works where they are out of range values.If your algorithm spends too much time thinking, it won't be ready for the next 32 samples if you

author: golden_labels
author_rank: Super Contributor
timestamp: October 18, 2023, 04:12:07 am
content: Please re-read, carefully, what I wrote above. In particular the first sentence. I assure you there is no natural order in ℝ3. I did not say anything about resolution either.You can either define it or, better yet, find another way of finding/avoiding outliers. But that is domain-specific and calculations are often expensive. As you have correctly noted, this is undesirable, because “if your algorithm spends too much time thinking, it won't be ready for the next 32 samples”.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 18, 2023, 08:23:56 am
content: Quote from: JustMeHere on October 18, 2023, 12:31:51 amThanks for the app note. Is the LP filter decimating ? If not, the filter is not directly relevant to my question.So the app note says: "the sensor provides acceleration data at an output data rate of 1100 Hz".The datasheet says only in a table: "ODR/Digital output data rate is typically 1.1 kHz, and Typical specifications are not guaranteed.".Either I misunderstand the word "typical" or the datasheet is not clear, but the app note says it is 1100 Hz, so it is not actually variable so my question is wrong.I am not doing a real-time process, just trying to record the samples and already did that but I was not sure about the data rate hence my question. I will work on the samples offline.

author: JustMeHere
author_rank: Frequent Contributor
timestamp: October 18, 2023, 06:13:51 pm
content: Typical is probably the rate in continuous mode. There are charts that show this can change in the other modes. It looks like there is a variance during startup.The chip being busy could cause delays.Typical also is a synonym for "not gatenteed" So if the thing actually runs at 1101Hz then they aren't going to let you return it.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 19, 2023, 07:11:12 am
content: Quote from: JustMeHere on October 18, 2023, 06:13:51 pmI thought this is mostly about variation in a single device but it seems to me now that it is mostly about inter device variation. There is also a post at ST forums about this confirming there is an inter device ODR variation (not for this but about another device).I did a 9h recording (recording 9h*1100Hz samples), and it seems like it is running a bit faster (maybe 1101Hz like you said), the recording is finished more than 10 seconds earlier. I cannot be more accurate because I did not log enough things but I guess it is enough to see it is not running at 1100Hz.Meanwhile, I realized some (or many) other devices have configurable ODR and does not actually specify ODR like this. So now I have a feeling this is a wrong device for what I am trying to do, I will check other devices.

author: Berni
author_rank: Super Contributor
timestamp: October 19, 2023, 07:30:38 am
content: The chip has an internal oscillator that it runs from. This determines how fast everything in the chip happens and since these are on chip RC oscillators they are not terribly precise. So if the internal circuitry of the accelerometer is running a bit fast then it also spits out samples a bit fast.If you have a strict acquirement for the sample rate to be precise, then the way to do it is resampling in software on the MCU.These MEMS sensors usually have a sigma delta ADC inside, so you can just simply lower the oversampling ratio to get a higher samplerate out of it then downsample that in software to get full resolution again. If you select a sampling rate that is 10x to 100x higher than you actually need, then you can simply collect samples between your precise sampling periods and then calculate the average of those to get your sample. As the accelerometers internal data rate fluctuates you will something get 1 or 2 samples more or fewer in the average, but it won't impact the result.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 19, 2023, 09:58:23 am
content: These cheap IMUs run out of some internal, inaccurate oscillator and do not offer any way to sync conversion to external clock. It says "typical", and if it does not specify the tolerance, you can guess that it's not probably much worse than maybe +/- 1% or so.If youneedsynchronization to external clock, best you can do, and this is what I have done, is to configure the sensor to output much higher sample rate than your desired output rate, and average samples accumulated during your (slower, asynchronous) sampling period. The number of samples to be averaged would then vary between output periods (usually just by 1, so for example sometimes you get 10 and sometimes 11 samples).More expensive/specialized IMUs come either with more accurate clock source, or ability for external clocking. But in absence of clock input, the fundamentals of asynchronous communication remain even if both parties had +/-1ppm accuracy: you would still need to map from different sample timing to your required output timing, which is a whole lot easier when you can significantly oversample, because any jitter error coming from the fact that you sometimes sample 10 sometimes 11 values together (and they sometimes align close to leading edge to your output sample window, sometimes closer to trailing edge) is way less than what you get when you need to either duplicate or completely skip a sample when the sample rates are close together; and more complex realtime interpolation systems, while possible, are not trivial.(And as golden_labels points out, you can't do median filtering, or I would add, any kind of 3D interpolation either, by just treating the vector components separately like it was 1D data. Pretty much whenever you try to do any geometric math with IMUs you end up working with either quaternions or discrete cosine matrices and want to convert to those as early as possible. For truly minimized error, you should be doing thisbeforeaveraging even the 10 samples, but of course given that your output sample rate is high enough, too, then it does not matter even if you used simple component-wise avarage.)

author: metebalci
author_rank: Frequent Contributor
timestamp: October 19, 2023, 04:33:20 pm
content: Thanks everyone for detailed explanations. I understand what you say about the clock accuracy or inaccuracy used for sampling the MEMS analog output.I think, because there are both analog and digital sensors, I was expecting digital to have a more accurate clock but I did not pay attention to the use cases since I dont know much about the applications. I believe the digital output has more use in immediate or short period of records (hence the modes of the sensors, now it makes more sense) and then the clock accuracy is not that much important. If I want to sense the orientation of a device etc.For long records, I guess at least for some cases of predictive maintenance or vibration measurement, analog outputs might be more useful, because there are probably more sensors and it is much easier to sample them externally with a common clock and it is much easier to know the accuracy of the sampling clock. I initially planned to have only one 3-axis accelerometer (hence only one sensor) but actually I might need another one. So I am not 100% sure which is better for me yet but I continue my research and keep an eye on analog ones as well.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 21, 2023, 05:21:57 am
content: I started evaluating IIS3DWB which is marketed as a vibration sensor mainly due to wide bandwidth I think but it also has specifications related to ODR in the datasheet (ODR accuracy 1% typical, 2% max), timestamping and a bit more information regarding to this topic in general.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 21, 2023, 03:54:38 pm
content: Preferably, you would sync yourprocessingto the rate generated by sensor, not the other way around. The reason I once did not do that was, I used combination of six sensors which would obviously not be in sync, which is why I had to go for the oversampling/averaging approach so that I can get the output of all six sensors "as if" they were sampled at the same time, as closely as possible.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 21, 2023, 06:59:49 pm
content: Quote from: Siwastaja on October 21, 2023, 03:54:38 pmMultiple sensors are quite a problem I think, I did not think about it much yet but it sounds pretty complicated to be done properly.This latest sensor I am trying, IIS3DWB, is interesting with timestamping. It increases the data throughput requirement 2x (and ODR is 26.6kHz) but it becomes immune to FIFO overruns. I think timestamp counter runs 3x faster than actual sampling rate of the sensor. It also provides a register called internal fine frequency register which contains a correction (0.15% resolution of nominal ODR I think) to calculate an actual rate of ODR, I guess it is programmed at the factory.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 22, 2023, 11:24:35 am
content: Unless you are power-constrained (i.e., sleeping CPU and batch processing from FIFO), it's still probably easiest to just use highest possible sample rate and read out data as soon as possible (interrupt lines, or very frequent polling). If you try to read out more often than the sample rate, overrun is impossible and FIFO mode doesn't need to be even used. Even if you get tiny amount of timing jitter, that would then be small enough that all other sources of errors of these cheap sensors (offset, gain, aging and temperature drifts thereof, backlash/hysteresis i.e. offset being different depending on the direction you are coming from) clearly dominate. The timing thing is just something people have discussed and manufacturers have responded to it because it's so easy to do so, it's a simple digital logic addition to the chip.Think about it - if you enable say 200Hz internal LPF and then sample at 2000Hz, what difference does it if you have say 5% of timing jitter on that 2000Hz data?The only time I have utilized the FIFO was in a battery-powered wireless wheel sensor because sleeping the CPU and letting the IMU to collect enough samples to run a batch EKF then send a radio packet was significant energy conservation.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 24, 2023, 06:35:44 am
content: Quote from: Siwastaja on October 22, 2023, 11:24:35 amNot power constrained, not running on batteries, but I am using an RPi 4 with the standard distribution and running a user-level process. I didnt try not using FIFO, maybe it is possible, but the problem is even the whole 4GB memory of RPi is enough only for 6h and using standard file I/O may cause overruns even with FIFO. So I am using two threads, producer reading the sensor directly to a circular buffer and consumer reading from the buffer and writing the sensor data to a file. It seems to be working without overruns independent of the recording duration.Let me say I started evaluating this because I would like to monitor the vibrations from 2 (maximum 3) sensors as wide bandwidth as possible. I do not know exactly what I am looking for so I would like to collect the data and analyze later. Probably collecting some data is enough but I thought why not to collect a full session which might be a few hours. This brought me to various limits and then I wondered how to overcome these. So at the moment I wonder if it is possible to record 24/7 accelerometer data from a sensor with 26667Hz ODR until the storage is full (which may never happen, the files can be rotated, old can be taken out etc.). Another option to investigate later might be to stream it over the network. Again this is to be run as a user process (no rt kernel, no interrupt lines, not at kernel level), so it should handle various hiccups gracefully.Maybe it is a better idea to use a microcontroller and stream it over ethernet and use RPi only as the network receiver endpoint.

author: Berni
author_rank: Super Contributor
timestamp: October 24, 2023, 07:10:16 am
content: Ah RaspberryPiYeah that sort of realtime processing is not for use on a regular linux box. But if you are saving it for later analysis you don't really care about realtime processing. Just use the accelerometers internal FIFO to pump raw samples over into memory as fast as possible, then every so often insert a real time clock timestamp. This lets you check the exact sample rate of the accelerometer later on during processing and if you really must have a fixed sample rate, write a python script to resample the data to whatever you want. Since it is running offline on data on disk it can be as slow as it wants to be.As for the datarate, it is not that bad. For recording CD quality audio (44.1KHz 2ch 16bit) you only need 176 KB/s. Pretty much any shitty SD card you have laying around will be able to maintain a write speed higher than this over a long period. If you buy fancy cards they can grantee a 10MB/s or even 90MB/s sustained write speed. So those cards would be capable of recording raw audio from 500 CDs in parallel.Tho the thing is that the write speed of a SD card is not consistent since the cards controller sometimes needs time to rearrange flash blocks. So a card rated for 10MB/s might actually write at 40MB/s but here and there for a few moments drop down to 0.1MB/s then back to 20MB/s..etc But a raspberry Pi has tons of RAM, so there is no problem buffering a a few seconds worth of data for when the SD card hickips and then catches up.So a Pi could record to SD from >100 such accelerometers in parallel if you optimize your software enough.

author: golden_labels
author_rank: Super Contributor
timestamp: October 24, 2023, 10:23:30 am
content: If that’s an RPi without any additional HATs,(1)I wouldn’t be worried about inaccuracies from the accelerometer itself.Don’t let this discourage you from pursuing this project, whatever it is! See the second part of the answer for the why. My goal is opposite: to make you not care about this issue for now.The problem with RPRPi offers no accurate, low-drift timing source. With a recording lasting hours your datapoints may turn out to be off by seconds or worse.(2)That will completely eclipse inaccuracies from the accelerometer, which you are worried about. If long-term error is not relevant to you, the other end of the scale is no better. I do not remember, what precision RPi’s timer offers. But I remember it wasn’t too high and a quick search people do not get below 500 µs. And you want to pick datapoints with less than 1000 µs between them. The timestamps will be of garbage quality.Why continue?Because this single imperfection does not invalidate the entire endevour. You may still get useful data. Either because the timing issue will not affect the relevant information at all, or because you can take it into account while drawing conclusions. It would be a disaster, if you were unaware of the problem. But now you know. Just interpret your data with having this in mind and, if you consider data to still be valid and want to publish your conclusions, just be honest and clear about the setup and its shortcomings.The worst thing, that can happen, is data being useless and you gaining experience. And some issues are not that hard to overcome by other means. For example: if it’s about providing a common reference point for multiple accelerometers, just tap the subject to provide a common, easily recognizable signal to all — amethod successfully used in film.(1)aka shields; you didn’t mention using any.(2)I want to underline, that “seconds” is a very conservative estimate.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 24, 2023, 01:09:09 pm
content: Quote from: Berni on October 24, 2023, 07:10:16 amI do something similar but using the timestamp of the sensor, and use python and matlab for offline work.Quote from: Berni on October 24, 2023, 07:10:16 amActually the data rate is very low comparing to many other things (~26 KSps, 7 bytes/sample, lets say interleaved with timestamp so 2x more, ~370KB/s). As you said even RPi+SD has a raw speed much higher than this. However, I think, there are two issues, one is obviously I am running a user process, I have almost no control how it is scheduled etc. I only pin the threads to different cores (RPi has 4) and the main process to another to help with this. I think it is possible to set affinity of linux kernel scheduler but I did not try it yet.Other is it is not that straight-forward how to avoid memory copy as much as possible and do sequential I/O. At the moment I am using a circular buffer but each element is not a byte but another fixed length byte buffer, like a 2D buffer basically. For every SPI transaction to read FIFO, I use one row (as spi_ioc_transfer structure rxbuf) and this eliminates any need for copying memory etc. I tried different alternatives and this is the most effective I found until now. The writes to SD card are usually very small (and probably this is not optimal), but the file I/O does not seem to be a bottleneck at the moment.Quote from: golden_labels on October 24, 2023, 10:23:30 amNo I am not using any HATs, just using the embedded SPI on RPi. As long as I am not using an analog sensor and have the control of ADC (which I also tried but I dont have a wide bandwidth analog sensor at the moment so I moved to a digital one), I am actually not too much worried about the timing accuracy on RPi. The sensor is already digital, and I am reading the samples, so it is basically sensor's timing accuracy. The issue is that if a FIFO overrun happens, there is no way to know how many samples have been lost. So at that point, you are right I have to go back to get a timestamp from RPi. Then I realized this sensor I am currently using (ST's IIS3DWB) can also emit timestamp values to FIFO (timestamp resolution is ~12.5us, it runs at 80kHz). There are alternatives but at the moment I am using no decimation or 1x decimation, so basically before an accelerometer data (ODR=26667Hz) is saved to FIFO, it first saves the timestamp then the accelerometer data. This naturally doubles the data rate but the issue I said about buffer overrun disappears. You can lost samples when overrun happens but you do not lose the timing so the new data is totally usable. This is how I am using the sensor at the moment.Quote from: golden_labels on October 24, 2023, 10:23:30 amI was thinking to do the same and align the data offline. However, I am not sure about the accuracy that can be achieved, whether I need multiple such sync signals etc.I finally fixed a bug in my code and tried it to record for an hour. During this time, 2 buffer overruns happened, and it recorded ~96M xyz accelerometer data, ~700MB, 2x more if you count timestamps as well. I dont see any errors or unexpected values so I assume it is working.

author: Berni
author_rank: Super Contributor
timestamp: October 24, 2023, 02:32:34 pm
content: While Linux might not be the pinnacle of timing precision you can still have things happen reasonably regularly on a milisecond scale. If nothing else you can just keep a thread busy running around a infinite while loop checking the sensor for more data, pumping data out as fast as it can. Let linux mess with the other 3 cores for background stuff. As long as your accelerometer has some sort of built in FIFO that can hold at least a few dozen samples it will never overrun. Also if the designers of the chip had half a brain, it would have an overrun error flag somewhere in a status register.Don't worry about copying memory around You got DDR4 memory on a 32bit bus at 3200 MT/s. it can easily move the contents of an entire DVD in less than as second. For small things like that it might stay in CPU cache where you can move an entire BluRay Disc in under a second.Just use an actual real compiled programing language.And yes if you are after timing precision, you will need a RTC chip because the Pi does not have one.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 24, 2023, 07:20:17 pm
content: Quote from: Berni on October 24, 2023, 02:32:34 pmI roughly agree but this is an average or majority behavior. Running a long process, there definitely a few times it takes much more than average to execute a single run (of the infinite loop), these are the times overruns happen. That is why there is a need for real-time kernel in certain applications but I am not even at kernel level. So my experience is just the FIFO is not enough for this case. Again ODR is 26667, FIFO can hold 512 samples (without timestamps) and this leaves 20ms to complete a full cycle, which is not always possible (in 1h for example). I should restrict the linux scheduler to the other cores, I am sure that will help. (just tried this, isolcpus is supported but not for core 0, so 2-3 works as expected)Quote from: Berni on October 24, 2023, 02:32:34 pmIt of course has an overrun flag, that is how I understand there is an overrun. However, having just a flag does not say anything about the extent of the overrun, did it overwrite just one sample or hundred.Quote from: Berni on October 24, 2023, 02:32:34 pmNaturally I am not worried about the memory bandwidth, but any memory copy is extra work.Quote from: Berni on October 24, 2023, 02:32:34 pmI use C for data collection.

author: Berni
author_rank: Super Contributor
timestamp: October 24, 2023, 07:47:19 pm
content: 20ms is tons of time for the linux task scheduler to do its thing. Just try pumping data out and leave it running for a few days to test.The FIFO overrun flag is not meant to be a mechanism for recovering from an overrun, it is just a signal to tell you something went wrong. Under normal operation you should never see that flag come up, hence you would not need to mitigate it.But if you do want to read your sensor with precision down to the microsecond then you might want a Raspberry Pico. It can easily be connected to another computer for data storage over USB, or you could even connect a SD card straight to it. It even has two cores, so you could offload your critical sensor reading to a dedicated core.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 24, 2023, 08:35:31 pm
content: Quote from: Berni on October 24, 2023, 07:47:19 pm20ms is a lot of time but Linux is also doing a lot of things and the code is not only reading the data from the sensor. I mentioned at the moment I am not only keeping it in the memory, there has to be a way to persist this, display something/progress etc., this is not a code running just some seconds. I might test a pure code but it does not show anything as it is not going to be a final code. Actually at the moment I am not too much concerned about overruns. Having a few overruns in an hour is nothing because I can still correctly recover the upcoming data so I do not need to restart the data collection. Missing some samples in such a long record will probably be not important.Quote from: Berni on October 24, 2023, 07:47:19 pmI definitely do not have any experience with the applications but at least IIS3DWB app note says: "If the overrun condition occurs, the correct procedure to retrieve the data from FIFO is to discard each data read before a new timestamp sensor." So I dont think it is always the case that when overrun is seen, you do not mitigate it. When there is only a flag (and nothing else like timestamps), then there might not be a way to mitigate it in some applications, that I agree.Quote from: Berni on October 24, 2023, 07:47:19 pmA microcontroller is surely an alternative. I think I would first investigate using an STM32 H5 or so and stream the data over the network. The sensor is not going to be near a computer so a network is required either to transfer the data after it is collected or to stream it.

author: metebalci
author_rank: Frequent Contributor
timestamp: October 25, 2023, 04:56:45 am
content: It seems, and I believe, preventing Linux scheduler to use the cores have a major impact. I did that (isolcpus=2,3 on cmdline and set each thread affinity to core #2 and #3) and made a 8h recording, that is ~1.5B samples, ~11GB data and had zero buffer overruns, furthermore the maximum size of FIFO used was only 22 elements, vast majority of FIFO reads were only 1 or 2 items. I guess this concludes that 24/7 recording is possible like this.

author: Berni
author_rank: Super Contributor
timestamp: October 25, 2023, 05:34:20 am
content: Yep see that Linux is not as horrible with timing as you might think. Even if you just hog one thread 100% without any special settings that will make the scheduler realize this is a thread that needs to be given as much CPU as possible so it tries to leave it alone, but is indeed a good idea to give it some more hints like you did. There are hobby CNC machines out there that are being run using Linux bitbanging LPT port bits to generate step pulses.For the occasional hiccup you did get, that might be a system call (like filesystem) taking a bit longer to service because something else was going on. But that can be optimized out even more by directly taking control over the SPI peripheral over a memory map and having an intermediate FIFO between one thread that is servicing the sensor and one thread that is interacting with the OS to save/send data out. But as you seen there is no need to go that far.For FIFO overrun mitigation, the only thing you can reasonably do is realize you have incorrect data in the FIFO and start over, there is no way to fix it. In your case you could replace the timestamp section that overran the FIFO with all FFs to indicate something went wrong and make sure you don't use the data later on.If you got it working on a RaspberryPi you probably want to stick with it because networking is so much easier under Linux. Yes there are a lot of MCUs with Ethernet, but you have to put an entire TCP/IP stack into your code to use it on a normal network.(Unless you plan to have a point to point link to a network card on a PC that is receiving raw MAC packets)

author: metebalci
author_rank: Frequent Contributor
timestamp: October 25, 2023, 06:03:34 am
content: Quote from: Berni on October 25, 2023, 05:34:20 amI am not against what you are saying (using Linux for 25+ years), my point is that the code I am running is not as straight-forward as you suggest, and a straight-forward implementation might have problems.Quote from: Berni on October 25, 2023, 05:34:20 amI am already doing this. I have two threads, one is only doing SPI transactions and storing the data to a circular 2D buffer, other thread is saving the data to SD card. Basic producer-consumer implementation, just the buffer is a bit different.Quote from: Berni on October 25, 2023, 05:34:20 amI simply omit this section when I convert the FIFO data to xyz, because I also create a t data, t will not contain these points. I analyze the data later on MATLAB, so it is useful to have t anyway.Quote from: Berni on October 25, 2023, 05:34:20 amDefinitely I agree. I also plan to do something totally different on STM32 H5 which might use the network, so it might be a stepping stone.