Edouard Griffiths

Stopping the device using its API (of some sort) is not a guarantee that there will be no RF leak either. I have to check again this but I think...

If a switch off action is not available in the hardware API another possibility is to shift the LO away enough to fall outside the bandwidth of the filter that...

Replying to myself... > The Tx chain is not designed for the channels to take action on the transmitting device In fact this should be possible since channels have access...

This is not working because if Tx is stopped then no samples are pulled anymore and there is no way to start the Tx again. Unless the hardware has the...

A new interface could be provided and not implemented by default that enables/disables RF without stopping the Tx. For example `libhackrf` gives access to the MAX2837 RF device registers so...

Evenn If you go through API you still have the issue of stopping the thread. The point is that the Tx thead cannot be stopped. I ve made some experiments...

> I'm assuming there aren't any other channels active in this scenario Indeed! Let's make it simple and assume it is a limitation known to the user. Mixing Tx channels...

I've experimented with the HackRF at various sample rates to conclude that it is not possible to control the transmit window from software. The delay and its variation depending on...

For 802.15.4 Rx/Tx I think the best option is to use a MIMO device so that Rx and Tx can run concurrently. Some devices like the BladeRF have the option...

For the first bullet this is very unlikely to happen and not worth a mutex. For the middle bullet the solution is to return ~~204~~202 that just says the messages...