Transmitting different sized packets

Using Arduino Networking, Protocols, and Devices
#1

Hi, this may be someting simple I just do not understand, but..

I have a radio controlled boat which has an NRF24 as a receiver, any data it receives is processed and passed to the master controller arduino that handels the running of the boat, on receiving any data it sends an ACK package back that includes temperature and water sensor readings.

The transmitter is another RF24 on a nano which has a joystick and also has a touchscreen monitor, It has multiple screens. when not busy it sends a one byte heartbeat to the RX, so it receives back the Temp/water readings using the ACK system

Screen 1 displays the latest Temperature and water level readings, so it only uses the received ACK data.

Screen 2 uses the joystick to act as a backup radio control for the boat, so when using screen 2, a 3 byte data packet is sent, instead of the heartbeat, containing three channel data (speed, Steering and Aux3)

Screen 3 allows me to change some of the settings on the master controller, so it sends five bytes of data, instead of the heartbeat. More bytes may be added in time.

Further screens will be added but are not relevant to my problem.

So the problem is my transmitter is sending differen sized packets, depending which screen it is on, but the receiver does not know what to expect, what is the easiest solution to this??

Note - The boats transmitter and receiver that I control the boat with is a totally seperate 27Mhz (crystal) system

Nick

#2

nickcwizardscx:
So the problem is my transmitter is sending differen sized packets, depending which screen it is on, but the receiver does not know what to expect, what is the easiest solution to this??

IMHO the simplest solution is to send a standard long message every time even if some of the data has not changed.

...R
Simple nRF24L01+ Tutorial

#3

Thank you Robin2. With my limited knowledge of programming I think you may be right.

I was thinking of setting the receiver to listen on three pipes, and have each pipe set to receive a different package, then switch the transmitter to a relevant pipe (on changing screens) before sending.

The other option was to make all the packets from all screen the same size, filled with zeros if needed, but have the first byte as the package type number, so the receiver can copy the data to the correct data array.

Nick

#4

nickcwizardscx:
Thank you Robin2. With my limited knowledge of programming I think you may be right.

My advice has nothing to do with your knowledge. It just makes the programming simpler and what advantage do you see from sending different sizes of message? The time saving is minuscule and I doubt there is any opportunity to make practical use of it.

I was thinking of setting the receiver to listen on three pipes, and have each pipe set to receive a different package, then switch the transmitter to a relevant pipe (on changing screens) before sending.

That sound woefully complicated.

The other option was to make all the packets from all screen the same size, filled with zeros if needed, but have the first byte as the package type number, so the receiver can copy the data to the correct data array.

That sounds reasonable. However if it is possible to devise a single message that can contain the data needed for every case it would be even simpler.

I assume you know how to use a struct to create an object with several different data types.

...R

#5

nickcwizardscx:
So the problem is my transmitter is sending differen sized packets, depending which screen it is on, but the receiver does not know what to expect, what is the easiest solution to this??

Set the first byte of the packet to represent the packet type or size.

The receiver then deals with the packet depending on that first byte.

Its not difficult to extend that so that the first 3 bytes of a packet are packettype, destinationaddress, sourceaddress.

#6

Hi

use padding
explaining: Make the packet size fixed, and fill the empty space with zeros 00000

#7

srnet:
Set the first byte of the packet to represent the packet type or size.

The receiver then deals with the packet depending on that first byte.

That won't work with an nRF24 because you read the whole message as a block rather than byte by byte. There is a function to tell you how many bytes have been received but it makes life far more complicated compared to making all messages the same size.

...R

#8

Thank you all for your input.

I think I am going to use multiple packets of the same size because :-

a) the total number of data bytes would be over 32.

b) some of the data (speed and steering) will be changing due to the radio (Not nrf24) control unit, and only when I send a steady stream of data from the touchscreen transmitter (the nrf24) will the system listen to that data.

c) 90% of the data sent will just an empty heartbeat, so I can get the ACK data to display on the screen.

#9

It would make it easier to give useful advice if you can provide an example of each type of message that you want to send.

There is no reason why the "heartbeat" message cannot be 32 bytes long.

...R

#10

I see no reason to expand messages to same size just to make parsing easier. A long message will not only have an effect on transmission time but also on used airtime - the time your transmitter "pollutes" the radio frequency. If nobody cares about airtime - "just because it is easier to parse" - we end up in stuffed radio bands.

I totally agree on:

Set the first byte of the packet to represent the packet type or size.

Either decide on the message size what kind of parsing is needed or a single additional byte to represent the message type. This gives you up to 256 different message types - if you need more - let us know...

#11

noiasca:
A long message will not only have an effect on transmission time but also on used airtime - the time your transmitter "pollutes" the radio frequency.

IMHO these are theoretical objections.

Let's wait until the OP gives us examples of what he wants to transmit.

...R

#12

Ok, let me first introduce the Ghost Ship that I am building, then I will try to explain what I am doing.

#13

As this boat is an experiment and I am not very good at programming the arduinos (e.g. I am not using PID to control the stability, I am just moving the fins in direct response to the gyro) I will need to 'tweak' a lot of settings as things progress. So I have made a hand held unit with a TFT touch screen and an NRF24 to talk to the boat, The TFT screen will have various functions which I will call screen 1..2..3 etc.

Screen 1 is the one that will be in use 90% of the time, it will send a heartbeat (1 byte) to the boat and receive the following data (all bytes) Temp from 4 sensors, water level from 2 sensors and an average of the height senso readings (7 bytes)

Screen 2 is an emergency replacement for the 27Mhz RC transmitter should it loose signal (and the NRF24 still has signal), it will need to send the three channel signals (3 bytes)

Screen 3 (used occasionally) allows me to alter the pre sets for the center point on all 4 stabaliser fins, the required height from the height sensor and the center presets for steering and speed. These figures will have to be stored on the eeprom so they will be remembered after alteration. This can only be done whilst the boat is oprerational.(8 bytes)

Screen 4 (used occasionally) allows me to alter the constants used in the stabalisation routine, altering these will allow me to get better results in differing conditions, once I find a good standard set I will edit the settings in the program and re upload it, but I still have the option to fiddle them. (5 bytes)

The 7 bytes received on Screen 1 are the only bytes sent from the boat to the Hand held screen, all other bytes are going the other way (only 17 bytes as it happens) so I could send them all as one 17 byte heart beat.

Having written all this out it seems I have answere my own question, although I did not want to send the Screen 2 data if the RX was still working, but that can be sorted in code, I also thought there would be more data to send, which there may be in future, but also by then I probably will not need to edit the settings.

Thank you for helping me and sorry if I have been wasting your time.

Nick

#14

nickcwizardscx:
The 7 bytes received on Screen 1 are the only bytes sent from the boat to the Hand held screen, all other bytes are going the other way (only 17 bytes as it happens) so I could send them all as one 17 byte heart beat.

That would be my recommendation.

As you have the capability to send data to the boat with the nRF24 I suggest you dispense with the 27MHz wireless and just use the nRF24 - it is a lot more versatile.

…R

#15

I can not trust the NRF24, at least I have been using the 27Mhz for years and know it works.

#16