Re: [Hackrf-dev] How to tell if antenna is faulty

2019-01-30 Thread Gavin Jacobs 
Cliff,
I have a hackrf and an Ant500. With the antenna fully extended, you should 
measure a very low resistance between the tip of the antenna and the center pin 
of the connector. Mine was about 2 ohms. If you have 75 ohms, then there is a 
problem. Try again between the center pin and the elbow (where the extensions 
start) - it should be very low < 1 ohm.

You should be able to use GQRX to receive an FM radio station, with almost any 
antenna. Most common rookie mistake is forgetting to turn up the IF gain.

Tell us more about your setup and we can help you get started.

Jake


From: HackRF-dev  on behalf of cliff 
palmer 
Sent: January 30, 2019 3:15 PM
To: hackrf-dev@greatscottgadgets.com
Subject: [Hackrf-dev] How to tell if antenna is faulty

I have a Hackrf One with an Ant500 Antenna and I am having no luck with 
multiple tutorials found on YouTube, including the ones at Great Scott Gadgets. 
 I measured the resistance on the (disconnected but fully extended) Ant500 
Antenna using a multimeter (one lead on the metal part of the antenna and the 
other on the male lead in the connector.  The multi-meter measured up to 75 Ohm 
resistance.
I'm really new to SDR and so I don't know if resistance should concern me, but 
it seems like an antenna should not have resistance.
I would appreciate some advice about how to determine if this is really a 
problem (and the antenna is faulty) or if I am making a typical new-to-SDR 
mistake.
Thanks
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Hackrf-dev] Hackrf One output impedance

2018-09-21 Thread Gavin Jacobs 
What is the output impedance when transmitting at 147.42 MHz with and without 
the output amplifier?

I’ve built an RF amplifier to boost the output about 26 dB, but with no signal 
it oscillates. The data sheet suggests it is probably due to an impedance 
mismatch between the Hackrf and the amp. So, can anyone say definitely the 
impedance of the Hackrf?

Thanks,
Jake
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Still hoping for PTT

2018-06-26 Thread Gavin Jacobs 
Dominic
Thanks for that offer/suggestion, but it’s already done! I found the TX mode 
signal that drives the TX LED, and it was already brought out to P5. So All I 
had to do was solder some ribbon cable to P5 socket (which is not populated). I 
have it connected to my power amp such that it energizes whenever the Hackrf is 
in transmit mode.

Jake


On Jun 26, 2018, at 10:59 AM, Dominic Spill 
mailto:domini...@gmail.com>> wrote:

I'm not certain, because I don't want to break portapack or other add on 
boards, but it may be possible for us to toggle a GPIO pin on one of the 
headers when we switch to TX mode, if that would help?

Dominic

On 20 June 2018 at 17:55, Gavin Jacobs 
mailto:apriljunk...@hotmail.com>> wrote:
Chuck,
I have used the bias-t voltage on the hackrf to power an upconverter but it 
isn’t easy to turn it on and off. The only method I know is to use 
hackrf-transfer - but that doesn’t work when switching to/from rx & tx.

Meanwhile I have brought the tx LED signal out from P5, and it is switching the 
power amp on and off just fine.

Jake

On Jun 19, 2018, at 7:02 PM, Chuck McManis 
mailto:chuck.mcma...@gmail.com>> wrote:

FWIW the idiomatic way to achieve this as far as I can tell is to send a bias-T 
signal on the RF cable, basically its a DC offset on the cable which the PA 
picks up and switches on. This lets you have short cables between the PA and 
the antenna and its only one line to hook up (the antenna coax)

On Tue, Jun 19, 2018 at 5:04 PM Gavin Jacobs 
mailto:apriljunk...@hotmail.com>> wrote:
Bernie
That’s a great idea! I looked on the hackrf schematic and the signal for the TX 
LED is brought out to a (DNP) header - all I have todo is bring that signal out 
to my PTT circuit. Thanks for the suggestion!

Jake


On Jun 15, 2018, at 5:32 AM, Bernard Kobier 
mailto:bernardkob...@tpg.com.au>> wrote:

I admit I have not tried this but what about using the TX LED to drive an 
optocoupler to switch the amp?

Bernie



On 11 Jun 2018, at 00:53, CJ Hicks 
mailto:cjhi...@dadelus-engineering.com>> wrote:

Why not leave your exciter on and only PTT your power amplifier (PA)?  Or use 
an RF to shunt your exciter signal into a dummy load.  Just a couple of random 
thoughts.

CJH

From: HackRF-dev [mailto:hackrf-dev-boun...@greatscottgadgets.com] On Behalf Of 
Gavin Jacobs
Sent: Saturday, June 09, 2018 5:57 PM
To: hackrf-dev@greatscottgadgets.com<mailto:hackrf-dev@greatscottgadgets.com>
Subject: [Hackrf-dev] Still hoping for PTT

Has there been any progress on implementing digital i/o from/to the hackrf One. 
I'm hoping that someday the hackrf can supply a PTT signal to an external 
amplifier.

Jake

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev


___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Hack RF TX/RX switching

