[Hackrf-dev] HackRF-dev Digest, Vol 53, Issue 6

McDonald, J Douglas

2017-02-14 14:04:02 UTC

Maybe its time for me to give HackRF another try. Last timne I got fed up
and gave up.

Is there a GOOD description of how to do this on Windows?

What I want to do is transmit a test pattern that repeats every 1/100 to
10 seconds, forever, with no breeaks or glitches. I sort of got it working
on Windows 8 but Windows 10 broke the "no glitches" part.

I got it to work by using HackRFTransfer .. I never got a dll to
do the actual transmitting. I'd like to have a standalone program.

This is to make a custom sweep generator for aligning
old tube radios and TVs.

I never got it to work on Ubuntu at all.

Doug McDonald

-----Original Message-----
From: HackRF-dev [mailto:hackrf-dev-***@greatscottgadgets.com] On Behalf Of hackrf-dev-***@greatscottgadgets.com
Sent: Tuesday, February 14, 2017 12:29 AM
To: hackrf-***@greatscottgadgets.com
Subject: HackRF-dev Digest, Vol 53, Issue 6

Send HackRF-dev mailing list submissions to
hackrf-***@greatscottgadgets.com

To subscribe or unsubscribe via the World Wide Web, visit
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
or, via email, send a message with subject or body 'help' to
hackrf-dev-***@greatscottgadgets.com

You can reach the person managing the list at
hackrf-dev-***@greatscottgadgets.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of HackRF-dev digest..."

Today's Topics:

1. Re: release 2017.02.1 (Gavin Jacobs)
2. Re: release 2017.02.1 (Dominic Spill)
3. Signal at IF (James Brown)
4. Re: Raspberry Pis and HackRFs (Dominic Spill)
5. Re: release 2017.02.1 (Gavin Jacobs)
6. Re: release 2017.02.1 (Michael Stahn)
7. Re: release 2017.02.1 (Dominic Spill)
8. Re: Signal at IF (Dominic Spill)
9. Re: Fwd: Dead Hack RF - Update (Dominic Spill)
10. Why Hackrf only one time run and stop (Rustu Yucel)
11. Re: Why Hackrf only one time run and stop (Dominic Spill)
12. Re: Why Hackrf only one time run and stop (Rustu Yucel)
13. Re: Why Hackrf only one time run and stop (Dominic Spill)
14. Re: Why Hackrf only one time run and stop (Alexandru Csete)
15. Re: Why Hackrf only one time run and stop (Alexandru Csete)
16. Re: Why Hackrf only one time run and stop (Dominic Spill)
17. Re: Why Hackrf only one time run and stop (Alexandru Csete)
18. Re: Why Hackrf only one time run and stop (Dominic Spill)
19. Re: release 2017.02.1 (Gavin Jacobs)
20. Re: Why Hackrf only one time run and stop (Rustu Yucel)

----------------------------------------------------------------------

Message: 1
Date: Mon, 13 Feb 2017 16:35:16 +0000
From: Gavin Jacobs <***@hotmail.com>
To: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID:
<***@DM5PR22MB0044.namprd22.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

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 <hackrf-dev-***@greatscottgadgets.com> on behalf of Rustu Yucel <***@gmail.com>
Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Cc: hackrf-***@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

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

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

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.
- 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
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

_______________________________________________
HackRF-dev mailing list
HackRF-***@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/36e7f118/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 13 Feb 2017 10:08:15 -0700
From: Dominic Spill <***@gmail.com>
To: Gavin Jacobs <***@hotmail.com>
Cc: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID:
<CACX+tOZpzbVGJcj0RuVyGRAHS_mtdPy3MdGHi5mrm4ThJA+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 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?

I have built the HackRF tools on a Windows system recently and I have also
set up automated builds using Appveyor:
https://ci.appveyor.com/project/mossmann/hackrf

Could you give more details on what doesn't work with the instructions and
I will attempt to fix them.

Thanks,
Dominic

______________________________

Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Subject: Re: [Hackrf-dev] release 2017.02.1
Thanks for new firmware! But how about update with Windows OS?
Sent from my iPhone

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

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

Release 2017.02.1 is tagged in git with packages available for
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.

- 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
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/585601f8/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 13 Feb 2017 08:23:01 -0800
From: "James Brown" <***@SETI.Net>
To: <hackrf-***@greatscottgadgets.com>
Subject: [Hackrf-dev] Signal at IF
Message-ID: <***@Zeke>
Content-Type: text/plain; charset="utf-8"

