- THIS IS ANT

Username		Password		Remember Me?	forgot password?

03 September 2015 09:27 PM

MaximumTrainer Sr. Member

Total Posts: 123

Joined 2013-10-07

PM

I would like to know the different between sending ack message vs broadcast message to a sensor.

For example, to send "Target Power" page to a FE-C Trainer
(page 67 of D000001231_-_ANT+_Device_Profile_-_Fitness_Equipment_-_Rev_4.1.pdf)

It specify to send an Ack message, but if I send a broadcast message, it still works.
I just want to understand the difference, except knowing if the message succeeded or not with ack.
I would like to minimize Radio used so I don't really need to know if the message was received or not, it is sent every second anyway.
Will using Broadcast save some message processing time with the radio?

Note:
I'm using CSM mode and controlling 7 FE-C trainer per ANT+ stick.

Signature

——————————————————
Free Indoor Cycling Software - https://maximumtrainer.com

08 September 2015 12:08 PM #1

BK Sr. Member

Total Posts: 120

Joined 2013-05-07

PM

The differences between acknowledged and broadcast messages are as follows:
1. Broadcast data is sent without the guarantee or knowledge of its successful transmission. A node that transmits an acknowledged message will be notified if the packet was sent successfully or not.
2. An acknowledged data packet uses more RF bandwidth than a broadcast packet
3. An acknowledged data packets consumes more power than a broadcast packet

Acknowledged messages are ideal in situations where a control message is being sent. This is because the controller can know if the controlled device successfully received the message, and re-transmit the message if the initial transmission was unsuccessful.

Sending a message every second on the back channel (from slave to master) may actually use more RF bandwidth than sending an acknowledged message occasionally. Profiles may require a page to be sent as only broadcast messages or only acknowledged messages.

For clarifications about the "Target Power" page, please post to the relevant ANT+ Forum.

08 September 2015 12:31 PM #2

MaximumTrainer Sr. Member

Total Posts: 123

Joined 2013-10-07

PM

Thanks for the detailed response.

I am sending acknowledge messages right now, as I want to conform with the FE-C profile.
I will see to change my algorithm and only change ack message when the target power actually change, not every second. I am doing this because it may be hard to track 25 different target power (25 FE-C trainer possible at the same time), and detect if the target changed (progressive target can change every second).

Also, when a message fail with Ack message, I get an error saying "transfer failed" but I need to re-initiate the transfer myself or it is done automatically? If it is done automatically, I can see using this without too much effort, if not, how do I know which message failed if I'm sending as many as 25 messages each second (25 different users with 25 different targets). That's why I'm sending it every second for now. it is easier to manage and I don't have to keep track of the last target power, but it uses more RF bandwidth as you said.

As of right now I'm not seeing problem controlling up to 10 trainer with this technique (can't test more ATM). There is more than one slave (node) sending the ack message so the load is spitted between ANT+ Sticks.

Thank you,
Max

Signature

——————————————————
Free Indoor Cycling Software - https://maximumtrainer.com

08 September 2015 01:25 PM #3

BK Sr. Member

Total Posts: 120

Joined 2013-05-07

PM

Acknowledged messages are not retried automatically. Your code will need to handle acknowledgement retries.

To handle retries, acknowledged messages will need to be sent sequentially to each device being controlled: retrying the message to one FE-C trainer until a successful acknowledgement is received, then sending the next message to the next FE-C trainer and retrying until a successful acknowledgement is received, and so on.

There will be an upper limit to the number of trainers you can ack to successfully using CSM. Please test with 25 FE-C trainers to see if this will be successful for your use case.

08 September 2015 01:42 PM #4

MaximumTrainer Sr. Member

Total Posts: 123

Joined 2013-10-07

PM

Ok that was I was afraid of. handling retries..
I will try to figure out how to handle retries, as it seems the most efficient way to use the radio.
There is probably a flag in the ack response (failed or success) that I could use to identify from which trainer the response was coming from. Then if it's a success, do not send the same message again until the load changed, if it failed, retry until success.

For now the upper limit seems to be 7 trainers per ANT+ Stick. Channel 0 is used for data reception, while the 7 other channels are used to send ack message to 7 different trainers. Using multiple ANT+ Sticks, I can control 7 trainers per stick.

