Manage channel table with gazell pairing

RE: Manage channel table with gazell pairing

ovrebekk — Fri, 24 Mar 2023 08:45:28 GMT

Hi Thibaud

That is great news 🙂

Then I will consider the case resolved for now.

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Fri, 24 Mar 2023 08:43:01 GMT

Hi Torbjorn

In deed it solved my problem.

Thank you for your help, I will focus on my channel selectrion algorithm.

Best regards

Thibaud

RE: Manage channel table with gazell pairing

ovrebekk — Fri, 24 Mar 2023 08:04:03 GMT

Hi Thibaud

One potential issue is that the gzll_msgq used to store incoming packets on the host side can only store 1 item. This means that if you spend a lot of time processing this item you will not be able to receive any more from the stack.

Could you try to increase the size of this queue by changing this line in main.c to a larger number?

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Wed, 22 Mar 2023 09:50:28 GMT

Hi Torbjorn

You did not answer me on why my application is not able to receive some new gazell frames when I am either stuck in my main or in my gazell callback.

This comportement is weird becasue in Gazell user guide it is write that the callback has a queue for receiving new packet, even if you are still handling an older one.

For the channel selection algorithm I will do what you said and try to implement something from the gazell link layer implementation.

Thank you for your time.
Best regards

Thibaud

RE: Manage channel table with gazell pairing

ovrebekk — Wed, 22 Mar 2023 09:37:23 GMT

Hi Thibaud

On second thought I notice that the while loop will return as soon as there are no messages available in the message queue, so in that sense it should not be blocking for a long time.

[quote user="Thibaud"]But okay i will try to do something with a K_FOREVER in my system workqueue.[/quote]

Good luck. If you have more questions just let me know.

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Tue, 21 Mar 2023 10:14:24 GMT

The while in the system workqueue came from your example "gzl_ack_payload_host" .

Me personally, I tried to implemente a while in my main function.

But okay i will try to do something with a K_FOREVER in my system workqueue.

Best regards

Thibaud

RE: Manage channel table with gazell pairing

ovrebekk — Mon, 20 Mar 2023 08:58:51 GMT

It is not recommended to use a while loop like that in a workqueue item, since you will block any other callbacks on the system workqueue.

What you can do instead is to set up your own thread, and call k_msgq_get with an infinite timeout (K_FOREVER).

Then this thread will be suspended until there is anything in the message queue, and once you put something in the queue the thread will be woken up and start processing the message.

I did something similar in a UART driver I am working on, as you can see here.

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Fri, 17 Mar 2023 08:47:04 GMT

It is mentionned there is a queue for the callback function, it means if I am stuck in the callback function I should receive my new frame but have to wait for using it right ? Because I also tried to block the callback function with a getchar/getline from console but it resulted that my device cant send me a new frame

In my main I am just calling a function that classes the bytes I received in a custom structure.

This is what I am doing :

- When I receive a new frame I put it in my own fifo from the callback

-In the main I say while there is new byte that I didn't deal with I call a function which class every byte in a structure I implemented.

But when I am busy in that while, I can't receive any new frame from my other board.

I managed to workaround by replacing the while with a if so, I guess, the kernel can check if there is new data incoming beetwen every byte.

RE: Manage channel table with gazell pairing

ovrebekk — Fri, 17 Mar 2023 08:00:58 GMT

Hi Thibaud

[quote user="Thibaud"]Indeed I am not planing to pair devices very often but I would prefer implementing one pairing_channel which all of my devices will know and once paired device and host automaticly switch on one ( or a few) other channel exculsively used for communication. I understand that I can't do this whithout changing GZP implementation so i will think of what I do. [/quote]

I would recommend you do some testing with the standard GZP implementation before spending a lot of time to implement your own channel selection algorithm.

GZP is designed to support robust performance in challenging RF scenarios, and if you want to design something that works significantly better I think you will need to spend significant time and resources to do so.

[quote user="Thibaud"]I tried to change the main thread priority in kconfig with an higher value than the gazell low and high priority but the callback is still not call when I am stuck in a fuction called from the main.[/quote]

This sounds strange. Gazell should be able to operate, unless you run a lot of code in an interrupt context.

Do you have any examples of the kinds of code you run from main that will block Gazell?

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Mon, 13 Mar 2023 15:30:39 GMT

Hello Torbjorn,

Thank you I will thinnk about using USE_CURRENT or USE_SUCCESSFUL.

Indeed I am not planing to pair devices very often but I would prefer implementing one pairing_channel which all of my devices will know and once paired device and host automaticly switch on one ( or a few) other channel exculsively used for communication. I understand that I can't do this whithout changing GZP implementation so i will think of what I do.

I have an other interrogation but about the Gazell interruption this time :

I am making tests with a device and a host communicating and when my host is busy doing something, even a task called from the main, my device can't send any packet. On the host side It don't even call the callback "nrf_gzll_host_rx_data_ready".

I assume that is a priority problem but do main fonction should not have a lower priority than any peripherial or radio interrruption ? I tried to change the main thread priority in kconfig with an higher value than the gazell low and high priority but the callback is still not call when I am stuck in a fuction called from the main.