2018-06-21 Thread Gavin Jacobs 
Dana,
For applications which require switching rx/tx, I use gnuradio, osmocom 
source/sink blocks, and the soapysdr-hackrf driver. As far as I know, this is 
the only combination that can switch rx/tx on the fly.

For 2m use, I have a homebrew power amp to boost the hackrf tx output, but I 
only want the power amp enabled when I am transmitting. I took the cover off 
the hackrf and soldered a 6 conductor ribbon cable to the unpopulated socket 
P5. You can see on the hackrf schematic that P5 has signal LED3 on pin 6 and 
GND on pin 1. LED3 is the same signal that drives the TX LED. It is 0V when the 
LED is off (rx mode) and 3.3V when the LED is on (tx mode). I then wired LED3 & 
to an input on my antenna controller (which is a PIC 18F2550). I put some logic 
in the firmware of the antenna controller such that when the hackrf is in tx, 
and the antenna controller is connected to the 2m yagi, and I have enabled what 
I call Pass-Through, then the antenna controller drives an output with a 2n3904 
npn transistor to put the the power amp also in tx mode. So, I didn't use an 
opto as suggested by Bernie; I just directly tapped the signal that drives the 
tx LED.

I don't have a schematic of the connection to P5, it's just GND and LED3 wired 
directly to a GPIO pin on the PIC controller.

Hope that helps!

Jake


From: Dana Shtun 
Sent: June 21, 2018 8:01 AM
To: Gavin Jacobs
Subject: Hack RF TX/RX switching

Gavin
Can you share your circuit? I’m in the same situation here re switching…
ie. anything special re opto? Is there enough current for the LED and to drive 
switching?

Also what software are you using?

Thx
Dana VE3DS
Toronto
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Still hoping for PTT

2018-06-20 Thread Gavin Jacobs 
Chuck,
I have used the bias-t voltage on the hackrf to power an upconverter but it 
isn’t easy to turn it on and off. The only method I know is to use 
hackrf-transfer - but that doesn’t work when switching to/from rx & tx.

Meanwhile I have brought the tx LED signal out from P5, and it is switching the 
power amp on and off just fine.

Jake

On Jun 19, 2018, at 7:02 PM, Chuck McManis 
mailto:chuck.mcma...@gmail.com>> wrote:

FWIW the idiomatic way to achieve this as far as I can tell is to send a bias-T 
signal on the RF cable, basically its a DC offset on the cable which the PA 
picks up and switches on. This lets you have short cables between the PA and 
the antenna and its only one line to hook up (the antenna coax)

On Tue, Jun 19, 2018 at 5:04 PM Gavin Jacobs 
mailto:apriljunk...@hotmail.com>> wrote:
Bernie
That’s a great idea! I looked on the hackrf schematic and the signal for the TX 
LED is brought out to a (DNP) header - all I have todo is bring that signal out 
to my PTT circuit. Thanks for the suggestion!

Jake


On Jun 15, 2018, at 5:32 AM, Bernard Kobier 
mailto:bernardkob...@tpg.com.au>> wrote:

I admit I have not tried this but what about using the TX LED to drive an 
optocoupler to switch the amp?

Bernie



On 11 Jun 2018, at 00:53, CJ Hicks 
mailto:cjhi...@dadelus-engineering.com>> wrote:

Why not leave your exciter on and only PTT your power amplifier (PA)?  Or use 
an RF to shunt your exciter signal into a dummy load.  Just a couple of random 
thoughts.

CJH

From: HackRF-dev [mailto:hackrf-dev-boun...@greatscottgadgets.com] On Behalf Of 
Gavin Jacobs
Sent: Saturday, June 09, 2018 5:57 PM
To: hackrf-dev@greatscottgadgets.com<mailto:hackrf-dev@greatscottgadgets.com>
Subject: [Hackrf-dev] Still hoping for PTT

Has there been any progress on implementing digital i/o from/to the hackrf One. 
I'm hoping that someday the hackrf can supply a PTT signal to an external 
amplifier.

Jake

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Still hoping for PTT

2018-06-19 Thread Gavin Jacobs 
Bernie
That’s a great idea! I looked on the hackrf schematic and the signal for the TX 
LED is brought out to a (DNP) header - all I have todo is bring that signal out 
to my PTT circuit. Thanks for the suggestion!

Jake


On Jun 15, 2018, at 5:32 AM, Bernard Kobier 
mailto:bernardkob...@tpg.com.au>> wrote:

I admit I have not tried this but what about using the TX LED to drive an 
optocoupler to switch the amp?

Bernie



On 11 Jun 2018, at 00:53, CJ Hicks 
mailto:cjhi...@dadelus-engineering.com>> wrote:

Why not leave your exciter on and only PTT your power amplifier (PA)?  Or use 
an RF to shunt your exciter signal into a dummy load.  Just a couple of random 
thoughts.

CJH

From: HackRF-dev [mailto:hackrf-dev-boun...@greatscottgadgets.com] On Behalf Of 
Gavin Jacobs
Sent: Saturday, June 09, 2018 5:57 PM
To: hackrf-dev@greatscottgadgets.com<mailto:hackrf-dev@greatscottgadgets.com>
Subject: [Hackrf-dev] Still hoping for PTT

