Ranging quality is NOT OK after a while

Hi,

I have been making a sequential channel sounding program. I tried very hard to get rid of memory leaks and now the program is able to sequentially range with three reflectors and send the readings through GATT to another device. The issue is, after a hundred rounds of ranging, the initiator starts displaying "ranging quality is NOT OK". At the start everything is fine, all the distance readings are coming out fine, and every time I reboot it it is fine at the start as well. I am not sure what issue I am running into now, especially since the devices are still able to connect and disconnect without any issues. Perhaps it is another memory leak? But why would that affect the data quality? Any help is appreciated thanks!

Sincerely, 

Triscuit

Parents
  • Hi,

    I assume this is based on the nRF/ nordic channel sounding samples, that you are using SDC, and nRF54L15DKs? What NCS version are you using? And by doing it sequentially, you connect and disconnect from one node at the time?

    Regards,

    Elfving

  • Hi,

    Yes I am using the channel sounding with ras samples. I am using 54l15 dk's and VCS version 3.0.99. By sequentially it is connecting and disconnecting from one node at the time. I am just not sure how data quality would be affected? Maybe because the device is now using more memory as it should so it does not have enough resources to dedicate to the ranging?

    This brings me to another point. Right now I implemented a GATT messaging system where after the initiator ranges it would send the readings to my laptop via Bluetooth GATT, and the laptop would calculate the trilateration results. However, I noticed that when it sends the readings wirelessly as well as range at the same time, the distance at which it can range decreases, going from over 20m to not even 10m. Would this be because the device is holding two concurrent connections, making it split its radio, resulting in worse readings? Or would this just be a software bug?

    Thank you.

    Sincerely,

    Triscuit

  • Triscuit said:
    By sequentially it is connecting and disconnecting from one node at the time. I am just not sure how data quality would be affected?

    No, me neither. The sequential way is what we currently recommend as well, though I guess what you say about RAM resources could make sense. 

    Triscuit said:
    Right now I implemented a GATT messaging system where after the initiator ranges it would send the readings to my laptop via Bluetooth GATT, and the laptop would calculate the trilateration results. However, I noticed that when it sends the readings wirelessly as well as range at the same time, the distance at which it can range decreases, going from over 20m to not even 10m. Would this be because the device is holding two concurrent connections, making it split its radio, resulting in worse readings? Or would this just be a software bug?

    Ah so one reason why we recommend doing this sequentially is to avoid multiple connections potentially colliding, as we haven't yet optimized the SDC to avoid this for channel sounding. So even though you do things correctly by having the CS connections sequentially, it could be best if you did the GATT messaging in a timeslot of its own as well. Although I am surprised that this would result in just a worse range/ readings.

    Is this project something heavily modified, or essentially the default samples with a few additions? I guess it could be a bug, but I wouldn't expect any in the default samples.

    ranging quality is NOT OK

    Btw, I am not immediately seeing where this could be coming from in the initiator. This isn't your own error message, right?

    Regards,

    Elfving

  • Hi Elfving. This project I would say is very heavily modified, since I have been working on this for the past few months. I took the original sample and added a lot onto it, but the CS connection and ranging procedure are pretty much the same as the original. Oh Sorry, I think 'ranging quality is NOT OK' is my own message, it is just in an else statement for when the CS_DE_QUALITY_OK is false in the ranging_data_cb function. Another question I have is, if I were to reverse the devices and use three initiators connect to one reflector, would that make concurrent channel sounding possible? Because right now I am using three reflectors and one initiator. Is the initiator doing more work by starting it or would it be the same since the reflector also has to hold a stable connection? And sometimes when it is ranging it says parsing empty step data, is there any way to reduce or stop this? Thank you so much.

    Sincerely,

    Triscuit

Reply
  • Hi Elfving. This project I would say is very heavily modified, since I have been working on this for the past few months. I took the original sample and added a lot onto it, but the CS connection and ranging procedure are pretty much the same as the original. Oh Sorry, I think 'ranging quality is NOT OK' is my own message, it is just in an else statement for when the CS_DE_QUALITY_OK is false in the ranging_data_cb function. Another question I have is, if I were to reverse the devices and use three initiators connect to one reflector, would that make concurrent channel sounding possible? Because right now I am using three reflectors and one initiator. Is the initiator doing more work by starting it or would it be the same since the reflector also has to hold a stable connection? And sometimes when it is ranging it says parsing empty step data, is there any way to reduce or stop this? Thank you so much.

    Sincerely,

    Triscuit

Children
  • I see. Well CS_DE_QUALITY_OK being false would mean that the sample is discardable, my coworker expands a bit on this here as well. My first thought is that this would be due other external factors, like rf noise or objects being in the way. Though if you do not think that is applicable, and if it happens after the same amount of time every time then it does sound like a bug, eg. a memory leak. It is still a bit strange to me that it would impact the range as well though.

    Could you try lowering the memory, and see if that makes the issue happen even sooner?

    Regards,

    Elfving

Related