This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Multiple data sources transmission routing and identification

Dear Team, 

I'm preparing an application for nRF52840 that will require to send and receive data collected from two different sources, I2S and UART, two UART or SPI and UART channels. 
One of the connections will be lower in bps than the other but essentially they must arrive to the receiver and be routed to the correct UART, I2S or SPI port.
How do I route the packets to be sent to the correct interfaces at the destination (receiver)? 
On the other hand, I'll be interested in using the lowest latency protocol available (maybe ESB or Gazell). Other protocols could be used if the features are not availabe for those two. 

Is it possible to do this? 

About the bandwidth, I'll only need about 500/600 kbps as any audio traveling towards radio will be previously compressed and the other channel will be small control data to interface with the custom code and other peripherals. 

Thanks for your time and attention.
Best regards, 

Mental Mode

  • Hi Pablo

    How do I route the packets to be sent to the correct interfaces at the destination (receiver)? 

    You are free to do this any way you like. If you can combine all the serial data into a single packet then you can use the position in the packet to differentiate the different interfaces, and make sure to route the right parts of the packet to the right interfaces on the receiver end. 

    Alternatively you use one packet for each of the serial interfaces, and put some kind of command byte in the packet telling the receiver which interface the data is from. The drawback of this method is that it is not very efficient to send many small packets if you want to maximize data throughput. 

     

    Is it possible to do this? 

    For maximizing bandwidth I would recommend either ESB or BLE. ESB will give you lower latency and slightly higher maximum throughput, while BLE is easier to design in since the entire protocol is provided (the ESB protocol is quite simple, and will require more work on the software side). 

    Using BLE will also require BLE certification, which adds to the cost. 

    In both cases it is possible to do it, it's just a matter of priorities. 

    Best regards
    Torbjørn

  • Hi Torbjørn, 

    Do you have any example about both examples? Take into account that the custom command packets will be sent by the user only sometimes so, reserving space for that commands and interface in all packts will be pretty unnecesary. About creating whole packets with the commands per each interface may be a waste as you said so, If I have an example of each one I could create some kind of conditional packet building to mix them and not waste part of the packets that will be send continously from one of the interfaces.

    If you don't have examples of this, I could review any sample of packet building and origin-destination specification in the packet or interface.  
    Sorry if I'm asking these basic things but I'm pretty new on this technology Slight smile

    About protocols, I've been exploring that options and multiprotocol stacks.
    I have to say that the options are very flexible and seem to be pretty powerful...
    Maybe I'm little lost with frequency selection and tables... I read that there 80 channels for BRE to create necessary tables, but I have to study a way to make less populated selectable ones. What's the minimum frequency separation that I could use in ESB? Does it common to Gazell?

    Again, thanks for your time and patience. 

    Best regards, 

    Mental Mode

  • Hi Pablo

    If you look at any of our examples the different data types are usually organized in structs, allowing you to build up a packet in a logical manner instead of just using long arrays of bytes. 

    Then in applications where you want to send different types of data you can define multiple different structs, and use a command byte to identify them. 

    As an example consider the following two data structures, and an enum used to create unique identifiers for them:

    typedef struct
    {
        uint8_t     cmd_byte;
        uint32_t    some_data;
        float       some_more_data;
    } packet_type_1_t;
    
    typedef struct 
    {
        uint8_t     cmd_byte;
        uint8_t     spi_data[4];
        uint8_t     i2c_data[6];
    } packet_type_2_t;
    
    enum {PACKET_TYPE_1, PACKET_TYPE_2};

    Sending a packet of type 1 using ESB can be as simple as this:

    static uint32_t send_packet_type_1(packet_type_1_t *data_packet)
    {
        nrf_esb_payload_t esb_payload = {0};
    
        // Ensure that the cmd_byte field is set correctly, in correspondence with the packet type
        data_packet->cmd_byte = PACKET_TYPE_1;
    
        // Populate the esb_payload struct
        memcpy(esb_payload.data, (uint8_t*)data_packet, sizeof(packet_type_1_t));
        esb_payload.length = sizeof(packet_type_1_t);
        esb_payload.pipe = 0;
    
        // Forward the data to the ESB library
        return nrf_esb_write_payload(&esb_payload);
    }

    Then on the receiving end you need to check the command byte (the first byte of the packet in this case) and process it accordingly:

    static uint32_t process_received_packets(nrf_esb_payload_t *rx_payload)
    {
        packet_type_1_t packet_1;
        packet_type_2_t packet_2;
    
        switch(rx_payload->data[0])
        {
            case PACKET_TYPE_1:
                // Copy the ESB payload data into our struct variable
                memcpy((uint8_t*)&packet_1, rx_payload->data, sizeof(packet_type_1_t));
    
                // Now the data is stored in the packet_1 struct, and can be accessed accordingly. 
                // What to do with the data is up to the application. 
                break;
    
            case PACKET_TYPE_2:
                // Similar to the type 1 case, except the packet_2 struct is used
                break;
        }
    }

    To maximize the throughput you should try to make each packet as long as possible, up to a maximum of 252 bytes for ESB. 

    BLE defines 40 channels, each spaced 2MHz apart in the range 2402-2480MHz. 

    With ESB you should use 2MHz separation if you are using the 2Mbps PHY (on-air bitrate), or 1MHz separation if you use the 1Mbps PHY. 

    Gazell is based on ESB and supports the same channels. The main difference is that Gazell supports a mechanism for switching channels automatically, while ESB requires you to manually control the channel selection. 

    Best regards
    Torbjørn

  • Hi Torbjørn,

    All clear. Now I have something to start from.
    Amazing support by the way guys. 

    Thanks a lot for your time and attention. 
    Have a great day! 
    Mental Mode. 

  • Hi Pablo

    Thanks for the kind words, and the best of luck with your project Slight smile

    Best regards
    Torbjørn

Related