Best regards,

Thibaud

RE: Manage channel table with gazell pairing

ovrebekk — Wed, 08 Mar 2023 08:55:54 GMT

Hi Thibaud

[quote user="Thibaud"]Thank you for the clarification because when I read the user guide of Gazel I understood that once the device is in sync, he will follow the changement of channel of the host and not that they both will stay on one channel.[/quote]

Actually, my description has been a bit imprecise. There are actually two different channel selection modes available for the device, allowing you to control how the device will pick channels, and you can read more about this here.

The USE_SUCCESSFUL mode is the one I have described to you. In this mode you stick on the same channel as long as packet loss is low (low interference).

The USE_CURRENT will pick whatever channel the host is on when you want to send more data from the device side. This mode is good if you want to reduce latency, since the device will not wait for the host to be on the same channel for every packet.

[quote user="Thibaud"]There will be an utilisation of my product where the device could send packets to the host within a very small interval.[/quote]

Then the USE_CURRENT mode might be a good alternative.

[quote user="Thibaud"]Is there a way to force device and host to go to the 2nd channel of the table after they have been paired, so the low channel can always be free for pairing ?[/quote]

Not without changing the GZP implementation, which I wouldn't recommend.

I assume you are not planning to pair devices very often?

The pairing phase is designed to be very robust, and will re-transmit packets a large number of times in case of packet loss, so I don't think you should see poor pairing performance just because some other devices might send the occasional packet on the same channels.

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Tue, 07 Mar 2023 13:12:58 GMT

Hi ovrebekk

I am using nRF Connect SDK.

Thank you for the clarification because when I read the user guide of Gazel I understood that once the device is in sync, he will follow the changement of channel of the host and not that they both will stay on one channel.

There will be an utilisation of my product where the device could send packets to the host within a very small interval.

Is there a way to force device and host to go to the 2nd channel of the table after they have been paired, so the low channel can always be free for pairing ?

Best regards

Thibaud

RE: Manage channel table with gazell pairing

ovrebekk — Tue, 07 Mar 2023 11:30:32 GMT

Hi Thibaud

Can you confirm whether you are using the nRF5 SDK or the nRF Connect SDK?

The full user guide for the GZP library in the nRF Connect SDK can be found here.

The way Gazell works, whether you use GZP or not, is that the host will cycle through all the configured channels in sequence continuously. The device will typically synchronize to one of these channels, and wait for the host to be on the same channel before sending any more data. But if the device does not get an ACK from the host when sending data on the same channel, it will assume there is a lot of interference on this channel and try to reach the host on one of the other channels in the channel map. Once it finds some other channel where it gets an ACK it will then stick to this channel instead.

When using GZP the lowest and highest channel will be static, in order to ensure that un-paired devices will be able to communicate with the host without knowing the full channel map. Once they are connected to the host the host will share the full channel map, allowing the devices to communicate on any channel.
Since the remaining 3 channels are randomized they will not be shared between other systems in the area, and if there is a lot of interference on the low or high channel then the devices will switch to one of these channels once the pairing phase is complete.

In other words I don't expect this to be a problem if you have multiple systems in the same area.

This also depends on how often you send packets from the device side. Are you streaming data continuously, or just sending an update at a fixed interval?

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Thibaud — Mon, 06 Mar 2023 14:57:12 GMT

First of all, thank you for the fast answer and for all the clarification.

So, if I understood well, with the Gazell pairing protocol, the device and the host communicate only on one channel ? And it is the same channel that it is used to pair ?

If that, my first device and host will pair and communicate on channel 2 (the GZP_CHANNEL_LOW by default) and when I will have an other device/host product nearby, they will try to pair on channel 2 but as the channel will be occupied they will try to find an other channel.

My concern is, seems the device and the host generate their own channel table, if GZP_CHANNEL_LOW is occupied, my 2nd device/host product will go on the GZP_CHANNEL_HIGH because it will be the only one they have in common.

And if I add a 3rd device/host product they will not have any channel in common unused.

RE: Manage channel table with gazell pairing

ovrebekk — Mon, 06 Mar 2023 11:58:59 GMT

Hi Thibaud

Gazell is based on a principle called "frequency agility" rather than frequency hopping.

As opposed to Bluetooth LE for instance, which switches frequency for every connection event, Gazell will only switch channel once it detects significant packet loss. As long as packet loss is low it will stick to the same channel forever.

The advantage of this method is that if you find a part of the band which is unaffected by interference you will simply use that, rather than automatically switch to some different channel which may or may not be clear.

In the case that you have multiple products in the same area each device should eventually find a channel that is not significantly affected by the other products, and stick to that channel.

Best regards
Torbjørn

RE: Manage channel table with gazell pairing

Susheel Nuguru — Fri, 03 Mar 2023 11:55:37 GMT

Hi,

Our Gazell expert is OoO right now and will be be in office on Monday. I can request him to look into this and give more insights on your requirements.