• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 1698 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Streaming digital versus analog audio with CC1310.

Julian
Prodigy 50 points
Other Parts Discussed in Thread: CC1310, CC1120, CC1350

Hello,

     This is my first post on E2E. I am relatively new to working with embedded systems (I am a biologist with minimal engineering background), so please excuse me if my description of the problems I'm facing are overly simplistic.

     I am attempting to create an extremely small audio transceiver tag that can be placed on very small birds (the transceiver functionality is important for allowing me to turn the tag on remotely only when needed, to save power), and I have therefore settled on the CC1310 for the MCU.

     The I2S interface capabilities of the CC1310 appeared to offer a promising approach to wirelessly streaming audio data from a digital MEMS microphone (many of which also have an I2S interface). That said, the lack of available I2S example code for the CC13xx and CC26xx families of MCUs has been a real hindrance to my progress on this front. In addition, it occurred to me that some TI RF chips (e.g. CC1120/1175) allow direct analog frequency modulation of the RF carrier, which would enable the use of analog microphones, and might offer a less power-hungry solution.

I'm fairly certain that the CC1310 does not support analog FM, but wanted to ask the E2E community:

1) if there are potential workarounds for simply frequency modulating the RF carrier of the CC1310 with an analog MEMS mic signal,

2) if so, if this is likely to offer a lower-power solution than using a digital I2S approach, and

3) if not, I'd appreciate any advice concerning finding example code for using I2S with a digital microphone to stream audio data (I am aware of the fairly sparsely-commented code snippets that have been shared on E2E over the last several months, but am hopeful that someone may have a more comprehensive example to share at this point).

     I would be happy to provide additional information, but I wanted to keep this post as general as possible initially.

Many thanks for your input!

-Julian

  • 0
    TI__Mastermind 36375 points
    Julian,

    Streaming digital data is not that straight forward. Our devices do support high speed data modes (4mbps at 915MHz and 5mbps at 2.4GHz). But then the issues is getting the I2S data over the wireless link without too much data loss that it will be corrupted at the output. There will likely need to be some code that tries a packet twice and does some graceful fall back when packets are missed. (many solution is to just replay the last know good packet).

    I will reach out to a other apps team to see if they have any I2S driver written yet.

    /TA
  • 0 in reply to TA12012
    Prodigy 50 points

    Thanks for your input TA; It's very much appreciated.

        The sample rates I'm hoping to obtain are on the order of 48 kHz (most animal vocalizations occur below 24 kHz), though with an I2S protocol, I'm not sure what this would translate to (1 channel x 16 bits / sample x 48 kHz sampling rate = 768 kbps??). Wouldn't the CC1310's ability to support higher speed data modes provide the possibility of error detection (e.g parity check, checksum, or CRC) and error correction algorithms instead of simply sending each data packet twice?  

        Regarding an I2S driver, I (naively) thought that a driver might be available through the TI-RTOS Resource Explorer for the CC1350 Sensor Tag, since there is a digital MEMS microphone on the board. The latest information I have suggests that there are still no I2S examples or drivers (though a basic PDM example is available), though I would love to be proven wrong.

        All this said, it is still not clear to me whether a digital approach is the only one supported, and whether a direct analog FM approach might be possible with the CC1310 (or other sub-GHz RF MCU). The possible issues of data corruption and buffering with digital streaming would make this approach more attractive, and it's clear (from existing physically small analog "spy bugs") that a lightweight analog approach can work (at least hypothetically).

    Cheers,
    Julian

  • 0 in reply to Julian
    TI__Guru**** 317180 points
    Note that "analog FM" is not a analog feature, as stated in the 5.2.4 in the CC1120 UserGuide AnalogFM (CFM). It's basically a possibility to set the deviation directly in a register. In other words you will not be able to connect a analog microphone directly.

    Will you be able to use a audio IC between the microphone and the CC1310 to do some compression?
  • 0 in reply to TER
    Prodigy 50 points
    Thanks for the input TER,

    I'm assuming that I have not missed an equivalent (pseudo-)analog FM feature in the CC1310. If this is true, then it sounds like an all digital approach (i.e. I2S with digital output MEMS mic) might be the only (potentially) feasible solution for streaming audio using only the CC1310 and a digital mic.

    TA (in his response above) suggested that in using an I2S approach data corruption at the output could be a real issue, though (in re-reading his answer) I'm unclear if he meant that there might be corruption in the digital encoding of audio data before being sent on the RF carrier due to the difficulty of packaging audio data at high rates, or that there would be corruption at the receiver input stage (due to noise and interference during transmission). I can deal with the latter issue partially by making sure I am physically close to the audio transmitter. It's my hope that someone who has found a solution to the former issue (i.e. buffering, packaging, and sending data at high rates) might be willing to provide example code.

    To answer your question about my specific application, I won't be able to use an audio IC for compression due to weight constraints (the tag needs to be below 150 mg, so even the addition of a tiny 2x2 DSBGA package IC represents a major step towards exceeding this limit).
  • 0 in reply to Julian
    TI__Guru**** 317180 points
    With the very limited weight requirement, are you able to use a good enough battery?

    When transmitting over the air, some packets will not be received or be received with bit errors. This can be due to noise from other transmitters, multipath, fading etc. So your protocol needs to take into account what to do when a packet is received with errors or not at all.
  • 0 in reply to TER
    Prodigy 50 points
    Battery power is certainly an issue, however, I am working on an energy harvesting solution so that this tag can be activated on command when sufficient battery power is available, and then put back to sleep to recharge the battery (using PV cells and a voltage regulator).

    Regarding error detection and correction on the receiving side, I'm not constrained on weight or current consumption (within reason). On the transmitting side I will have to find a good balance between error detection/correction and power consumption, but if I'm transmitting a signal with sufficiently high SNR I might be able to get away with a protocol that allows for some (low) level of data corruption.

    All that said, it's beginning to sound like an analog FM approach might be a better way to go. Especially since it appears that example I2S code is not on the horizon, and I'm not a sufficiently competent embedded systems programmer to figure this out on my own.