Transmissions aren't correct for the first few buffers

[awelkie]

I'm seeing an issue where if I transmit a signal of length less than or equal to 4 MTU, then the signal isn't actually transmitted. If I transmit a signal of length N MTU with N ≥ 5, the only the last N - 4 MTUs worth of the signal seem to be correct.

Here's my code for the transmitter. I'm using another HackRF with gqrx to verify the reception.

Here's a screenshot of the reception. Here I'm sending 7 copies of the signal. Only the last 3 actually show up. The first "signal" I believe is actually just random uninitialized memory! When I look at it in the time domain it never seems to match up with what I'm sending.

My software is Fedora 27, SoapySDR v0.6, the latest version of SoapyHackRF (commit e653dc6), and I'm using HackRF One with firmware 2017.02.1.

[guruofquality]

So theres no hardware support for the transmit receive switching in hackrf, so the switching largely based on changing usb modes when transmit data becomes available. So its not precisely timed, and its possible that this explains what you are seeing -- the switching is good enough for PTT, but with very small frames. The loss of initial packets could be due to some other firmware related implementation, turning things on, etc. You might consider padding out transmit buffers. However, I invite any driver patches (pull requests) that would automatically do this -- pad out the buffer, sleep, delay internally, whatever it takes to ensure that the writeStream API behaves as expected based on your observations/measurements.

[mossmann]

@awelkie The latest HackRF release includes transmit buffer handling improvements that I believe should fix this for you. Can you please let us know if you still have trouble with this release?
https://github.com/greatscottgadgets/hackrf/releases/latest