I'm using a VS1053,to do a PCM recording for 1 minute by using STM32l4 microcontroller.

The data is read from the VS1053 at 16 MHz, the sampling rate is 8000 sps and each sample is 2 bytes, which makes it 128 kbs to be sent.

I was using a UART to send this data to another module at 230,400 baud but I had to reduce this to 115,200 baud as the Bluetooth module the UART connects to does not support 230,400 baud.

Now the data is acquired at a faster rate than sending. The VS1053 has a buffer form which I read 512 bytes each time via SPI. How can I handle this situation to send all the bytes via UART without losing it?

  • 1
    \$\begingroup\$ Speed the UART up. If data is coming in, faster than it's going out, you can buffer (if it's for a short period of time, and you have enough memory), speed it up going out, lose it, or compress it somehow. \$\endgroup\$ – Colin Jan 15 '18 at 8:20
  • \$\begingroup\$ I cannot increase the UART baud rate as the module to which I communicate do not support high rates, I have no enough RAM to buffer it as well \$\endgroup\$ – Arun Joe Jan 15 '18 at 10:34
  • \$\begingroup\$ why is it down voted? , is that a wrong question? \$\endgroup\$ – Arun Joe Jan 15 '18 at 14:28
  • \$\begingroup\$ I can think of one reason: You're somewhat obviously asking for an impossible thing here, and you probably know it as well. You can't send the data and you can't buffer it. What do you expect to happen? \$\endgroup\$ – pipe Jan 15 '18 at 17:54
  • \$\begingroup\$ My be I can reduce the samples , like sending every alternate samples? or send only the 8 bit values skipping the higher bits? or any algorithms that might help? I think I overestimated StackOverflow \$\endgroup\$ – Arun Joe Jan 15 '18 at 20:25

How can I handle this situation to send all the bytes via UART without losing it?

If the final recipient of the data cannot handle the natural data rate that is being transmitted then you only realistically have two options: -

  1. Throw away data
  2. Buffer the 1 minute's worth of data and ship it out at a slower rate compatible with the final recipient.

You don't need much RAM to do (2), about 8 Mbits maximum.

  • \$\begingroup\$ Actually you only need about 800 kbits since you can still push out 115 kbit/s so the buffer isn't filling up quite as fast. \$\endgroup\$ – pipe Jan 15 '18 at 13:42
  • \$\begingroup\$ @pipe yes, so I changed my final sentence to state maximum! \$\endgroup\$ – Andy aka Jan 15 '18 at 14:02
  • 1
    \$\begingroup\$ Ah the phantom downvoter strikes twice today. If anyone can see an obvious mistake in what I've written I'd appreciate heads up. \$\endgroup\$ – Andy aka Jan 15 '18 at 17:39
  • \$\begingroup\$ Wasn't me! Some people downvote answers to questions which are obviously off-topic, but in this case it's weird. \$\endgroup\$ – pipe Jan 15 '18 at 17:53
  • \$\begingroup\$ @pipe yeah I knew it wasn't you! \$\endgroup\$ – Andy aka Jan 15 '18 at 18:03

IF you need to send continuous data at that rate within those constraints, the only possible way is to compress it somehow. Either lossless or lossy compression is possible.

But it clearly depends on the information content or “whiteness” of the data, I.e., bandwidth and dynamic range. It also depends on the processing power you have available.

If your bandwidth is low enough, you can simply filter and subsample. If the dynamic range is low enough you can throw bits away.

If the slew-rate of the data is low enough, a method that is somewhat generic and with wide applicability is delta-coding of the data, that is calculate the difference between successive samples and only send that.

In voice, where large changes mask small ones, data compansion is commonly used.

If there are data patterns that are much more frequent than others lossless Huffman encoding would work. If you have the processing power, you can even implement a full Lempel-Ziv algorithm.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.