Has there been any progress on implementing digital i/o from/to the hackrf One. 
I'm hoping that someday the hackrf can supply a PTT signal to an external 
amplifier.

Jake

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com<mailto:HackRF-dev@greatscottgadgets.com>
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Hackrf1 with gnuradio 3.7.11 win64.msi

2018-06-12 Thread Gavin Jacobs 

Dominic Spill
The windows msi package for 3.7.11 includes rtl and hackrf drivers in 
gr-osmosdr, so it should work.

jf.devois,

Here are some suggestions to narrow down the problem.

In Windows, start a Command window and navigate to:
C:\Program Files\GNURadio-3.7\bin

Then type this command:
rtl_test

You should see something like this:
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 5201
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 
19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 
48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

If you see the above, then you will have to type ^C to stop rtl_test.
BUT if you get an error message, then you will probably have to run the ZADIG 
program to updage the USB driver. Here is the link: https://zadig.akeo.ie/ Once 
you have done that, you can proceed with the next test.


Zadig - USB driver installation made easy
Zadig is a Windows application that installs generic USB drivers, such as 
WinUSB, libusb-win32/libusb0.sys or libusbK, to help you access USB devices.. 
It can be especially useful for cases where:
zadig.akeo.ie


In the same Command window you used above, type this command:
hackrf_info

You should get something like this:
hackrf_info version: 2017.02.1
libhackrf version: 2017.02.1 (0.5)
Found HackRF
Index: 0
Serial number: xxx
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: xxx

If that works, then gnuradio companion should also work.

Hope that helps,
Jake




From: HackRF-dev  on behalf of 
jf.dev...@gmail.com 
Sent: June 12, 2018 1:11 PM
To: Dominic Spill
Cc: hackrf-dev
Subject: Re: [Hackrf-dev] Hackrf1 with gnuradio 3.7.11 win64.msi




jf.dev...@gmail.com

From: Dominic Spill
Date: 2018-06-12 18:17
To: jf.dev...@gmail.com
CC: hackrf-dev
Subject: Re: [Hackrf-dev] Hackrf1 with gnuradio 3.7.11 win64.msi
On 12 June 2018 at 04:12, jf.dev...@gmail.com 
mailto:jf.dev...@gmail.com>> wrote:
>
> I'm a french physics teacher not a computer expert
> I use hackRf1 with grc  on a  Pentoo  Linux   USB stick boot  with my 
> students in electronics  since 2 years to measure emission reception levels
> with an hackrf1 for emission and a DBTV  USB stick for reception   both on 
> the same computer
> (I have been unable to install GRC  under a Linux system otherwise)
>
> I now try to use GRC/HackRF1   under Windows 7 ( which is my usual computer 
> system)
> The new .msi   gnuradio windows installation   3.7.11   works   in my 
> computer   under windows 7

Where did the .msi file come from?  could you give us a link to the download?

> GRC works without using external  sources and sinks
> But   it doesn't   works   with Hackrf1  (osmocom source)it creates a 
> python.exe  bug
>
> I tried with  the  DBTV  USB stickrtlsdr source :  grc doesn't   
> communicate with the usb  ( null source instead)
>
> Do I need a pilot or something else  to run  osmocom and   rtlsdr sources  
> with GRC  under windows 7?

I suspect this is because while the .msi contained GNU Radio, GRC, and 
gr-osmosdr, it doesn't include the libraries required for using HackRF or the 
RTL-SDR devices that gr-osmosdr uses.

I don't have much experience of using them, but I've heard good things about 
the binary packages hosted here: http://downloads.myriadrf.org/builds/PothosSDR/

Thanks,
  Dominic

Thank you for your answer
I tried to run GRC from the Pothos  installation but GRC is unable to find my 
Python 2.7 already installed
I'll tried to reinstall  Python 2.7

Sincerely
JF Devois

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  Garanti sans virus. 
www.avast.com
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Hackrf-dev] Still hoping for PTT

2018-06-09 Thread Gavin Jacobs 
Has there been any progress on implementing digital i/o from/to the hackrf One. 
I'm hoping that someday the hackrf can supply a PTT signal to an external 
amplifier.

Jake

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] HackRF and Spyverter

2018-04-25 Thread Gavin Jacobs 
Alejandro,
The Spyverter will shift the 457kHz signal up by 120 MHz, so the result will be 
120.457 MHz. Connect your 457kHz signal to the input of the Spyverter; connect 
the output of the Spyverter to the rf input of the hackrf. Remember to apply 
5Vdc to the Spyverter (make sure you use a linear power supply, or a battery 
pack, because a switch mode supply will be very noisy). You can use gnuradio 
companion (or numerous other programs) to show the spectrum.

Jake


From: HackRF-dev  on behalf of 
ALEJANDRO RAMIRO MUNOZ <100314...@alumnos.uc3m.es>
Sent: April 25, 2018 2:36 PM
To: hackrf-dev@greatscottgadgets.com
Subject: [Hackrf-dev] HackRF and Spyverter