I have two HackRF that both exhibit a set of signals in the center of the IF across all bands and all frequencies. I have posted screen grabs on my web site here:
http://www.seti.net/engineering/engineering.php
Initially I thought it was an I/Q imbalance problem with the software I was using, SDR Console V3, but now I?m not sure.
These grabs were with the HackRF running at 2 mHz bandwidth but it?s the same at all other bandwidth settings.
The signals remain but change in amplitude with all settings of LNA , VGA settings, and external amp. They remain the same with all receive modes (AM, USB, etc).
The receivers are running with no antenna, no clock input and antenna input terminated with a 50 ohm load.
Windows 10 64 bit.
One of the other users of SDR Console suggested that a change in IF frequency might move the signals off to the side but SDR Console does not provide control over that.

I am running the following firmware revisions on the two HackRf:

USB descriptor string: 000000000000000040a465c83826294b
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa000cb3c 0x006a4f5f
Serial Number: 0x00000000 0x00000000 0x40a465c8 0x3826294bFound HackRF board 0:

Board ID Number: 2 (HackRF One)
Firmware Version: git-44df9d1
Part ID Number: 0xa000cb3c 0x00674744
Serial Number: 0x00000000 0x00000000 0x457863c8 0x2337151f

Has anyone else run into this?
Suggestions?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/222c7630/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 13 Feb 2017 11:30:03 -0700
From: Dominic Spill <***@gmail.com>
To: Rustu Yucel <***@gmail.com>
Cc: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Raspberry Pis and HackRFs
Message-ID:
<CACX+tOYPbwzUkey_4GbUeWTC+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I have an error as " hackrf sweep: undefined symbol: hackrf_init_sweep "

and no sweep function of course

What should be done?

This sounds like the same problem, you have two copies of libhackrf
installed. I recommend removing all copies of libhackrf and them
re-running the "make install" step of the installation.

Dominic

Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1
Part ID Number: 0xa000cb3c 0x004f4f5b
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x0f5cafe1

hackrf_open_by_serial

hackrf_info version: git-0335f1a

hackrf_library_release

This is picking up an older copy of libhackrf, possibly the previous

install, possibly one from a package manager.

As Martin suggested, using "ldd /usr/local/bin/hackrf_info" should show

you which version is installed, this error message would suggest that it's
picking up 0.4 rather than 0.5.

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/4d5f871a/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 13 Feb 2017 18:56:41 +0000
From: Gavin Jacobs <***@hotmail.com>
To: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID:
<***@DM5PR22MB0044.namprd22.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

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?

________________________________
From: Dominic Spill <***@gmail.com>
Sent: February 13, 2017 10:08:15 AM
To: Gavin Jacobs
Cc: hackrf-***@greatscottgadgets.com
Subject: Re: [Hackrf-dev] release 2017.02.1

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 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?

I have built the HackRF tools on a Windows system recently and I have also set up automated builds using Appveyor: https://ci.appveyor.com/project/mossmann/hackrf

Could you give more details on what doesn't work with the instructions and I will attempt to fix them.

Thanks,
Dominic

______________________________

Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Subject: Re: [Hackrf-dev] release 2017.02.1
Thanks for new firmware! But how about update with Windows OS?
Sent from my iPhone

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

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/02592fe7/attachment-0001.html>

------------------------------

Message: 6
Date: Mon, 13 Feb 2017 20:07:53 +0100
From: Michael Stahn <***@gmail.com>
To: hackrf-***@greatscottgadgets.com
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID: <56d033f0-a4e2-7735-c1e6-***@gmail.com>
Content-Type: text/plain; charset="windows-1252"

Guys, seriously, compiling open source on windows? Is this a joke? Use a
reasonably (or actual) operating

system and all those problems will vanish into thin air.

https://ci.appveyor.com/project/mossmann/hackrf/build/job/2muwvs91hw1g3w6m
-- Found PkgConfig: C:/pkg-config/bin/pkg-config.exe
-- 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?
------------------------------------------------------------------------
*Sent:* February 13, 2017 10:08:15 AM
*To:* Gavin Jacobs
*Subject:* Re: [Hackrf-dev] release 2017.02.1

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 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?
I have built the HackRF tools on a Windows system recently and I have
https://ci.appveyor.com/project/mossmann/hackrf
Could you give more details on what doesn't work with the instructions
and I will attempt to fix them.
Thanks,
Dominic
______________________________

Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Subject: Re: [Hackrf-dev] release 2017.02.1
Thanks for new firmware! But how about update with Windows OS?
Sent from my iPhone

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

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

Release 2017.02.1 is tagged in git with packages available for
https://github.com/mossmann/hackrf/releases

<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.

