While reviewing ADAR1000_Manager.cpp, I noticed that several low-level SPI/ADC operations detect failures only through DIAG_ERR logs, but the calling flow often continues as if everything succeeded.
Right now, helpers such as adarWrite(), adarRead(), adarSetBit(), adarSetTxPhase(), adarSetRxPhase(), and adarAdcRead() don’t consistently propagate an explicit success/failure result. This can let higher-level logic (init, mode switching, beam updates) move forward and update software state even when the actual ADAR1000 transaction failed on hardware.
In practice, this can lead to configured TX/RX/beam states in software that may not match the real RF state when SPI communication is unstable.
I’d be happy to work on this and open a PR.
While reviewing ADAR1000_Manager.cpp, I noticed that several low-level SPI/ADC operations detect failures only through DIAG_ERR logs, but the calling flow often continues as if everything succeeded.
Right now, helpers such as adarWrite(), adarRead(), adarSetBit(), adarSetTxPhase(), adarSetRxPhase(), and adarAdcRead() don’t consistently propagate an explicit success/failure result. This can let higher-level logic (init, mode switching, beam updates) move forward and update software state even when the actual ADAR1000 transaction failed on hardware.
In practice, this can lead to configured TX/RX/beam states in software that may not match the real RF state when SPI communication is unstable.
I’d be happy to work on this and open a PR.