Closed smileyrekiere closed 5 months ago
The difference lies in the data types.
Vector Source generates data with a complex
output type (as seen in the first screenshot). This format uses 32-bit floating-point numbers (2 per sample). This is common among GNURadio blocks.
Now, HackRF operates with 8-bit signed integers. The sink in your flowgraph converts between the two formats before sending the samples to the device.
However, when you save the complex
samples to a file and then provide it to hackrf_transfer
, there is a missing conversion step.
A simple solution would be to convert the samples using the Complex to IChar
block before storing them in a file. You might also want to adjust its scale factor to 127.
Thank-you, and appreciate the scale factor comment.
What would you like to know?
O.k. have a simple vector that is saved to a file Was hoping that 2 samples at 1 would look like a single pulse as compared to two pulses![image](https://github.com/greatscottgadgets/hackrf/assets/67471545/23b50dd9-4e0a-487a-b7fe-58057d069420)
Using hackrf_transfer ( hackrf_transfer -d 22276763 -t /home/user/git/x64_btbits/server/three_pulses.bin -f 5300000000 -x 47 -s 2000000)
the pulse looks like![image](https://github.com/greatscottgadgets/hackrf/assets/67471545/d5a2a910-4294-4c03-a9a0-70cbfb48635a)
When doing though GNU radio companion (with hackrf)and transmit the pulse looks like
Is there someting that needs to be done to the output of the Vector Source to allow the two samples do not have the dip between them and look like a single pulse as it transmitted with gnu radio companion? Is there a switch setting missing in hackrf_transfer?
Host at 2023 and hackrf_info at the following hackrf_info version: git-13765055 libhackrf version: git-13765055 (0.8) Found HackRF Index: 0 Serial number: 000000000000000057b068dc22276763 Board ID Number: 2 (HackRF One) Firmware Version: 2023.01.1 (API:1.07) Part ID Number: 0xa000cb3c 0x00644754 Hardware Revision: older than r6 Hardware supported by installed firmware: HackRF One