Hey all!

I'm writing this e-mail because I'm using HackRF-One SDR as a spectrum analyzer 
in a university project.

I'm also using a Spyverter converter (https://airspy.com/spyverter-r2/) and I'm 
having troubles to configure correctly the device, since I'm not very familiar 
with it.

I'm interested in detecting with the HackRF-One a signal which is at 457 KHz 
(out off the range of operation), therefore I need the Spyverter to achieve it, 
but I'm not able to configure it.

If you have some experience with this device used with a HackRF, or there's any 
website I can get some information about how to configurate it, I'll apreciate 
it a lot.

Thank you very much in advance,
Kindest regards,

Alejandro Ramiro.
--
Alejandro Ramiro Muñoz
NIA: 100314975

Grado en Ingeniería de Sistemas de Comunicaciones
(Bachelor's Degree in Communication System Engineering)

Universidad Carlos III de Madrid
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] RX/TX switching

2018-04-11 Thread Gavin Jacobs 
Matteo,
Using GnuRadioCompanion, there is a way to switch from RX to TX, but it is not 
obvious. If you use the Osmosdr Source and Sink blocks, and specify the hackrf 
as the device, then one works but not the other. However, if you use the 
Osmosdr Source and Sink blocks, and specify Soapy as the device, and hackrf as 
the soapy device, then you can have both source and sink in the same flowgraph. 
If you are a newcomer to GRC, it can be a long road to get it working. To get 
started, are you a beginner with GRC? What is your platform? Do you have the 
hackrf working in receive mode? Also, please tell us a bit about your 
application.

Jake


From: HackRF-dev  on behalf of Matteo 
Terzi 
Sent: April 10, 2018 3:34 AM
To: hackrf-dev@greatscottgadgets.com
Subject: [Hackrf-dev] RX/TX switching

Hi,
I'd like to know if there is a way to switch from RX mode to TX mode and vice 
versa with GRC Radio Companion.
Thanks

--
Matteo TERZI
Google Gmail Member
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Is my new (old) HackRF Deaf?

2017-07-10 Thread Gavin Jacobs 
Jerry,

Learning how to use Ubuntu, and Gnu, and HackRF is a challenge! I went down 
that path about a year ago. The issue you describe hits every new user. When 
you are running GNU radio, you have to turn up the IF gain to about 40 - it 
defaults to 0. Also, turn up the BaseBand gain to about 30. Leave the RF gain 
at 0 (that setting is confusing; a value of 0 just means the RF LNA is left 
off; 14 means it is on; but you rarely need it on).


Also, a word of caution. Since you are a ham, you likely have an HT or a base 
station. You have to take care to never exceed the maximum field strength 
anywhere near the HackRF. I don't recall the exact spec, but basically if you 
transmit with a 5 Watt HT, right next to HackRF, you can fry the RF front end.


Hope that helps.

Jake



From: HackRF-dev  on behalf of Jerry 
Stern 
Sent: July 10, 2017 2:54:16 PM
To: hackrf-dev@greatscottgadgets.com
Subject: [Hackrf-dev] Is my new (old) HackRF Deaf?


Is my HackRF deaf?  I am a ham radio hobbyist and I bought a HackRF One to 
enhance my deeper learning of SDR but also as a broadband RF source.  To my 
dismay, installing the software has become days of learning Ubuntu basics and 
dealing with instructions that are at times outdated or nuanced towards a 
person with much more than basic Linux skills.  So, I gave up on Ubuntu only 
because it was faster for me to install and test with Windows 7.   My HackRF 
One (GreatScott) must have been a leftover as the firmware was dated 
2014(August).  I installed the latest version HackRF tools and updated the 
firmware to Feb 2017.  I followed Mike's video tutorial for creating a basic 
GNU flow for FM and also installed SDR#.  I have very strong FM broadcast 
stations in my area which I can easily demodulate with my Rigol Spectrum 
analyzer using the ANT500. However both with GNU and SDR# my HackRF appears 
deaf in FM broadcast mode.  I read that a few years back there may have been 
some issues with cold solder joints on the HackRF pcb  I have a lot of test 
equipment - from RF generators up to 2 GHz, etc but before I go that route is 
there something I am perhaps missing in my setup.  Not sure where or what 
details to provide here without overloading my question further .


Thanks


Jerry


Sent from my iPhone
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] release 2017.02.1

2017-02-14 Thread Gavin Jacobs 
I now have the host tools working on Windows 10. Thanks to Dominic for 
assistance. If you want to update the Windows build instructions, I would be 
happy to test them out. Or if you would like a copy of the binaries, just let 
me know how to upload to the wiki.


Using Windows 10, I updated the firmware and CPLD on my HackRF One. Here is the 
output:

C:\local\hackrf\hackrf_tools>hackrf_info
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 00**   {actual s/n obfuscated by me}
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x005d475a


So just one minor question left: should the version numbers for hackrf_info and 
libhackrf show as 'unknown'?



From: Dominic Spill <domini...@gmail.com>
Sent: February 14, 2017 9:20:59 AM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1


