[Hackrf-dev] release 2017.02.1

[Michael Ossmann]

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!

[Brian Gieryk]

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 <***@ossmann.com> 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-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Michael Ossmann]

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 <***@ossmann.com> 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-***@greatscottgadgets.com
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Rustu Yucel]

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

Sent from my iPhone

> On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com> 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 <***@ossmann.com> 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-***@greatscottgadgets.com
>>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

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

> On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com> 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 <***@ossmann.com> 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-***@greatscottgadgets.com
>>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Dominic Spill]

On 13 February 2017 at 09:35, Gavin Jacobs <***@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 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

______________________________
> 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
>
> > On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com> 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 <***@ossmann.com> 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-***@greatscottgadgets.com
> >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>

[Gavin Jacobs]

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

On 13 February 2017 at 09:35, Gavin Jacobs <***@hotmail.com<mailto:***@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 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

______________________________
> From: HackRF-dev <hackrf-dev-***@greatscottgadgets.com<mailto:hackrf-dev-***@greatscottgadgets.com>> on behalf of Rustu Yucel <***@gmail.com<mailto:***@gmail.com>>
> Sent: February 11, 2017 10:22:34 PM
> To: Michael Ossmann
> Cc: hackrf-***@greatscottgadgets.com<mailto: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
>
> > On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com<mailto:***@ossmann.com>> 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 <***@ossmann.com<mailto:***@ossmann.com>> 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-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>

[Michael Stahn]

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.


On 13.02.2017 19:56, Gavin Jacobs 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?
>
>
> ------------------------------------------------------------------------
> *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
>
> On 13 February 2017 at 09:35, Gavin Jacobs <***@hotmail.com
> <mailto:***@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 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
>
> ______________________________
> > From: HackRF-dev <hackrf-dev-***@greatscottgadgets.com
> <mailto:hackrf-dev-***@greatscottgadgets.com>> on behalf of Rustu
> Yucel <***@gmail.com <mailto:***@gmail.com>>
> > Sent: February 11, 2017 10:22:34 PM
> > To: Michael Ossmann
> > Cc: hackrf-***@greatscottgadgets.com
> <mailto: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
> >
> > > On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com
> <mailto:***@ossmann.com>> 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 <***@ossmann.com
> <mailto:***@ossmann.com>> wrote:
> > >>>
> > >>> Release 2017.02.1 is tagged in git with packages available for
> download:
> > >>>
> > >>> 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.
> > >>>
> > >>> 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-***@greatscottgadgets.com
> <mailto:HackRF-***@greatscottgadgets.com>
> > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>
> > > _______________________________________________
> > > HackRF-dev mailing list
> > > HackRF-***@greatscottgadgets.com
> <mailto:HackRF-***@greatscottgadgets.com>
> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com
> <mailto:HackRF-***@greatscottgadgets.com>
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>
> >
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com
> <mailto:HackRF-***@greatscottgadgets.com>
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev>
> >
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

[Dominic Spill]

On 13 February 2017 at 11:56, Gavin Jacobs <***@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 <***@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
>
> On 13 February 2017 at 09:35, Gavin Jacobs <***@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 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
>
> ______________________________
> > 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
> >
> > > On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com> 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 <***@ossmann.com> 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-***@greatscottgadgets.com
> > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > > _______________________________________________
> > > HackRF-dev mailing list
> > > HackRF-***@greatscottgadgets.com
> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> >
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> >
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>

[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 <***@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

On 13 February 2017 at 11:56, Gavin Jacobs <***@hotmail.com<mailto:***@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 <***@gmail.com<mailto:***@gmail.com>>
> Sent: February 13, 2017 10:08:15 AM
> To: Gavin Jacobs
>
> Cc: hackrf-***@greatscottgadgets.com<mailto:hackrf-***@greatscottgadgets.com>
> Subject: Re: [Hackrf-dev] release 2017.02.1
>
> On 13 February 2017 at 09:35, Gavin Jacobs <***@hotmail.com<mailto:***@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 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
>
> ______________________________
> > From: HackRF-dev <hackrf-dev-***@greatscottgadgets.com<mailto:hackrf-dev-***@greatscottgadgets.com>> on behalf of Rustu Yucel <***@gmail.com<mailto:***@gmail.com>>
> > Sent: February 11, 2017 10:22:34 PM
> > To: Michael Ossmann
> > Cc: hackrf-***@greatscottgadgets.com<mailto: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
> >
> > > On 12 Feb 2017, at 05:16, Michael Ossmann <***@ossmann.com<mailto:***@ossmann.com>> 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 <***@ossmann.com<mailto:***@ossmann.com>> 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-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > > _______________________________________________
> > > HackRF-dev mailing list
> > > HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> >
> > _______________________________________________
> > HackRF-dev mailing list
> > HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
> >
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com<mailto:HackRF-***@greatscottgadgets.com>
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>

[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: 00000000000000****************** {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 <***@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 <***@hotmail.com<mailto:***@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 <***@gmail.com<mailto:***@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 <***@hotmail.com<mailto:***@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\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]

I seem to remember having these issues, but they should have been resolved recently. Are you building from the 2017.02.1 release package?

Could you send me your cmake command line? Mine is:
PS C:\Program Files\hackrf_all\bin> cmake.exe ../ -G "Visual Studio 14 2015 Win64" -DLIBUSB_INCLUDE_DIR=C:\src\libusb-1.0.21\include\libusb-1.0\ -DLIBUSB_LIBRARIES=C:\src\libusb-1.0.21\MS64\dll\libusb-1.0.lib -DTHREADS_PTHREADS_INCLUDE_DIR=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\include\ -DTHREADS_PTHREADS_WIN32_LIBRARY=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\lib\x64\pthreadVC2.lib -DPKG_CONFIG_EXECUTABLE=C:\src\pkg-config_0.26-1_win32\bin\pkg-config.exe

[Dominic Spill]

On 14 February 2017 at 13:39, Gavin Jacobs <***@hotmail.com> wrote:
>
> 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: 00000000000000****************** {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'?

This is because of the source archive that you downloaded (github makes
this a little confusing). When building from a git repository we detect
the git commit and use it for the version string, when we package a release
we replace the string with the release version string. Unfortunately, when
we tag a release GitHub produces two source archives that are neither git
repositories nor have the string updated, so you get the fallback version
string of "unknown".

> ________________________________
> From: Dominic Spill <***@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 <***@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 <***@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 <***@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\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]
>>
>> I seem to remember having these issues, but they should have been
resolved recently. Are you building from the 2017.02.1 release package?
>>
>> Could you send me your cmake command line? Mine is:
>> PS C:\Program Files\hackrf_all\bin> cmake.exe ../ -G "Visual Studio 14
2015 Win64" -DLIBUSB_INCLUDE_DIR=C:\src\libusb-1.0.21\include\libusb-1.0\
-DLIBUSB_LIBRARIES=C:\src\libusb-1.0.21\MS64\dll\libusb-1.0.lib
-DTHREADS_PTHREADS_INCLUDE_DIR=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\include\
-DTHREADS_PTHREADS_WIN32_LIBRARY=C:\src\pthreads-w32-2-9-1-release\Pre-built.2\lib\x64\pthreadVC2.lib
-DPKG_CONFIG_EXECUTABLE=C:\src\pkg-config_0.26-1_win32\bin\pkg-config.exe
>>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-***@greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>