Not calling getTargetState() between getSpeed() calls yields useless data

[adriaanb]

To avoid blocking delays, I set up my code to call getSpeed() using a non-blocking alternative (millis()).

As the library implements getTargetState() using delays (#3), I want to call it as rarely as possible for now.

Not calling getTargetState() at least once in between every getSpeed() call makes the data returned by getSpeed() not usable. Readings are heavily delayed, often the data is erroneous or not usable. If calling getSpeed() every 300 ms to avoid redundant readings, the issue is compounded by #5.

This is a brief code example meant to reproduce the behavior (tested on Arduino Nano 33 IoT):

#include <BGT24LTR11.h>

BGT24LTR11<Uart> radar;

int execInterval = 150; 
unsigned long runTime, prevTime = 0;

void setup() {
  Serial.begin(9600);
  Serial1.begin(115200);
  radar.init(Serial1);
  while (!Serial);
  while (!Serial1);
  while (!radar.setMode(0)); 
}

void loop() {
  runTime = millis();
  if ((unsigned long)(runTime - prevTime) >= execInterval) {
    Serial.println(radar.getSpeed());
    // The behaviour ceases if the following line is commented in:
    // radar.getTargetState(); 
    prevTime = runTime;
    }
}

[x29a]

@adriaanb thanks for your investigations. What value should getSpeed() return in the case that the target state is 0 (no target)? So i assumed that one has to call getTargetState() anyway and then only read the speed if its 1 or 2.

I also see sometimes target states above 2, on ESP8266 using EspSoftwareSerial, did you ever notice that as well? Not sure if from the sensor or during transmission.

Also, the communication works for me just as fine when removing the delay(20) from getTargetState(), can you confirm?

[x29a]

my PR #10 mitigates the data consistency issues for me.

an even better approach would be to do the reading for target state and speed in one call (since its the same command) and keep the values internally.

also, the module periodically sends the values in target detection mode, so there is no need to call the functions over and over again, just using the last correctly transmitted values should be just fine.

[x29a]

btw the single call for information was implemented with #13 - this way you can distinguish between "call failed", which is return value 0 and "no target detected" which sets target state to 0.

[Lesords]

Hello,

I'm very sorry to have kept you waiting so long.

Do you still have this problem now?

[x29a]

Hey, thanks for following up on this!

Im good with the set of changes that i proposed/got merged, but maybe its a good time to release a new version with them for easy usage in other projects?

[Lesords]

Ok, I'll post a release as soon as possible.

[Lesords]

The latest version has been released.

I'm going to close this issue, feel free to re-open it if you have any other questions.