Question regarding the direct mode buffer

[Crsarmv7l]

Please ignore the disjointed nature of this post, I am not quite sure exactly how to get at what I am looking for but figured you guys might have some ideas.

While working on my project which uses direct mode, I have noticed that I get a lot of blank signals "00000" etc when using carriersense with promiscuous no syncword and direct mode (actual signals are also coming through with my test remote so all good this is just about efficiency). So I passed bytes from read() to a buffer I created, then check the entirety of the signal to see if it is all blank discarding and resetting my buffer if it is.

I still get some noise eg "FFFFFFF" etc but I no longer get blanks so it cuts down on the displayed undesired noise substantially. The inefficiency I can see is there was already a buffer that could have been parsed that I have now recreated taking both time and memory.

Do I need god mode to interact directly with the direct mode buffer in Physical Layer? Any concepts to make this more efficient?

I am currently looking at read() and available() to see if there is some way I can discard blank buffers there before it hits the end user (shouldn't be any issues with that as even a single bit would no longer be a blank buffer and would be returned)

[Crsarmv7l]

I am thinking something like this. What do you think.

uint8_t PhysicalLayer::read(bool drop) {
  int flag = 0;
  if(drop) {
    dropSync();
  }
  for (int i=0; i < this->bufferWritePos; i++) {
    if(this->buffer[i] > 0) {
      flag = 1;
      break;
    }
  }
  if (flag == 1) {
    this->bufferWritePos--;
    return(this->buffer[this->bufferReadPos++]);
  }
  else {
      this->bufferWritePos=0;
      this->bufferReadPos=0;
    return(0);
  }
}

[Crsarmv7l]

Gah, the above wont work because it would still return 0 before breaking the while radio.available() loop. It would also check for empty signals each time around the while radio.available loop although the break helps that.

See what I mean about not quite being able to get to the result?

[Crsarmv7l]

Disregard. Figured out my issue with empty signals. User error. Still going to have to copy to a temp buffer to do other decoder work.

[jgromes]

Do I need god mode to interact directly with the direct mode buffer in Physical Layer?

At the moment yes, it's not really meant to be interfaced with directly. The main issue I see is that PhysicalLayer::buffer is being added to bit-wise. So you would have to be very careful to not touch that byte at PhysicalLayer::bufferWritePos since it can still be modified. Though this could be resolved in RadioLib by using a single byte as the "working buffer", and only copying it to the main buffer after it is complete. The it could be safe(r) to give users a way to access the buffer, e.g. uint8_t* PhysicalLayer::getDirectBuffer(void);.

Actually, looking at the implementation now, it's a bit dodgy - PhysicalLayer::buffer is being written to from an interrupt, but it's not declared as volatile .... I will have to take a look at that.

[Crsarmv7l]

I gotcha, the bufferWritePos position is still being actively written to so reading that byte could give wrong info.

If I understand you correctly, you are contemplating pin reads to a single byte, then once the byte is complete adding the byte to the buffer. That way reading the buffer directly would be established information.

Sounds like a good idea to me, and would be very helpful when I start writing the decoders. That is still a bit off for my project since I just got RX and the serial UI working how I want. Need to get the TX piece dialed in before I get to decoding signals.

I need to start looking into direct mode tx. I did a bit of looking here in the discussions, but most of what I found was a bit old.