Multiple data sources transmission routing and identification

RE: Multiple data sources transmission routing and identification

ovrebekk — Mon, 27 Apr 2020 06:46:10 GMT

Hi Pablo

I am happy to help. You have a great week too 🙂

Best regards
Torbjørn

RE: Multiple data sources transmission routing and identification

Mental Mode — Thu, 23 Apr 2020 16:34:58 GMT

Hi Torbjørn,

Amazingly explained... Thanks a lot!

And for the literature proposal! I'll check out that to be more concentrated on plain C.
I'll be doing experiments with modified versions of the examples and my own code but now I have the basic bricks.

I promise not bothering you with code related stuff. :)

Thanks again and have a great week.
Best regards,

Pablo.

RE: Multiple data sources transmission routing and identification

ovrebekk — Thu, 23 Apr 2020 15:34:43 GMT

Hi Pablo

All our code examples including this one are based on C, not C++.

Technically C++ is a superset of C, but if you are reading about C++ you will get a lot of information about classes, inheritance, function overloading, exceptions etc which is not relevant to understand our C examples.

In other words I would strongly suggest starting with a book on C to get familiar with the basics of the language, and then you can move to C++ later on if you need to learn all the additional features supported by C++.

A good start is what many consider the "bible" on the C language, "The C Programming Language by Kernighan and Ritchie", which even seems to be available for free here.

As for your questions, I tried to answer them inline:

devzone.nordicsemi.com/.../reply.c

Best regards
Torbjørn

RE: Multiple data sources transmission routing and identification

Mental Mode — Wed, 22 Apr 2020 19:15:20 GMT

Hello ovrebekk,

Just for your to know, I've been programming for years in "too much high level" languages as Java, C# and so on...

I've been studying C++ in my free time the last 2 months, but at this point there are still things that I don't fully understand about the code proposed so... Let me put the code step by step and comment what I'm understanding.

Probably, you're so used to code for hardware using these compilers but I'm not so familiar with these types and operators.

I'll paste your program and comment my doubts about the original definition and transmitter part.

The receiver part will be clarified with the transmitter part.

Again. I know that you're not here to teach C++. You're here to help to implement your solution.

I'm using SES and run several examples so I'll able to test this at the moment you reply.

// COMMON STRUCT DEFINITION:

typedef struct // Struct definition for dummy example. For me to understand how a struct is declared. 
{
    uint8_t     cmd_byte; // Unsigned integer size 1 byte variable called cmd_by. I understood that this will be the “packet type” for my program to distinguish between i2c or whatever origin. To be able to put in the right port on receivers side.
    uint32_t    some_data; // Unsigned integer size 4 bytes variable called some_data. This is dummy thing to explain struct declaration.
    float       some_more_data; // Float type integer size float variable called some more data. Another dummy thing to explain another variable in case of wanting to send more than 1 data in the same struct type. 
} packet_type_1_t;

typedef struct 
{
    uint8_t     cmd_byte; // here we are declaring what type of data I want to send to be routed by the receiver. 
    uint8_t     spi_data[4]; // Unsigned integer size 4 bytes ARRAY called some_data maximum 4 bytes in length. Is this the data size expected from SPI?
    uint8_t     i2c_data[6]; // Float type integer size float ARRAY called some more data maximum 6 bytes in length. Is this the data size expected for I2C data? 
} packet_type_2_t;

enum {PACKET_TYPE_1, PACKET_TYPE_2}; // Here you declare the two structs as unique types to be used in all the program. Take into account that my original program was intended to separate i2c and spi in two different structs but this is OK for me, 

// TRANSMITTER PART:

static uint32_t send_packet_type_1(packet_type_1_t *data_packet) // function declaration returning 4 bytes of static (doesn’t change each time is called) data called send_packet_type_1. **DOUBT** Are you passing the cmd_byte and the “deferenced pointer here? If that’s the case, why we don’t have the comma? 
{
    nrf_esb_payload_t esb_payload = {0}; // Declaration of a variable using your struct type nrf_esb_payload_t called esb_payload and initialized to 0. 

    // Ensure that the cmd_byte field is set correctly, in correspondence with the packet type
    data_packet->cmd_byte = PACKET_TYPE_1; // Here, we are defining our data packet cmd byte struct as type 1. 

    // Populate the esb_payload struct
    memcpy(esb_payload.data, (uint8_t*)data_packet, sizeof(packet_type_1_t)); // Copy our unsigned 1 byte data packet variable to es_payload_data and defining the size of out whole struct. **DOUBT**Why the * in uint8_t?
    esb_payload.length = sizeof(packet_type_1_t); // Populating the required variable esb_payload.length with the size of the struct.
    esb_payload.pipe = 0; // Selecting the pipe to send it. **DOUBT** how many pipes do I can use?

    // Forward the data to the ESB library
    return nrf_esb_write_payload(&esb_payload); // Returning all the stuff to the nrf_esb_write_payload function.
}

Again, Thanks for your valuable help.

Best regards,

Pablo.

RE: Multiple data sources transmission routing and identification

ovrebekk — Thu, 13 Feb 2020 07:17:47 GMT

Hi Pablo

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

Best regards
Torbjørn

RE: Multiple data sources transmission routing and identification

Mental Mode — Wed, 12 Feb 2020 14:05:50 GMT

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.

RE: Multiple data sources transmission routing and identification

ovrebekk — Wed, 12 Feb 2020 12:10:49 GMT

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

RE: Multiple data sources transmission routing and identification

Mental Mode — Tue, 11 Feb 2020 14:25:54 GMT

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 🙂

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

RE: Multiple data sources transmission routing and identification

ovrebekk — Tue, 11 Feb 2020 12:17:10 GMT

Hi Pablo

[quote user=""]How do I route the packets to be sent to the correct interfaces at the destination (receiver)? [/quote]

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.

[quote user=""]Is it possible to do this? [/quote]

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