I tracked this down very late last night.  You are using the static version of 
libusb and I'm using the DLL. libusb-1.0.18-win\MS64\static\libusb-1.0.lib vs 
libusb-1.0.18-win\MS64\dll\libusb-1.0.lib

The tricky part was working out why this matters.  It turns out that Visual 
Studio 14 2015 has changed the way that some functions are linked, most notably 
the stdio.h functions, this wouldn't be a problem with binaries built with the 
same compiler or dynamically linked libraries, but when linking to a static 
library built with the different versions of the function, it causes a problem.

There are two fixes to this:
1) Use the dll version
2) Add legacy_stdio_definitions.lib to the linked libraries

Option 2 doesn't entirely solve it and there are some required code changes.  I 
recommend using the dll for now.

Thanks,
  Dominic

On 14 February 2017 at 08:19, Gavin Jacobs 
<apriljunk...@hotmail.com<mailto:apriljunk...@hotmail.com>> wrote:

Dominic,

Further to your questions:


I believe I have the latest version. I downloaded hacrkf-master.zip and all the 
files within are timestamped 2017-02-11 11:24.


Here is my CMAKE command (executed from C:\local\hackrf-master\host\build )

cmake ../ -G "Visual Studio 14 2015 Win64" 
-DLIBUSB_INCLUDE_DIR=c:\local\libusb-1.0.18-win\include\libusbx-1.0 
-DLIBUSB_LIBRARIES=c:\local\libusb-1.0.18-win\MS64\static\libusb-1.0.lib 
-DTHREADS_PTHREADS_INCLUDE_DIR=c:\local\pthreads-w32-2-9-1-release\Pre-built.2\include
 
-DTHREADS_PTHREADS_WIN32_LIBRARY=c:\local\pthreads-w32-2-9-1-release\Pre-built.2\lib\x64\pthreadVC2.lib
 -DPKG_CONFIG_EXECUTABLE=C:\local\pkg-config_0.26-1_win32\bin\pkg-config.exe


The only difference I see is the libusb version (1.0.18-win vs. 1.0.21).


Thanks,

Jake



From: Dominic Spill <domini...@gmail.com<mailto:domini...@gmail.com>>
Sent: February 13, 2017 5:42:27 PM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1

On 13 February 2017 at 17:11, Gavin Jacobs 
<apriljunk...@hotmail.com<mailto:apriljunk...@hotmail.com>> wrote:
>
> Thanks for the pointer to pkgconfig. If you are updating the instructions, 
> you'll need the extra info as follows.

I've been experimenting with this today and I've discovered that the pkg-config 
thing is my fault, you shouldn't need it for the Windows build, but I made an 
error in the config that complains if you don't have it.
>
> NB: in addition to the files in that zip, you also need two other DLLs as per 
> steps 4 - 8 below:
>
> go to http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/
> download the file pkg-config_0.26-1_win32.zip
> extract the files to c:\programs\pk-config_0.26-1_win32
> download the file gettext-runtime_0.18.1.1-2_win32.zip
> extract JUST the file bin/intl.dll to c:\programs\pk-config_0.26-1_win32\bin
> go to http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28
> download file glib_2.28.8-1_win32.zip
> extract JUST the file bin/libglib-2.0-0.dll to 
> c:\programs\pk-config_0.26-1_win32

This is strange, I don't need these at all.  Although I've just discovered that 
none of my executables work.

