funcion in hackrf.c --prepare_transfers() send garbage data,because no init

[hustpigeon]

static int prepare_transfers(
hackrf_device* device,
const uint_fast8_t endpoint_address,
libusb_transfer_cb_fn callback)
{
int error;
uint32_t transfer_index;
if( device->transfers != NULL )
{
for(transfer_index=0; transfer_index<TRANSFER_COUNT; transfer_index++)
{
device->transfers[transfer_index]->endpoint = endpoint_address;
device->transfers[transfer_index]->callback = callback;

// I think this line will send a garbage data, beacuase, device->transfers[transfer_index])->buffer didn't init， and no where fill it's value.?????????? am i right
e# rror = libusb_submit_transfer(device->transfers[transfer_index]);----this line

		if( error != 0 )
		{
			last_libusb_error = error;
			return HACKRF_ERROR_LIBUSB;
		}
	}
	return HACKRF_SUCCESS;
} else {
	// This shouldn't happen.
	return HACKRF_ERROR_OTHER;
}

}

[Hoernchen]

Are you talking about TX?

[hustpigeon]

yes, please help me , thanks @Hoernchen

[Hoernchen]

As far as I can see this could be fixed by initializing the transfer buffer with 0, which would lead to a short delay when sending data depending on buffer size and number of buffers instead of sending random garbage, or by changing the way tx works by manually submitting TRANSFER_COUNT buffers before relying upon the callback function. Since no one complained about this for the past few years the first solution sounds like a reasonable fix...

[hustpigeon]

@Hoernchen thanks again!!! I found many example code like this，i doubt am i wrong?

here is anthor example

[Hoernchen]

I don't really feel like googling for random slides you found somewhere, but my guess is that those slides talk about receiving data, in which case the buffers are filed the device.

[dominicgs]

We already zero the transfer buffers when we allocate them : https://github.com/mossmann/hackrf/blob/master/host/libhackrf/src/hackrf.c#L210

[hustpigeon]

@dominicgs no, you didn't, i mean buffer "device->buffer[transfer_index * TRANSFER_BUFFER_SIZE]", not transfer https://github.com/mossmann/hackrf/blob/5e9cad66363467fae93aec29679c041c03905047/host/libhackrf/src/hackrf.c#L228

[hustpigeon]

@Hoernchen may be

[Hoernchen]

@hustpigeon is right, struct hackrf_device which contains the buffers is malloced, not calloced in hackrf_open so the buffers are not initialized, unless I'm somehow unable to find a hidden memset.

[dominicgs]

Ah, sorry @hustpigeon you're right.

Changing this malloc() to a calloc() should do it: https://github.com/mossmann/hackrf/blob/5e9cad66363467fae93aec29679c041c03905047/host/libhackrf/src/hackrf.c#L558

[hustpigeon]

@dominicgs @Hoernchen thank you, thank you very much , you are so kind and nice!

[hustpigeon]

@dominicgs @Hoernchen
In fact initializing is not important, the true problem is that when you want to start a transfer (from host to device), the first transfer always has no usefull data( random datas or all zero datas).,and you have no where to fill your application data into the first transfer. you can only fill data into the second transfer and after in callback function tx_callback()..

when you call function below, you have no chance to fill data into the first transfer, ,because first tranfer had submitted before tx_callback(), you have no chance to do with first transfer.
hackrf_start_tx(device, tx_callback, NULL);

so ,the first tranfer always has no usage whatever you initialize or not.

[Hoernchen]

This is precisely what I was getting at above, and it's actually the 5th transfer that contains useful data, as soon as you get your cb, the other 3 transfers are still in flight. This only happens once, and timing is unpredictable anyway, due to the lack of timestamps/usb/....

[hustpigeon]

@Hoernchen ^_^ haha, you are right , It's actually the 5th， because the array has 4 transfer buffer!

that say, the next round , the data in transfer has meaning! My means is the same as you! the Second Transfer is the same index of Buffer arry. That to say, totally 4 transfer has garbage data!

thank you !

[mossmann]

Ah, sorry @hustpigeon you're right.

Changing this malloc() to a calloc() should do it:

https://github.com/mossmann/hackrf/blob/5e9cad66363467fae93aec29679c041c03905047/host/libhackrf/src/hackrf.c#L558

This was done in #805.

[mossmann]

While zeroing the buffer may not be the most ideal solution, it is the best we can do without implementing timed transfers (see #85).