- 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
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

<https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

<https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

<https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

<https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>
_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/26805955/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 13 Feb 2017 12:13:06 -0700
From: Dominic Spill <***@gmail.com>
To: Gavin Jacobs <***@hotmail.com>
Cc: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID:
<CACX+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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

________________________________
Sent: February 13, 2017 10:08:15 AM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1

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

I have built the HackRF tools on a Windows system recently and I have

also set up automated builds using Appveyor:
https://ci.appveyor.com/project/mossmann/hackrf

Could you give more details on what doesn't work with the instructions

and I will attempt to fix them.

Thanks,
Dominic
______________________________

Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Subject: Re: [Hackrf-dev] release 2017.02.1
Thanks for new firmware! But how about update with Windows OS?
Sent from my iPhone

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

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

Release 2017.02.1 is tagged in git with packages available for
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.

- 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
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/ba370fd8/attachment-0001.html>

------------------------------

Message: 8
Date: Mon, 13 Feb 2017 12:36:21 -0700
From: Dominic Spill <***@gmail.com>
To: James Brown <***@seti.net>
Cc: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Signal at IF
Message-ID:
<CACX+tOZDj6gdDPr-ums0SJ=***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I have two HackRF that both exhibit a set of signals in the center of the

IF across all bands and all frequencies. I have posted screen grabs on my

http://www.seti.net/engineering/engineering.php
Initially I thought it was an I/Q imbalance problem with the software I

was using, SDR Console V3, but now I?m not sure.

Could you try using another piece of software, such as SDR#, to verify if
this is an issue with HackRF or the software? We aren't familiar with SDR
Console and I'd like to verify that you see this across multiple pieces of
software. You could also try booting a live OS image and running gqrx.

These grabs were with the HackRF running at 2 mHz bandwidth but it?s the

same at all other bandwidth settings.

The signals remain but change in amplitude with all settings of LNA ,

VGA settings, and external amp. They remain the same with all receive modes
(AM, USB, etc).

The receivers are running with no antenna, no clock input and antenna

input terminated with a 50 ohm load.

Windows 10 64 bit.
One of the other users of SDR Console suggested that a change in IF

frequency might move the signals off to the side but SDR Console does not
provide control over that.

Again, it may be helpful to test with some software that allows changing
the IF.

Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Board ID Number: 2 (HackRF One)
Firmware Version: git-44df9d1

This second firmware is rather old (July 2014), I would recommend upgrading
it. While you're at it, I would also recommend upgrading both to the
2017.02.1 release, although I don't think that will affect your issue here.

Thanks,
Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/4e5fdbfa/attachment-0001.html>

------------------------------

Message: 9
Date: Mon, 13 Feb 2017 12:41:03 -0700
From: Dominic Spill <***@gmail.com>
To: Dana Shtun <***@hotmail.com>
Cc: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Fwd: Dead Hack RF - Update
Message-ID:
<CACX+tOYcjR=WaQKMF7a-wx5sYF27dKBA=***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Dana,

Where did you buy your HackRF? If it's a HackRF One then I think we should
get it back to GSG and get a replacement to you.

Thanks,
Dominic

Fortunately I found a friend who can do SMD rework locally
and had him replace the microprocessor.
Well, this cured the very hot (burn your finger) micro issue, but the

hack is still dead.

Further investigation suggests that the DC-DC power supply chip (TPS62410)
is dead, as the 2 voltages it is supposed to produce are missing.
I did find that others had experienced various failures of the power

supply chip

in the past, so I?m hopeful that it is part of the problem. I also see
that there is a more robust chip in the series. (ie higher current

capabilities)

Dana
VE3DS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/3b320223/attachment-0001.html>

------------------------------

Message: 10
Date: Mon, 13 Feb 2017 23:37:35 +0300
From: Rustu Yucel <***@gmail.com>
To: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CADTrzV=KP5kec80jciji0-***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

After I install gqrx (with guide of gqrx.dk website) I am not able to get
samples from hack rf (firmware 2017.02.1). I am receiving this
~$ hackrf_transfer -f 102MHz -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(102 Hz/0.000 MHz)
Stop with Ctrl-C
3.4 MiB / 1.000 sec = 3.4 MiB/second

Exiting... hackrf_is_streaming() result: streaming terminated (-1004)
Total time: 1.00012 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

Why only one sample and exiting after? Any help?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/937079ab/attachment-0001.html>

------------------------------

Message: 11
Date: Mon, 13 Feb 2017 13:57:27 -0700
From: Dominic Spill <***@gmail.com>
To: Rustu Yucel <***@gmail.com>
Cc: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CACX+tObYu8dd8ys-RWyN_xWJB8donbk85X15Q+r+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