> Meanwhile, getting pkgconfig fixed the cmake step, but now MSBUILD step is 
> reporting errors such as:
> libusb-1.0.lib(core.obj) : error LNK2001: unresolved external symbol 
> __imp__iob [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
> libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol 
> __imp__vsnprintf referenced in function usbi_log_v 
> [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
> libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol 
> __imp__snprintf referenced in function usbi_log_v 
> [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
> libusb-1.0.lib(windows_usb.obj) : error LNK2001: unresolved external symbol 
> __imp__snprintf 
> [C:\local\hackrf-master\host

Re: [Hackrf-dev] release 2017.02.1

2017-02-13 Thread Gavin Jacobs 
Thanks for the pointer to pkgconfig. If you are updating the instructions, 
you'll need the extra info as follows.

NB: in addition to the files in that zip, you also need two other DLLs as per 
steps 4 - 8 below:

  1.  go to http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/
  2.  download the file 
pkg-config_0.26-1_win32.zip<http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip>
  3.  extract the files to c:\programs\pk-config_0.26-1_win32
  4.  download the file 
gettext-runtime_0.18.1.1-2_win32.zip<http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-runtime_0.18.1.1-2_win32.zip>
  5.  extract JUST the file bin/intl.dll to 
c:\programs\pk-config_0.26-1_win32\bin
  6.  go to http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28
  7.  download file 
glib_2.28.8-1_win32.zip<http://ftp.acc.umu.se/pub/gnome/binaries/win32/glib/2.28/glib_2.28.8-1_win32.zip>
  8.  extract JUST the file bin/libglib-2.0-0.dll to 
c:\programs\pk-config_0.26-1_win32

Meanwhile, getting pkgconfig fixed the cmake step, but now MSBUILD step is 
reporting errors such as:
libusb-1.0.lib(core.obj) : error LNK2001: unresolved external symbol __imp__iob 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol 
__imp__vsnprintf referenced in function usbi_log_v 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
libusb-1.0.lib(core.obj) : error LNK2019: unresolved external symbol 
__imp__snprintf referenced in function usbi_log_v 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
libusb-1.0.lib(windows_usb.obj) : error LNK2001: unresolved external symbol 
__imp__snprintf [C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
libusb-1.0.lib(windows_usb.obj) : error LNK2019: unresolved external symbol 
__imp_sprintf referenced in function guid_to_string 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
libusb-1.0.lib(windows_usb.obj) : error LNK2019: unresolved external symbol 
__imp_sscanf referenced in function force_hcd_device_descriptor 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]
C:\local\hackrf-master\host\build\libhackrf\src\Debug\hackrf.dll : fatal error 
LNK1120: 5 unresolved externals 
[C:\local\hackrf-master\host\build\libhackrf\src\hackrf.vcxproj]

Thanks for any suggestions.
Jake




From: Dominic Spill <domini...@gmail.com>
Sent: February 13, 2017 12:13:06 PM
To: Gavin Jacobs
Cc: hackrf-dev@greatscottgadgets.com
Subject: Re: [Hackrf-dev] release 2017.02.1

On 13 February 2017 at 11:56, Gavin Jacobs 
<apriljunk...@hotmail.com<mailto:apriljunk...@hotmail.com>> wrote:
>
> I looked at your build output here:
> https://ci.appveyor.com/project/mossmann/hackrf/build/job/2muwvs91hw1g3w6m
>
> My attempt matches yours up to line 97; but on line 98 yours says:
> -- Found PkgConfig: C:/pkg-config/bin/pkg-config.exe
>
> and mine says:
> -- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)
>
> I suspect this is a prerequisite that is not mentioned in the instructions, 
> so your example has helped. I tried to find pkgConfig for Windows, but there 
> wasn't any obvious choice. Which version do you use?

Ah, I see the problem, the build instructions don't mention pkg-config, I'll 
fix that.  I used this version of pkg-config: 
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip

You will also need to pass the location of pkg-config to cmake, something like 
this:
-DPKG_CONFIG_EXECUTABLE="C:\pkg-config\bin\pkg-config.exe"

You can see our Appveyor config here, which is probably more up to date than 
the build instructions in the readme file:
https://github.com/mossmann/hackrf/blob/master/appveyor.yml

That includes the download of the prerequisites in the "install" section, 
followed by the cmake and msbuild steps below it.

Thanks,
  Dominic

> 
> From: Dominic Spill <domini...@gmail.com<mailto:domini...@gmail.com>>
> Sent: February 13, 2017 10:08:15 AM
> To: Gavin Jacobs
>
> Cc: hackrf-dev@greatscottgadgets.com<mailto:hackrf-dev@greatscottgadgets.com>
> Subject: Re: [Hackrf-dev] release 2017.02.1
>
> On 13 February 2017 at 09:35, Gavin Jacobs 
> <apriljunk...@hotmail.com<mailto:apriljunk...@hotmail.com>> wrote:
> >
> > I have a dual boot computer (Windows and Ubuntu). So, I could use the 
> > Ubuntu system to update the firmware, but would I need to update hackrf 
> > host on both OS?
>
> That's correct.  You can also use the hackrf_spiflash tool under Windows to 
> update the firmware, once you have it built.
>
> > If yes, then I would like to hear from anyone who has actually built the 
> > latest hackrf host tool

Re: [Hackrf-dev] release 2017.02.1

2017-02-13 Thread Gavin Jacobs 
I have a dual boot computer (Windows and Ubuntu). So, I could use the Ubuntu 
system to update the firmware, but would I need to update hackrf host on both 
OS?

If yes, then I would like to hear from anyone who has actually built the latest 
hackrf host tools on Windows. The instructions on the git site don't work, so 
I'm looking for someone who has made it work. And if such a person can be 
found, can you post the procedure? Or can you simply post the binaries?



Thanks,

Jake




From: HackRF-dev  on behalf of Rustu 
Yucel 
Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Cc: hackrf-dev@greatscottgadgets.com
Subject: Re: [Hackrf-dev] release 2017.02.1

Thanks for new firmware! But how about update with Windows OS?

Sent from my iPhone

> On 12 Feb 2017, at 05:16, Michael Ossmann  wrote:
>
> Brian,
>
> That's great to hear!  My guess is that it was the reduction of power
> consumption that helped.  Have you tried running your HackRF off a powered 
> hub?
>
> Mike
>
>
>> On Sat, Feb 11, 2017 at 06:59:15PM -0700, Brian Gieryk wrote:
>>
>> Before the update, I was running the Hackrf in GQRX on a Raspberry Pi 3B.
>>
>> Input rate was 1 Msps, I could only run narrow fm, and I could not run DSP 
>> and use my mouse at the same time.  In other words, performance was all but 
>> unusable...
>>
>> After the update, I can now run 1.5 Msps, my mouse functions, and Wide fm is 
>> not great, but it is not overloading the cpu any longer.  In other words, 
>> useability increased by a factor of 10, at least!
>>
>> Thank you very much to the development team that made this happen!
>>
>> Brian
>> KE6IYC
>>
>> Sent from my iPhone
>>
>>> On Feb 11, 2017, at 15:33, Michael Ossmann  wrote:
>>>
>>> Release 2017.02.1 is tagged in git with packages available for download:
>>>
>>> https://github.com/mossmann/hackrf/releases
>>>
>>>
>>> HackRF 2017.02.1 Release Notes
>>>
>>> To upgrade to this release, you must update libhackrf and hackrf-tools on 
>>> your
>>> host computer.  You must also update firmware on your HackRF.  It is 
>>> important
>>> to update both the host code and firmware for this release to work properly.
>>> If you only update one or the other, you may experience unpredictable 
>>> behavior.
>>>
>>> Major changes in this release include:
>>>
>>> - Sweep mode: A new firmware function enables wideband spectrum monitoring 
>>> by
>>> rapidly retuning the radio without requiring individual tuning requests from
>>> the host computer.  The new hackrf_sweep utility demonstrates this function,
>>> allowing you to collect spectrum measurements at a sweep rate of 8 GHz per
>>> second.  Thanks to Mike Walters, author of inspectrum, for getting this
>>> feature working!
>>>
>>> - Hardware synchronization: It is now possible to wire the expansion 
>>> headers of
>>> two or more HackRF Ones together so that they start sampling at the same
>>> time.  This is advantageous during phase coherent operation with clock
>>> synchronized HackRFs.  See the -H option of hackrf_transfer.  Thank you, 
>>> Mike
>>> Davis!
>>>
>>> - A new utility, hackrf_debug, replaces three older debug utilities,
>>> hackrf_si5351c, hackrf_max2837, and hackrf_rffc5071.
>>>
>>> - Power consumption has been reduced by turning off some microcontroller
>>> features we weren't using.
>>>
>>> There have been many more enhancements and bug fixes.  For a full list of
>>> changes, see the git log.
>>>
>>> Special thanks to Dominic Spill who has taken over much of the software
>>> development effort and has helped with nearly every improvement since the
>>> previous release!
>>> ___
>>> HackRF-dev mailing list
>>> HackRF-dev@greatscottgadgets.com
>>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> ___
> HackRF-dev mailing list
> HackRF-dev@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] FATAL: No supported devices found to pick from.

2017-01-11 Thread Gavin Jacobs 
In GnuRadioCompanion, double click the osmocom source (or sink); on the line 
that says Device Arguments, type:

hackrf=278a43c7


This is last 8 digits of the serial number from hackrf_info, which was in your 
first post.


Also, your firmware version is not the latest; that probably is not the source 
of your problems, but you should probably update it once you get things working.


On a Virtual Machine, I could always get it to sorta work, but not reliably.





From: Marc Pàmies Massip <mpamies...@gmail.com>
Sent: January 11, 2017 12:04 PM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] FATAL: No supported devices found to pick from.

Hey Gavin,

Can you tell me how to specify the hackrf by serial? Or you don't recommend to 
do this as it didn't worked at all for you?


After running command "hackrf_info" on a Linux distro it returns this:

Found HackRF board 0:
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0xa000cb3c 0x00554743
Serial Number: 0x 0x 0x466c64c8 0x278a43c7



___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] FATAL: No supported devices found to pick from.

