Hi t1tl, I strongly recommend you to read about the BLE 4.2 standard and supporting documents like the Apple Accessory Design Guidelines  BLE works best if you design your application thinking with characteristics and services using the GATT profile. Here a characteristic is limited to 20 bytes, unless you run through the data package length extension, which increases this limit to 251 bytes at the cost of not being supported by some BLE participants. Raw communication is sent using rates of 2MBit/s, however there MUST be a pause between packages which is the connection interval parameter. This is a limitation that comes from the physical layer in BLE since BLE devices are not allowed to continously stream data to avoid some heating of the cheap oscillators used to keep costs down. Also after a certain amount of usage, all BLE chips must include a mandatory pause. Maybe try to see if you can change connection interval value, but also evaluate if BLE is the right choice for your use-case. Regards, Francisco ... View more

Hi Verena, the 0th element in the frequency array is the DC component. If you want to see other frequency components, then you need to run the max finding method over index >= 1 Regards, Francisco ... View more

Hi Verena, the asignment operation is the correct way to copy small chunks of data in C. Using an ARM MCU, this operation may take longer if the source or destination memory location is not aligned with 16-Bit. Else, it should be quite fast. I see that you are calling Sensor_GetData(&sensorValue); which will take some time to complete.   Else your program has some issues: It copies and re-arranges the accel data into three buffers Converts the data into strings and sequencially writes small chunks into the SD card A more efficient way would be to Get a RAM array of some kBs (up to 10kB should be no big issue) Get sensor data Convert the sensor data into string and push it into the RAM array If the RAM array is full, or nearly full, perform a write into the SD card If these operations are performed inside the same thread, then you will have some holes during the time the SD card is writing. Else, a double task and double buffer method may be used (one task acquires data and one task writes data into SD card. One buffer is used to acquire data and once it is full, the buffer pointer goes to the second buffer and the SD card writer task writes the buffer content into SD card) Do you have some requirement in logging speed? Best regards, Francisco Llobet         ... View more

Hi Verena, In XDK we access the SD-Card via a SPI interface, which means that we are limited in features we can use. To maximize write performance, you should write larger blocks into the SD card, which means that you should acquire the data and buffer it into RAM and write it once a certain amount of data is over a threshould. For your use-case, try to find The number of write operations per second  -> Limited by the access time Wops = 1/AT The theoretical Max Write Speed (maximum throughput if there was no access time WSpeedMax = 1/WR) The maximum data-throghput in data/time is given by WSpeed (X)  =  X / (AT + WR * X) The  memory write model is time based and the formula is: WT = AT + WR * X WT is the write time AT is the access time (time it takes for the SD card to prepare the write operation) WR is the byte (or block) dependent time write X is the amount of data to write I run some characterizations in the past, and there we discovered that a typical AT varied between  4.26ms and 8.25ms using new cards (Class 4 and 10 cards with 32GB capacity). The mean value was AT_mean = 6.25ms. This gives you a measure of the maximum write operations per second (1/AT) supported by the SD card in SPI mode (121.2 ops/s to  234 ops/s) with mean value 160 ops/s To get more data-throughput, you need to send more data to the card with each write operation. The WR we found were around 1.25ms/kB with small deviations per card. Best regards, Francisco Llobet ... View more