After I install gqrx (with guide of gqrx.dk website) I am not able to get

samples from hack rf (firmware 2017.02.1). I am receiving this

~$ hackrf_transfer -f 102MHz -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(102 Hz/0.000 MHz)

You need to specify -f 102e6 or -f 102000000 to receive on 102MHz.

Stop with Ctrl-C
3.4 MiB / 1.000 sec = 3.4 MiB/second

This data rate is very low, it should be around 20MiB/second. What is the
host system that you are running on? Is it embedded hardware?

Exiting... hackrf_is_streaming() result: streaming terminated (-1004)
Total time: 1.00012 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit
Why only one sample and exiting after? Any help?

Could you give us the output of hackrf_info ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/e5096b6b/attachment-0001.html>

------------------------------

Message: 12
Date: Tue, 14 Feb 2017 00:28:31 +0300
From: Rustu Yucel <***@gmail.com>
To: Dominic Spill <***@gmail.com>
Cc: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID: <C63A0C38-3084-4DD5-B6E8-***@gmail.com>
Content-Type: text/plain; charset="utf-8"

?ts ubuntu 16.10 and it was working smoothly till gqrx install. Gqrx website asked first remove some previous packs then I can not get signal. just 1 max signal then its stops. Help?

Sent from my iPhone

After I install gqrx (with guide of gqrx.dk website) I am not able to get samples from hack rf (firmware 2017.02.1). I am receiving this
~$ hackrf_transfer -f 102MHz -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(102 Hz/0.000 MHz)

You need to specify -f 102e6 or -f 102000000 to receive on 102MHz.

Stop with Ctrl-C
3.4 MiB / 1.000 sec = 3.4 MiB/second

This data rate is very low, it should be around 20MiB/second. What is the host system that you are running on? Is it embedded hardware?

Could you give us the output of hackrf_info ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170214/712cebcd/attachment-0001.html>

------------------------------

Message: 13
Date: Mon, 13 Feb 2017 14:38:11 -0700
From: Dominic Spill <***@gmail.com>
To: Rustu Yucel <***@gmail.com>
Cc: hackrf-dev <hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CACX+tOY4npEU-Vaqn46_oa5GHR9LHG2jXppbv+nFHyMsTX-***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

?ts ubuntu 16.10 and it was working smoothly till gqrx install. Gqrx

website asked first remove some previous packs then I can not get signal.
just 1 max signal then its stops. Help?

Which instructions are you following? Which packages did it ask you to
remove before installation?

As I asked in my previous email, what is the hardware you are running on?
What is the output of hackrf_info?

After I install gqrx (with guide of gqrx.dk website) I am not able to

get samples from hack rf (firmware 2017.02.1). I am receiving this

~$ hackrf_transfer -f 102MHz -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(102 Hz/0.000 MHz)

You need to specify -f 102e6 or -f 102000000 to receive on 102MHz.

Stop with Ctrl-C
3.4 MiB / 1.000 sec = 3.4 MiB/second

This data rate is very low, it should be around 20MiB/second. What is

the host system that you are running on? Is it embedded hardware?

Could you give us the output of hackrf_info ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/eec89933/attachment-0001.html>

------------------------------

Message: 14
Date: Mon, 13 Feb 2017 22:38:47 +0100
From: Alexandru Csete <***@gmail.com>
To: Rustu Yucel <***@gmail.com>
Cc: Dominic Spill <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CAHG=***@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

?ts ubuntu 16.10 and it was working smoothly till gqrx install. Gqrx website
asked first remove some previous packs then I can not get signal. just 1 max
signal then its stops. Help?

The gqrx website uses PPAs to provide packages that are newer than the
ones that come with Ubuntu. The hackrf library has not been upgraded
to this latest release and is therefore incompatible with your device
if it has firmware 2017.02.1.