2017-01-11 Thread Gavin Jacobs 
I tried to run my hackrf in a VM and it almost worked.

For the Osmocom source block, I had to specify the hackrf by serial # on the 
device options. I got it to recognize the hackrf and it would appear to 
function for a while, but the virtual usb driver would randomly fail without 
any error messages, and then the hackrf would freeze up. Eventually I went with 
a dual boot scenario.


Jake




From: HackRF-dev  on behalf of Chuck 
McManis 
Sent: January 11, 2017 11:28:17 AM
To: Marc P?mies Massip
Cc: Hackrf-dev
Subject: Re: [Hackrf-dev] FATAL: No supported devices found to pick from.

Since you are running in a VM anyway, consider downloading the Pentoo image as 
referenced by the GreatScottGadgets site. That is very plug and play with the 
HackRF-1. A long shot would be to look for is whether or not you are a member 
of group 'plugdev' since your ls of the dev tree showed that the hackrf is 
owned by root and only gives  access to root or members of group plugdev. I 
don't think hackrf_info would work though if you weren't.




On Wed, Jan 11, 2017 at 10:22 AM, Marc P?mies Massip 
> wrote:
Hi,

I am having some problems trying to use GNUradio together with a HackRF-One. 
The hardware seems to be fine as the LED lights turned ON and it works with 
SDR# on Windows.

After running command "hackrf_info" on a Linux distro it returns this:

Found HackRF board 0:
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0xa000cb3c 0x00554743
Serial Number: 0x 0x 0x466c64c8 0x278a43c7

I can see the device when running the "lsusb" command:
Bus 002 Device 006: ID 1d50:6089 OpenMoko, Inc.

