rad1o / hackrf Goto Github PK

si5351 needs some time to fully power up before accepting commands. We should probably check for this.

Hi,

It was suggested I use your branch to get around a issue, however I've now hit another one. If I run the command:

hackrf_transfer -S4294967296 -a 1 -l 32 -s 10000000 -n3000000000 -b 9000000 -f $498000000 -g 2 -r t1.iq8

I get a filesize of: 5999996928 and the program just hangs until I hit control-c (at which point the missing 3072 bytes are transferred). This is different behaviour from the stock hackrf_transfer which will exit after doing all 3000000000 samples.

This is on linux (debian unstable) on an i7 writing to a SSD (if that makes any difference).

Thanks,

Matt

While the original HackRF is working with an Android Device and the rf-analyzer app via USB-OTG, the rad1o is not.

Commit fb219b6 ("Let the rad1o be a hack-rf on the usb for now") uses the HackRF One USB PID for rad1o. I assume that this was to make it compatible with libhackrf. Is that correct?

We think it's probably best if the two hardware variants have different PIDs so that we can handle them differently. This will make it easier for libhackrf to support rad1o hardware and for us to continue supporting libhackrf.

In order to maintain compatibility between libhackrf and rad1o, we would also like to pull the relevant changes upstream, e.g. the firmware changes for rad1o.

Does this fit with your plans?
Would you like our help with this task?

During normal use, i and q are swapped resulting in frequencies being inverted.

16:59 < ole> s: im register-default-setting muss max2871_set_rfa_en auf 0 gesetzt werden
16:59 < ole> imho funktioniert sonst die vco auto aquisition nicht
16:59 < ole> und erst danach darf man die hf einschalten

This should also be reflected upstream.

I'm trying to use my Rad1o after shamefully not using it for quite some time. Shortly after camp2015, I soldered an SMA connector onto it like described in the wiki.

Steps to reproduce

1. Select HACKRF, HKRF-OLD or HKRF-APP app
2. attach to PC
   3a. hackrf_transfer -r asdf -p1
   3b. osmocom_fft

Expected behaviour

a. File asdf contains recorded samples.
b. osmocom_fft shows noise

Actual behaviour

Operation fails with the output below.

Version information

Operating system: Manjaro Linux with kernel 5.9.16-1
The same happens with the latest build of Pentoo

hackrf_info output:

hackrf_info version: 2018.01.1
libhackrf version: 2018.01.1 (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000750865d9221f6693
Board ID Number: 3 (rad1o)
Firmware Version: git-2faa200 (API:1.00)
Part ID Number: 0xa0000a30 0x005e4355

hackrf_transfer output

call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(900000000 Hz/900.000 MHz)
call hackrf_set_antenna_enable(1)
hackrf_set_antenna_enable() failed: Pipe error (-1000)
Usage: [...]

osmocom_fft and gnuradio output

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy soapy redpitaya 
[INFO] [UHD] linux; GNU C++ version 10.2.0; Boost_107500; UHD_4.0.0.0-0-unknown
Using rad1o with firmware git-2faa200
Failed to apply antenna bias voltage state: 0 (-1000) Pipe error

someone needs to debug this :)