hackrf_sweep sometimes doesn't output result #1052
Comments
|
I suggest trying again with current git master versions of the firmware & host code. I recently fixed several intermittent start/stop problems in PR #1029. |
|
Tested on Linux, where I didn't manage to reproduce the problem, even after 101018 iterations of Used to have full logs with timing info saved in case the issue appears. These tests were done with Preparing some Darwin tests. |
|
Found the problem. Sometimes the buffer that Have to go now, so can't analyse further at the moment, but attaching a couple of raw blocks. |
|
@metayan it's possible this is the result of the RX buffer overrunning because the host isn't retrieving the data quickly enough. If you run |
|
Thanks for the On Darwin |
|
With some logging added in for(j=0; j<BLOCKS_PER_TRANSFER; j++) {
fprintf(stderr, "rx_callback block %d\n", j);
ubuf = (uint8_t*) buf;
int b;
for (b=0; b<16; b++) fprintf(stderr, "%02X ", ubuf[b]);
fprintf(stderr, "\n");
for (b=BYTES_PER_BLOCK-512; b<BYTES_PER_BLOCK-512+16; b++) fprintf(stderr, "%02X ", ubuf[b]);
fprintf(stderr, "\n");
fflush(stderr);
if(ubuf[0] == 0x7F && ubuf[1] == 0x7F) {
fprintf(stderr, "rx_callback if ubuf[0]\n");
frequency = ((uint64_t)(ubuf[9]) << 56) | ((uint64_t)(ubuf[8]) << 48) | ((uint64_t)(ubuf[7]) << 40)
| ((uint64_t)(ubuf[6]) << 32) | ((uint64_t)(ubuf[5]) << 24) | ((uint64_t)(ubuf[4]) << 16)
| ((uint64_t)(ubuf[3]) << 8) | ubuf[2];
} else {
fprintf(stderr, "rx_callback if ubuf[0] else continue\n");
buf += BYTES_PER_BLOCK;
continue;
}I get and The full log: |
|
Hi @metayan, I'm very confused by all this, but here's some thoughts I have:
|
|
@miek has pointed out that this bug came up previously:
Looking at the fix, I suspect now that I broke this in #1045. |
|
I find it a bit strange that the offset persists across invocations of Just so you know, I did get shortfalls when printing the whole buffer - I guess it took way too long. |
Ah, I was wrong about the current sweep code guarantees. It doesn't guarantee no shortfalls, but it should guarantee that if shortfalls happen, they won't result in lost or corrupted data (which could happen before #982). When the host is too slow to process the data, the buffer will fill up, resulting in shortfalls as you saw when you were printing out the buffer contents. The only effect of those shortfalls should be on timing, though. The firmware should just wait for there to be buffer space, before continuing with RX. At the moment, #1045 looks like a possible culprit because it touches some of the same code as #702, but it's still not clear what the actual problem with it is. There was a mystery on that PR though that makes me extra suspicious: why we still needed the If you're up for more testing, it might be interesting to test |
|
Oh, interesting. So this dates back to before all the relevant work I've done recently. I guess the next question is: did it work correctly immediately after #702 was merged? If so, then we should be able to bisect from there to find where it broke. And if not, then there was always some other way for this to happen, which wasn't fixed by that change. |
martinling
added
bug
and removed
technical support
|
OK, seems like this isn't a regression then, but something that wasn't fixed by #702 in the first place. We'd really like to get a low level USB capture of this happening. Could you share the details of the Darwin system you're testing on - i.e. model and MacOS version? It's very odd that this seems to be host-dependent. |
|
Using macOS Darwin 10.15.7 I'm pretty certain that I have also encountered this issue on Linux - on devuan running on a Raspberry PI4, but that was quite a long time ago. There is some weirdness on Darwin during closing that I have just filed as issue #1079 . |
|
This seems like it could be related - from your debug output on #1079: |
|
I'm looking into finding a system to reproduce this on so that we can capture what's happening on the wire. I'd be very interested if the missing 512 bytes can be reproduced on something other than MacOS. Just seeing
The OP was running the 2021.03.1 release, and we fixed several other things that could have caused this symptom since then. We had a lot of |
|
The fact that this 'no output' issue persists over I have been tweaking the Darwin I can build any firmware and host software needed and test on both Linux and Darwin. |
On Darwin libusb calls This sends a According to the USB spec (sections 8.5.2 and 9.4.5), the data toggle should be initialized to DATA0 in two conditions: at configuration and when handling I think we need to add handling of |
|
We've reproduced this just now on a The change in #1081 failed to fix it, and hung things worse. I have a capture of that happening too. The captures are big, so I'll need to dig through and extract the interesting parts before posting here. |
Version information
Operating system:
hackrf_info output:
Output
hackrf_sweepsometimes outputs results, and sometimes it doesn't:Hardware issue or something else?
Cheers!
The text was updated successfully, but these errors were encountered: