Community news, upcoming events and general discussions
Threads: 36 Posts: 88
Get technical support from the community
Threads: 1409 Posts: 7545
Threads: 18 Posts: 64
Tell us how to make XDK better!
Threads: 36 Posts: 119
Share and discuss community member projects
Threads: 78 Posts: 343
I am using the datalogger example ("DDL_DemoDataLogger") to measure acceleration values. Currently I try the internal BMA280 sensor but my aim is to attach an external sensor which measures acceleration with a higher bandwith. At the moment I simply log the measured data. But eventually I plan to do some preprocessing and only save the processed data.
As far as I found the current sensor driver has some limitations on the maximal sampling rate.
Could someone please specify what is the maximal sampling rate at which data can be read from the BMA280 sensor?
What are the limitating factors?
Please could you also state what is the maximal jitter of the sampling rate.
thank you very much
welcome to the XDK community.
The maximal sampling rate is only limited by the bus that is used to receive all data from the sensors of the XDK by the MCU. This bus allows a maximal sampling rate of 1 kHz. This sampling rate also devided by the amount of used sensors. Therefore you are only able to use the full 1 kHz sampling rate if you use one sensor at a time.
The accuracy of the sampling rate varies by 1-2%. In case of the datalogger demo there are more factors to be aware of, for more information I recommend this thread here.
Please don't hesitate to ask if you have further questions.
thanks for your answer.
I have digged a bit in the source code up to the I2C driver.
Lets do a short calculation. The sensor is connected via I2C. Reading a 3 dimensional acceleration value requires 9 bits to address the sensor, 9 bits to set the read operation, 3x16bits to read the acceleration. This sums up to 66Bits.
Assuming an otherwise unused I2C interface, it is only the serial clock that limits the bandwith of the inteface.
Running at 100kHz / 66Bits = 1.51 kSample/s
Running at 400kHz / 66Bits = 6.06 kSample/s
Running at 1MHz / 66Bits = 15.15 kSample/s
Thus the I2C bus is capable to transport more than 1kSamples/s even when running at slowest speed. In praxis the bus operates at a higher frequency. On the external I2C interface I manage to get a frequency of 1MHz. I was not able yet to measure the frequency on the internal bus as there is no schematic nor layout provided that shows which testpoint to use. But I expect it will run at up to 1MHz as well.
However I confirm what you write. The XDK is only able to measure with a maximum of 1kSamples/s. To be more precise I did not even get that high, but this might be due to some other issues I have not figured out yet.
In my opinion it is not the bus that limits the sampling rate but the provided SDK software which uses an inefficient design. Please excuse and correct me if I am wrong. The code is written in a peculiar way that makes it extremly hard to understand at first glance.
The I2C driver seems to be implemented at least to some degree blocking. Thus the actual I2C signal is not using the full available bandwith. Instead there are gaps that occur when the source code is too slow to feed the I2C hardware. I could verify this with my scope.
Imho this is no appropriate design for a data acquisition system. To achieve a decent I2C performance the DMA should be used.
The actual sample timer is derived from a software timer. This has as consequence that every read sample requires a task switch. Thus the more samples are read the higher gets the CPU load, which also limits the maximal sampling rate.
But it has even worst consequences for the jitter. You state the jitter to be 1-2%. This is far too high to do scientifically correct signal processing. But in my opinion what you state is not even worst case but only an average value. The maximal jitter might be much higher It depends on the number of tasks, the tasks priorities, the OS etc. To achieve a precise timing it is crucial to use a hardware timer as time base.
Maybe I am too negative, but I get the impression the XDK is only useful for measuring low speed things like temperature. For measuring movements or acceleration it seems not to be appropriate. Or said in other words to do high speed measurements the software needs some significant redesign.
Hello Stefan, thank you very much for sharing your detailed experience as well as your point of view. The XDK framework certainly has some limits the development team tries to improve.
High speed measuring is a good improvement point. We are aware of the big potential of the XDK and I will add this issue to our improvement list and discuss it with the team.
Nevertheless, we hope you enjoy the XDK experience and stay tuned for upcoming features.
Kind regards, Franjo
could you tell us more details about your time schedule. When will you implement which new feature, when will you fix the limitations? How many persons are actively developping for XDK?
I have evaluated the XDK for quite some time now as I thought it might be a suitable plattform for doing serious measurement application. But my impression is that at the moment the XDK is far from useable and if I see the microphone topic it doesn't seem that there is much progress.
To sum up this is the list of issues that I find with the XDK currently:
- too high jitter when using sampling rate above 100 Hz - using several sensors in parallel is only possible for low speed measurement due to inefficient use of I2C bus - microphone is not useable yet - internal temperature sensor not useable if WLAN is active due to self heating - acceleration sensor not useable due to limited samling rate - battery operation last only for few days when doing serious measurement tasks - lack of schematic and layout makes adding custom electronics difficult - bad code quality of Bosch software part (Silicon Labs and freeRTOS code seems much better to me) makes own software modifications really tedious. I have spend many days just to clean up code to understand what it actually does.
Still I don't want to bash the XDK. I think its hardware is really nicely designed. But I would love to use it now. Thus it would be important to see that there are happening serious development efforts and the named issues get resolved quickly. best regards Stefan
thanks again for your detailed feedback, I really appreciate it. From looking you up online I understand that you are very serious about professional XDK development and usage, and understand your frustration. However, I am sadly not in a position to directly comment on internal bosch processes, but I am requesting a statement on your findings from someone who is.
I will post the statement in this thread once I receive it.
Until then I have to ask for your patience.
Kind Regards, Franjo
Sorry it took a few days to get back to you. I've tried to compile some remarks on your technical points below.
Firstly: You've correctly pointed out some weaknesses of the device. Even though we're constantly working on the SW with our team, many of the improvements and fixes being done are not so visible to most users since they affect architectural aspects. This is of great importance to us, since the XDK is not only a prototyping device (which could do with a much simpler structure), but offers a path to volume products and therefore faces some limitations from these aspects. However, we're planning major improvements on the usability of the SW interface and also in the drivers for 2017.
Now some comments on your statements from before:
"Lets do a short calculation. The sensor is connected via I2C. Reading a 3 dimensional acceleration value requires 9 bits to address the sensor, 9 bits to set the read operation, 3x16bits to read the acceleration. This sums up to 66Bits."
In the I2C protocol the transmitter sends 8 bits of data to the receiver and the receiver acknowledges the 8 bits data with a 9th bit ACK/NACK and there must be a stop bit at the end of the (multi-data-byte) transaction as well. As stated in the BMA280 datasheet, pages 103-104 „I2C multiple read”, to read 3x 16 bits axes data the host controller would need 19+10+6*9+1 I2C clock periods, which sums up to 84 bits, in ideal conditions. But of course it is not reasonable to think that the MCU can achieve 0 wait-time multi-byte transfers on the I2C bus so there will be additional inter-byte spaces. The BMA280 in particular has a fixed output data rate (ODR) of 2 kHz (typical as the sensor has its own clock inaccuracies) and if he reads filtered data the ODR is halved or scaled even further down
"Assuming an otherwise unused I2C interface, it is only the serial clock that limits the bandwith of the inteface.
For the following calculations we made the optimistic assumption that the inter byte space between I2C byte transfers will be 1 I2C clock period only and that after the stop bit there is one additional 1 bit delay till the next start bit can appear on the bus
- At 100 kHz / (84+10) bits = 1.0638297872340425531914893617021 kSample/s ± tolerances due to unquantified HFXO clock tolerances over the entire temperature range
- At 400 kHz / (84+10) bits = 4.2553191489361702127659574468085 kSample/s ± tolerances due to unquantified HFXO clock tolerances over the entire temperature range
- At 1000 kHz / (84+10) bits = 10.638297872340425531914893617021 kSample/s ± tolerances due to unquantified HFXO clock tolerances over the entire temperature range
As per the BMA280 datasheet the maximum allowed I2C bus frequency is 400 kHz, not 1 MHz. This is also true for the internal I2C, since it's a limit coming from the sensor. Thus, the XDK HW supports the maximum sampling rate of the BMA280 sensor – assuming that the other sensors sampled at the same time do not limit the I2C bus bandwith below 2kSample/s.
However, you are right in the respect that the design of the drivers might not be ideal to achieve maximum throughput. Again, here some some compromises had to be considered regarding our platform.
"To sum up this is the list of issues that I find with the XDK currently:
- too high jitter when using sampling rate above 100 Hz
The sensors perform sampling on their own. The MCU software is not triggering the sampling itself, the sofware simply reads out the available sensor data from the buffers. As long as sensors are continuously sampling their ODR will be fixed (minor tolerances due to sensor’s own clock source may apply) and as long as the MCU software can read with higher rate than the ODR of the sensors, the reading should work.
- using several sensors in parallel is only possible for low speed measurement due to inefficient use of I2C bus
Due to the prototyping character of the XDK, the parallel usage of all sensors leads to some limitations. For a Product designed for a specific use case, there are ways to fix this, but it would cost flexibility for the XDK as it is now.
- microphone is not useable yet
We sincerely apologize that the microphone is not supported by the workbench in the API. I don't want to bore you with the background story here, unfortunately, some other features were on top of it in our backlog. We expect a solution here in the beginning of 2017.
- internal temperature sensor not useable if WLAN is active due to self heating
That is a general topic of devices with integrated temperature sensors. I've tried to give an insight in previous posts. For all sensor, the application conditions must be considered, and to some extent compensated. But I agree that this is not the most user friendly approach for some applications.
We will provide examples for using additional temperature sensors in our community early next year.
- acceleration sensor not useable due to limited samling rate
We can't share your view on this point, since we're using the acceleration sensor in our other products based on the same SW. What sample rates would be required for your application?
- battery operation last only for few days when doing serious measurement tasks
The battery capacity of 600mAh allows operation times between hours (full wifi use and sensors on) and month (using sleep modes) which in our experience is sufficient for most users. What life time would you expect for your use case?
I hope these points can answer your questions to some extent. Many thanks for taking the time to give us such a detailed feedback. We would like to get into a more detailed discussion based on your use cases; if you are interested in this, please let us know.
thanks for your extensive response, which I appreciate a lot.
I was evaluating your XDK for a customer of mine who planned to use it for an industrial project (of which I cannot give more details here unfortunately). When I saw your XDK product I was really glad, as it provided almost all required features on its marketing slides. When I eventually realized that it does not hold my expectations I was just as much dissapointed.
In the meantime I have done an estimation how much development effort I had to invested to make it work for my intended use. Unfortunately the effort was beyond the available time. Thus we decided to better go on with our own design which is exactly matched on our needs.
Still I would love to see the XDK evolve. Maybe it will become useful for us in the future.
I agree with what your are saying. So I will only respond to your questions.
> What sample rates would be required for your application? 10kHz for acceleration 40kHz for microphone
> What life time would you expect for your use case? >= 1 year > We would like to get into a more detailed discussion based on your use cases; > if you are interested in this, please let us know. I think this thread is already growing beyond its intended length. But I am glad to discuss further on the phone.
best regards Stefan
I'm sorry that the XDK wasn't the right pick for your application. I have a rough idea on what you're trying to do here. For this kind of application, the build-in consumer sensors are simply not suitable. There are other sensor types (MEMS or different technologies) that could be used for this. Also, the microphone signal quality (even if supported properly) might suffer from insufficient coupling to the "signal source" by the design of the housing.
I've forwarded your answer to our product manager, he will try to contact you eiter in the next days or in beginning on 2017.