Not sure how handle this upgrade properly... Would have been nice if
libhackrf could handle both old and new firmwares :-(

Alex

------------------------------

Message: 15
Date: Mon, 13 Feb 2017 22:45:18 +0100
From: Alexandru Csete <***@gmail.com>
To: Dominic Spill <***@gmail.com>
Cc: Rustu Yucel <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CAHG=S_cotWLBmYTnTSBkZJQ=Ef_K3ZbLMmQzTJPXOf-***@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

?ts ubuntu 16.10 and it was working smoothly till gqrx install. Gqrx
website asked first remove some previous packs then I can not get signal.
just 1 max signal then its stops. Help?

Which instructions are you following? Which packages did it ask you to
remove before installation?

I assume these are the instructions:
http://gqrx.dk/download/install-ubuntu

They are intended for people who want to run gqrx on Ubuntu but
haven't got a clue about gnuradio, drivers, udev rules etc... They are
clearly incompatible with building any of the components from source.

Alex

------------------------------

Message: 16
Date: Mon, 13 Feb 2017 14:46:20 -0700
From: Dominic Spill <***@gmail.com>
To: Alexandru Csete <***@gmail.com>
Cc: Rustu Yucel <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CACX+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Libhackrf can handle both old and new firmware. I've tested this
hackrf_transfer with every combination of 2015.07.2 and 2017.02.1 libhackrf
and firmware.

The only requirement for upgrading firmware with newer versions of
libhackrf is to use newer features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/0424bc0d/attachment-0001.html>

------------------------------

Message: 17
Date: Mon, 13 Feb 2017 22:50:54 +0100
From: Alexandru Csete <***@gmail.com>
To: Dominic Spill <***@gmail.com>
Cc: Rustu Yucel <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CAHG=S_ewfEoAqH31gK-kU+UL-axEuQYDboisvMxF_4r7k=***@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Ah ok, that's cool. I must have misread it. I am going to upgrade
hackrf in our PPA and it should then work fine.

Alex

------------------------------

Message: 18
Date: Mon, 13 Feb 2017 15:06:40 -0700
From: Dominic Spill <***@gmail.com>
To: Alexandru Csete <***@gmail.com>
Cc: Rustu Yucel <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID:
<CACX+tOa7oVwfEpz5HiUE12385f-co88-obnt7MkT+***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Libhackrf can handle both old and new firmware. I've tested this
hackrf_transfer with every combination of 2015.07.2 and 2017.02.1

libhackrf

and firmware.
The only requirement for upgrading firmware with newer versions of

libhackrf

is to use newer features.

Ah ok, that's cool. I must have misread it. I am going to upgrade
hackrf in our PPA and it should then work fine.

That would be great, thank you.

Rustu, once hackrf has been updated in the gqrx repository, please try
updating and try the hackrf_transfer command again.

Thanks,
Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170213/2d1c3eec/attachment-0001.html>

------------------------------

Message: 19
Date: Tue, 14 Feb 2017 00:11:08 +0000
From: Gavin Jacobs <***@hotmail.com>
To: "hackrf-***@greatscottgadgets.com"
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] release 2017.02.1
Message-ID:
<***@DM5PR22MB0044.namprd22.prod.outlook.com>

Content-Type: text/plain; charset="iso-8859-1"

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 <***@gmail.com>
Sent: February 13, 2017 12:13:06 PM
To: Gavin Jacobs
Cc: hackrf-***@greatscottgadgets.com
Subject: Re: [Hackrf-dev] release 2017.02.1

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

________________________________
Sent: February 13, 2017 10:08:15 AM
To: Gavin Jacobs
Subject: Re: [Hackrf-dev] release 2017.02.1

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.

I have built the HackRF tools on a Windows system recently and I have also set up automated builds using Appveyor: https://ci.appveyor.com/project/mossmann/hackrf
Could you give more details on what doesn't work with the instructions and I will attempt to fix them.
Thanks,
Dominic
______________________________

Sent: February 11, 2017 10:22:34 PM
To: Michael Ossmann
Subject: Re: [Hackrf-dev] release 2017.02.1
Thanks for new firmware! But how about update with Windows OS?
Sent from my iPhone

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

_______________________________________________
HackRF-dev mailing list
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170214/8e24b01d/attachment-0001.html>

------------------------------

Message: 20
Date: Tue, 14 Feb 2017 07:42:11 +0300
From: Rustu Yucel <***@gmail.com>
To: Dominic Spill <***@gmail.com>
Cc: Alexandru Csete <***@gmail.com>, hackrf-dev
<hackrf-***@greatscottgadgets.com>
Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop
Message-ID: <495D266F-BFB5-4A98-871B-***@gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi, thanks for replies, I checked it on windows firstly on sdr# and not working (before firmware update it was ok) I think Mr. Ossmann open a bug report on this issue, now on another machine (kali linux) I tested it hackrf_info gives undefined symbol lookup hackrf_library version but gnuradio and hackrf_transfer works properly! What should I do? gqrx by the way gqrx.dk/d?wnload/install-ubuntu link followed. Maybe I shouldnt run volk_profile?

Sent from my iPhone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170214/08c7e8fe/attachment-0001.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of HackRF-dev Digest, Vol 53, Issue 6
*****************************************