TX question: does openant supposed to be used in TX way? I mean broadcast out data, just like a normal sensor.

[linxucc]

Hello Tigge,

Thanks for making this library, it's great, definitely you made a lot of things easier.

But for now, I have a different situation, what I want to do is the TX side, that is to say, make a master channel "broadcasting sensor" instead of a slave channel receiving from other ant+ devices. For example: I have some kind of a temperature sensor plugged in the board, and I can get the readings, what I want is to implement the Ant+ Temperature Sensor profile, to make it a standard Ant+ Temp sensor, so other watches of whatever could read it.

I have explored the examples, the receiving side is no problem, without further digging, I'm just wondering if this lib is designed to be worked in a way that do "Master channel TX" than "Slave channel RX"?

I'm quite familiar with ant+ protocols itself, but that's on the Garmin's connect IQ platform and SimulAnt, CIQ has a quite simple Ant API, all I need to do is set the channel type to TX, set the network key, period and frequency, then just set the broadcast data using sendBroadcast() things like that, the timing things are automatically handled.

I noticed in the channel.py, there are methods like "send_acknowledged_data()" and "send_burst_transfer()", but things like the "send broadcast" is not implemented there. So I'm wondering if I were to send some broadcast, a call to driver's write() will be good, just like the implementation in "send_acknowledged_data()", or it's something else? Does openant supposed to be used in this way?

Thanks!

[Tigge]

Hi! That is a good question. It should implement at least a large part of the standard but I'm unsure if this is 100% covered as of now. I don't think there is anything really special with operating in another mode, just setting the correct channel parameters - but could also be missing something more. That being said it was a while since I worked with this, I haven't tested anything similar to this, and I'm a bit unsure if there hardware requirement that the usb ant sticks are not covering. But I'd be a least a little bit surprised if this could be accomplished with a few smaller changes to openant.

[linxucc]

@Tigge Hi! Thanks for your reply. Seems my feeling is right that you might have made this library without considering it used as a TX master, because everything else is so complete except no TX or broadcast things... That's why I ask this question in the first place.

My concern is the same, "could also be missing something more" , but as you said, there shouldn't be anything really special. Broadcast should be no harder and no different than Acknowledge messages.

With some further digging into the protocols, and the source code of Mac SDK, it seems how the message are sent to the serial port is the same between Broadcast and Acknowledge, the only difference is the message itself (message type).

Your code base seems very solid, and by far the most complete implementation of ant protocol implementation in Python. So I'll make some tries in next few days, If there's any success, maybe I'll extend the lib a little bit to make it compatible with TX.

[linxucc]

@Tigge An update: Master channel TX is OK. Some minor changes has to be made, but it works great.

In short:

• set channel type to TX master, to say, "Channel.Type.BIDIRECTIONAL_TRANSMIT".
• write message directly with "Message.ID.BROADCAST_DATA" + 8-byte data payload, this will set the broadcast TX buffer with provided data.
• upon each TX tick, Ant chip will sent whatever in current TX broadcast buffer, same data got sent over time if no change to be made.
• The recommended practice is to update TX broadcast buffer with new data upon each TX tick, each TX tick will generate a RF event "EVENT_TX", which should be handled by user program to feed new data for next outbound message, this solves the timing problem.

Some minor changes including:

• add a new send_broadcast_data(...) function, layer by layer, similar to other data sending functions.
• add a new type of event "TX" in event handlings, similar to the handling of "burst" and "broadcast".
• separate the channel event "Message.Code.EVENT_TX" from other RX focused events, make it's own event type.

After project at hand I think I'll wrap these things up and try to make some contribution to the original code, to make it directly support master channel TX. Worth note that your code base is strong, no USB hardware problem or anything, it works great.

Thanks for the original work, my regards!

[huddy987]

@linxucc Do you have that TX code around? If you do would you mind forking this repo and posting it? I'd be curious to take a look at it, and if you don't have the time available to make a pr here I'd be interested in doing that.

[drkingpo]

This issue is solved with Pull: #54