And that's the output to "ls -l /dev/bus/usb/002/006" (I don't know if it will 
be useful for you)
crw-rw+ 1 root plugdev 189, 133 ene 11 16:38 /dev/bus/usb/002/006

Until here everything seems to work as expected. The problem comes when I 
execute a flowgraph with an osmocom source on it, then the program displays the 
following message:

gr-osmosdr v0.1.4-75-gae686c46 (0.1.5git) gnuradio 3.7.10
built-in source types: file fcd rtl_tcp rfspace redpitaya

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

I am running a Kali Linux as a virtual machine (with VMware), which is supposed 
to include multiple sdr tools. I think that the problem has to do with some 
libraries or tools for HackRF, but when I try to install or upgrade libhackrf 
or hackrf-tools the followin message appears in the terminal:

root@kali247:~# apt-get install hackrf-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package hackrf-tools

The same message appears for libhackrf. Any idea of what could be wrong? I am a 
bit lost right now, any help is welcome. I don't know if I am missing 
something, if you need further information just ask.

Thank you for your time,

Marc.

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev


___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

Re: [Hackrf-dev] Host Build with VS 2015

2016-10-12 Thread Gavin Jacobs 
Worked fine for me - thanks for sorting that out.



From: HackRF-dev  on behalf of James 
Brown 
Sent: October 12, 2016 12:50:51 PM
To: hackrf-dev@greatscottgadgets.com
Subject: [Hackrf-dev] Host Build with VS 2015

I have finally managed to get a successful build of the host using Windows 10 
x64 and Visual Studio 2015
The complete step-by-step process is at:
http://www.seti.net/engineering/engineering.php

I will go through that one more time from scratch to make sure its right.
I did have to modify hackrf.c at one point. I had to add : #define 
HAVE_STRUCT_TIMESPEC at the top of the file.
Is this something that can be added to the Git source file itself

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Hackrf-dev] Narrowband fm - what is the secret?

2016-09-14 Thread Gavin Jacobs 
Yesterday (thanks to help here on this mail list) I got my hackrf One working 
as an FM receiver. I have SDR# v1.0.0.1483 running on Windows 10. So, today I 
want to move on to narrowband fm. I picked APRS channel because there is steady 
traffic. I tuned SDR# to 144.39 MHz, NFM, bandwidth 8k, LNA gain 32, VGA gain 
24, amp off (also tried on), squelch off, antenna adjusted to 52 cm.

If I key my handheld, I see a big spike on the frequency; and if I zoom in, it 
appears centered on 144.39.  Meanwhile, on my handheld, I can hear the AFSK 
tones, so I know there are signals coming in, but the hackrf/SDR# doesn't 
change (neither frequency nor audio).

My first guess is that I have missed some RF setting, but I've been through the 
menus and can't find anything.

Once again - any advice is welcome.


Jake
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Hackrf-dev] Fw: How to verify hackrf is working

2016-09-13 Thread Gavin Jacobs 
Martin,

That was the problem. I didn't realize that you could only turn up the gains 
after clicking on play.


Thanks!

Jake


From: HackRF-dev  on behalf of Martin 
Smith via HackRF-dev 
Sent: September 13, 2016 6:50 PM
To: hackrf-dev@greatscottgadgets.com
Subject: Re: [Hackrf-dev] How to verify hackrf is working

Did you click on the gear wheel icon in SDR# (after clicking on the play
icon) and turn up the gains ?

___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Hackrf-dev] How to verify hackrf is working

2016-09-13 Thread Gavin Jacobs 
I have a new hackrf One and I can't get anything out of it. I am running 
Windows 10 (64 bit). I have it plugged into a USB port, it shows up in Device 
Manager. I ran the Zadig program to set the driver to WinUSB. I can see the 
device with hackrf_info, as follows:

C:\local\hackrf_tools>hackrf_info
Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0x005d475a 0x005d475a
Serial Number: 0x 0x 0x909864c8 0x343e0ecf


and here is the output from hackrf_transfer:

C:\local\hackrf_tools>hackrf_transfer -r rx_file -f 10770 -n 1
call hackrf_sample_rate_set(1000 Hz/10.000 MHz)
call hackrf_baseband_filter_bandwidth_set(900 Hz/9.000 MHz)
call hackrf_set_freq(10770 Hz/107.700 MHz)
samples_to_xfer 1/100Mio
Stop with Ctrl-C
19.9 MiB / 1.001 sec = 19.9 MiB/second
19.9 MiB / 1.000 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.000 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second

Exiting... hackrf_is_streaming() result: HACKRF_ERROR_STREAMING_EXIT_CALLED 
(-1004)
Total time: 10.00949 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit
The rx LED came on while receiving.

So far so good, but when I try to receive an FM broadcast (107.7 MHz) station 
with SDR#, I get:
- static on the speakers
- a big spike on the frequency display, but not much else; the spike goes away 
if I click on "Correct IQ"

I also tuned to a ham narrowband FM frequency 147.42 MHz and then transmitted 
with my handheld. I could see an increase in the rf power, but still no audio 
(just static).

Any suggestions welcome.

Jake








___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev