• State Not Answered
  • Replies 22 replies
  • Subscribers 26 subscribers
  • Views 739 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288915
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

BLE Audio - many to one, power consumptions of DK?

user101804

Excited to have ordered my BLE Audio DK which uses NRF5340.

In my use case I am looking for many microphones (audio transmitters) to a single listening device (audio receiver). Ideally, they'd be synchronised reasonably well but again that is something we can deal with in the back-end system. In terms of link robustness, will this work? e.g. 5 senders to one listener? 16bit, 16kHz ideal, but could be reduced if needed. 5 was a random number, even two would be useful. Can one use variable rates on each stream? And then I wasnt sure whether you'd recommend connected or broadcast - I understand connected minimises packet loss due to feedback. 

Finally, any idea of the DK / estimated power consumption for nRF5340 to send a single audio stream?

Thanks in advance,

Parents
  • 0

    Curious to see how this effort progresses.

    @Hillman007 have you found you may need to make changed to the net core ( child image ) ?

    I am interested in knowing what limitations there may be in the binary child image. 

    Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

    Hopefully NordicSemi can shed light on this.

Reply
  • 0

    Curious to see how this effort progresses.

    @Hillman007 have you found you may need to make changed to the net core ( child image ) ?

    I am interested in knowing what limitations there may be in the binary child image. 

    Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

    Hopefully NordicSemi can shed light on this.

Children
  • 0 in reply to user3313

    Hello mtsunstrum,

    Thank you for your patience with this.

    mtsunstrum said:
    Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

    Could you elaborate on what kind of non-standard LE Audio use cases you are referring to here?
    The precompiled Packetcraft controller should not limit your LE Audio application, no. The Packetcraft controller implements the isochronous channels necessary for LE Audio.

    Best regards,
    Karl

  • 0 in reply to user87869

    Hi Karl, welcome back, and thank you for the responses.

    For example, I would regard @Hillman007 use-case as a non-standard LE Audio use case.

    I understand ( or I think I understand) that the PacketCraft controller handles BLE 5.3 operations on the network core, and I understand the upper layers of LE Audio are handled by NCS, running on the application core.

    So for the binary PacketCraft controller, are there limitation such as:

    • a limit on the # of concurrent isochronous channels ?
    • any restrictions on number of concurrent "normal" LE Central / Peripheral connections
    • any restrictions on ability to support simultaneous LE Audio gateway and headset operation ?
    • is the PacketCraft work compliant with MPLS in any way, still allowing concurrent operation of ShockBurst/Gazell if we so choose.
    • for nRF5340 project, if we wanted to change DLE ( data length ), we had to change prj.conf setting for the network core, and rebuilt the network core. Are DLE changes affected/limited by the binary PacketCraft controller ?
    • compared to Nordic's own SoftDevice Controller are they any other capabilities missing from the PacketCraft controller ?

    Thanks, Martin

Related
Terms of service