Another way that could be done if the profile supports it later, would be to send a general broadcast message to all trainers that set the target in percentage instead of fixed watts. You could set the user FTP (or any other value) at the start using configuration page so that the trainer could calculate the target power directly from the percentage and the user configuration value.
example use case:
1- ANT slave Send target percentage 80% to all trainer (broadcast message)
2- Trainers calculate the target power with the percentage (80% * userConfigurationValue)
So just one message to control all the trainers basically

Thanks for your tips, will go back to try and code the ack validation you mentioned to improve RF usage.
Max

Signature

——————————————————
Free Indoor Cycling Software - https://maximumtrainer.com

08 September 2015 02:02 PM #5

BK Sr. Member

Total Posts: 120

Joined 2013-05-07

PM

I do not believe you will find a flag in the ack response that tells you which trainer you received the ack from. Sending the acks sequentially will ensure you retry on the correct receiver in CSM mode.

Are you using Continuous Scanning Mode on your display device? If so, to answer your original question: CSM uses maximum RF bandwidth and peak power consumption because the radio is on and receiving all the time. Sending acknowledgements may not significantly impact your power consumption or RF bandwidth because the radio is already on all the time.

If you are not using CSM (and it looks this way because you have channels open for specific tasks, and CSM uses the full radio), keeping track of retries is simple. Each channel tracks one trainer. Acknowledged messages sent on one channel that fail should just be retried on that same channel. Acknowledged messages may be sent on all channels simultaneously in this case, and retried simultaneously. And again, this method should be more power efficient than sending a broadcast on every channel's back channel every second.

08 September 2015 02:17 PM #6

MaximumTrainer Sr. Member

Total Posts: 123

Joined 2013-10-07

PM

I am not sure I will be able to know from wich trainer the ack response come from then if there is no ID flag.
I send the ack message sequentially but can send 7 per stick, they could come back in another order. (I do not wait to get a ack response to send another message)

As of right now, our latest official build use dedicated channel, but in the next version, we will be using CSM for our display. with CSM, we can read data from many sensors and this was the way to go for multiplayer. Good if sending Ack message will not change my power consumption, I am using a lot of power and don't really care, there is no battery issue as this software is running on desktop or plugged laptop computers.

Unfortunately, I am using CSM so keeping tracks of replies will be harder. Will see if it's possible to do, if not, the current way we use is not too bad as message are resend all the time so missing one is not a bid deal.

Here is a part of our code than configure and send the ack message to a FEC trainer.

void Hub::setLoad(int antID, bool fecTrainer, double load) {


    if (hashSensorFecNear.contains(antID)) {
        qDebug() << "HUB#" << stickNumber << "ok this sensor is close, send Load to it!" << antID;

        //return true if channel already openned, if not openned ask for permission to open
        bool readyForSendingData = checkToOpenChannelFEC(antID);

        if (readyForSendingData) {
            //Get the channel of this device (1..7)
            int channelNumber = hashSendingChannel.value(antID);
            uint8_t aucTxBuf[ANT_STANDARD_DATA_PAYLOAD_SIZE];
            FEC_Controller::EncodeTrainerTargetPower(aucTxBuf, load);
            pclMessageObject->SendAcknowledgedData(channelNumber, aucTxBuf);
        }
    }
    else {
        qDebug() << "HUB#" << stickNumber << "this sensor is too far, do not send load to it..." << antID;
    }
}

checkToOpenChannelFEC(antID) {

   //can open up to 8 channel per stick
   // simplified code for forums, in actual, we ask permission if we can control this trainer, if it's not currently being controlled by another stick, the parent will let use control the trainer (we open a channel to it)
   pclMessageObject->AssignChannel(currentLastChannel, 0, USER_NETWORK_NUM);
   pclMessageObject->SetChannelID(currentLastChannel, antID, constants::fecDeviceType, constants::transTypeFec);
} 

Signature

——————————————————
Free Indoor Cycling Software - https://maximumtrainer.com

ANT Forum

Ack vs Broadcast message

Signature

Signature

Signature

Signature