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:[email protected]] On Behalf Of [email protected] Sent: Tuesday, February 14, 2017 12:29 AM To: [email protected] Subject: HackRF-dev Digest, Vol 53, Issue 6 Send HackRF-dev mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <dm5pr22mb0044e06015511c71d63876dcc6...@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 <[email protected]> on behalf of Rustu Yucel <[email protected]> Sent: February 11, 2017 10:22:34 PM To: Michael Ossmann Cc: [email protected] 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > _______________________________________________ > HackRF-dev mailing list > [email protected] > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev _______________________________________________ HackRF-dev mailing list [email protected] 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 <[email protected]> To: Gavin Jacobs <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <cacx+tozpzbvgjcj0ruvygrahs_mtdpy3mdghi5mrm4thja+...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 09:35, Gavin Jacobs <[email protected]> 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 <[email protected]> on behalf of Rustu Yucel <[email protected]> > Sent: February 11, 2017 10:22:34 PM > To: Michael Ossmann > Cc: [email protected] > 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 <[email protected]> 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 <[email protected]> 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 > >>> [email protected] > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > > HackRF-dev mailing list > > [email protected] > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > _______________________________________________ > HackRF-dev mailing list > [email protected] > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > HackRF-dev mailing list > [email protected] > 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" <[email protected]> To: <[email protected]> Subject: [Hackrf-dev] Signal at IF Message-ID: <773B2A4AD83147CCA06218153F6E2757@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 <[email protected]> To: Rustu Yucel <[email protected]> Cc: hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Raspberry Pis and HackRFs Message-ID: <cacx+toypbwzukey_4gbuewtc+mohmfhoyqzp_jfvygbqdqq...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 12 February 2017 at 11:51, Rustu Yucel <[email protected]> wrote: > > 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 > On 12 Feb 2017, at 19:23, Dominic Spill <[email protected]> wrote: > > On 12 February 2017 at 07:21, Roy <[email protected]> wrote: > > > > The RPi3, which was working earlier, apart from hackrf_sweep: > > > > pi@raspberrypi3:~/hackrf/host/build $ hackrf_info > > 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 > > pi@raspberrypi3:~/hackrf/host/build $ hackrf_sweep > > hackrf_sweep: symbol lookup error: hackrf_sweep: undefined symbol: hackrf_open_by_serial > > > > So I rebooted and now I get this: > > > > pi@raspberrypi3:~/hackrf/host/build $ hackrf_info > > hackrf_info version: git-0335f1a > > hackrf_info: symbol lookup error: hackrf_info: undefined symbol: 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 > [email protected] > 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 <[email protected]> To: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <dm5pr22mb00445eb4bc872214f2f5c612c6...@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 <[email protected]> Sent: February 13, 2017 10:08:15 AM To: Gavin Jacobs Cc: [email protected] Subject: Re: [Hackrf-dev] release 2017.02.1 On 13 February 2017 at 09:35, Gavin Jacobs <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > on behalf of Rustu Yucel <[email protected]<mailto:[email protected]>> > Sent: February 11, 2017 10:22:34 PM > To: Michael Ossmann > Cc: [email protected]<mailto:[email protected]> > 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 > > <[email protected]<mailto:[email protected]>> 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 > >>> <[email protected]<mailto:[email protected]>> 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 > >>> [email protected]<mailto:[email protected]> > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > > HackRF-dev mailing list > > [email protected]<mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > _______________________________________________ > HackRF-dev mailing list > [email protected]<mailto:[email protected]> > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > HackRF-dev mailing list > [email protected]<mailto:[email protected]> > 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 <[email protected]> To: [email protected] Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <[email protected]> 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. 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 <[email protected]> > *Sent:* February 13, 2017 10:08:15 AM > *To:* Gavin Jacobs > *Cc:* [email protected] > *Subject:* Re: [Hackrf-dev] release 2017.02.1 > > On 13 February 2017 at 09:35, Gavin Jacobs <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> on behalf of Rustu > Yucel <[email protected] <mailto:[email protected]>> > > Sent: February 11, 2017 10:22:34 PM > > To: Michael Ossmann > > Cc: [email protected] > <mailto:[email protected]> > > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > > >>> [email protected] > <mailto:[email protected]> > > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev> > > > _______________________________________________ > > > HackRF-dev mailing list > > > [email protected] > <mailto:[email protected]> > > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev> > > _______________________________________________ > > HackRF-dev mailing list > > [email protected] > <mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev> > > > > _______________________________________________ > > HackRF-dev mailing list > > [email protected] > <mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > <https://pairlist9.pair.net/mailman/listinfo/hackrf-dev> > > > > > _______________________________________________ > HackRF-dev mailing list > [email protected] > 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 <[email protected]> To: Gavin Jacobs <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <cacx+toakesmvdk8uik0sfoujfiucaooho_g8ysqjdqmjs7e...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 11:56, Gavin Jacobs <[email protected]> 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 <[email protected]> > Sent: February 13, 2017 10:08:15 AM > To: Gavin Jacobs > > Cc: [email protected] > Subject: Re: [Hackrf-dev] release 2017.02.1 > > On 13 February 2017 at 09:35, Gavin Jacobs <[email protected]> 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 <[email protected]> on behalf of Rustu Yucel <[email protected]> > > Sent: February 11, 2017 10:22:34 PM > > To: Michael Ossmann > > Cc: [email protected] > > 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 <[email protected]> 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 <[email protected]> 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 > > >>> [email protected] > > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > _______________________________________________ > > > HackRF-dev mailing list > > > [email protected] > > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > > HackRF-dev mailing list > > [email protected] > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > > HackRF-dev mailing list > > [email protected] > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > HackRF-dev mailing list > [email protected] > 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 <[email protected]> To: James Brown <[email protected]> Cc: hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Signal at IF Message-ID: <CACX+tOZDj6gdDPr-ums0SJ=dqk9zgwuz4onjqjmorgqqnve...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 09:23, James Brown <[email protected]> wrote: > > 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. 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. > I am running the following firmware revisions on the two HackRf: > > 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 <[email protected]> To: Dana Shtun <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] Fwd: Dead Hack RF - Update Message-ID: <CACX+tOYcjR=WaQKMF7a-wx5sYF27dKBA=db7x40ai7eomg7...@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 On 11 February 2017 at 12:05, Dana Shtun <[email protected]> wrote: > > 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 <[email protected]> To: hackrf-dev <[email protected]> Subject: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <CADTrzV=kp5kec80jciji0-hlcof9ohb2df8s7hvz57omp5f...@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 <[email protected]> To: Rustu Yucel <[email protected]> Cc: hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <cacx+tobyu8dd8ys-rwyn_xwjb8donbk85x15q+r+upojdv2...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 13:37, Rustu Yucel <[email protected]> wrote: > > 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 <[email protected]> To: Dominic Spill <[email protected]> Cc: hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <[email protected]> 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 > On 13 Feb 2017, at 23:57, Dominic Spill <[email protected]> wrote: > > On 13 February 2017 at 13:37, Rustu Yucel <[email protected]> wrote: > > > > 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/20170214/712cebcd/attachment-0001.html> ------------------------------ Message: 13 Date: Mon, 13 Feb 2017 14:38:11 -0700 From: Dominic Spill <[email protected]> To: Rustu Yucel <[email protected]> Cc: hackrf-dev <[email protected]> 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" On 13 February 2017 at 14:28, Rustu Yucel <[email protected]> wrote: > > ?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? > On 13 Feb 2017, at 23:57, Dominic Spill <[email protected]> wrote: > > On 13 February 2017 at 13:37, Rustu Yucel <[email protected]> wrote: > > > > 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/eec89933/attachment-0001.html> ------------------------------ Message: 14 Date: Mon, 13 Feb 2017 22:38:47 +0100 From: Alexandru Csete <[email protected]> To: Rustu Yucel <[email protected]> Cc: Dominic Spill <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <CAHG=s_ebp4zbxvavmhf3eomcg72fdqbrvy4xcpntu3gd0go...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 10:28 PM, Rustu Yucel <[email protected]> wrote: > ?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 <[email protected]> To: Dominic Spill <[email protected]> Cc: Rustu Yucel <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <CAHG=S_cotWLBmYTnTSBkZJQ=ef_k3zblmmqztjpxof-dnmr...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 10:38 PM, Dominic Spill <[email protected]> wrote: > On 13 February 2017 at 14:28, Rustu Yucel <[email protected]> wrote: >> >> ?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 <[email protected]> To: Alexandru Csete <[email protected]> Cc: Rustu Yucel <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <cacx+tobhv3jmzukd7rqrjxwm3shlj3r5pabwqxfnsbkq8nk...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 14:38, Alexandru Csete <[email protected]> wrote: > > 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 :-( 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 <[email protected]> To: Dominic Spill <[email protected]> Cc: Rustu Yucel <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <CAHG=S_ewfEoAqH31gK-kU+UL-axEuQYDboisvMxF_4r7k=8...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Mon, Feb 13, 2017 at 10:46 PM, Dominic Spill <[email protected]> wrote: > On 13 February 2017 at 14:38, Alexandru Csete <[email protected]> wrote: >> >> 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 :-( > > 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. Alex ------------------------------ Message: 18 Date: Mon, 13 Feb 2017 15:06:40 -0700 From: Dominic Spill <[email protected]> To: Alexandru Csete <[email protected]> Cc: Rustu Yucel <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <cacx+toa7ovwfepz5hiue12385f-co88-obnt7mkt+76vkh0...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2017 at 14:50, Alexandru Csete <[email protected]> wrote: > > On Mon, Feb 13, 2017 at 10:46 PM, Dominic Spill <[email protected]> wrote: > > On 13 February 2017 at 14:38, Alexandru Csete <[email protected]> wrote: > >> > >> 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 :-( > > > > 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 <[email protected]> To: "[email protected]" <[email protected]> Subject: Re: [Hackrf-dev] release 2017.02.1 Message-ID: <dm5pr22mb0044becf34046883070eef55c6...@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 <[email protected]> Sent: February 13, 2017 12:13:06 PM To: Gavin Jacobs Cc: [email protected] Subject: Re: [Hackrf-dev] release 2017.02.1 On 13 February 2017 at 11:56, Gavin Jacobs <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> > Sent: February 13, 2017 10:08:15 AM > To: Gavin Jacobs > > Cc: [email protected]<mailto:[email protected]> > Subject: Re: [Hackrf-dev] release 2017.02.1 > > On 13 February 2017 at 09:35, Gavin Jacobs > <[email protected]<mailto:[email protected]>> 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 > > <[email protected]<mailto:[email protected]>> > > on behalf of Rustu Yucel > > <[email protected]<mailto:[email protected]>> > > Sent: February 11, 2017 10:22:34 PM > > To: Michael Ossmann > > Cc: > > [email protected]<mailto:[email protected]> > > 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 > > > <[email protected]<mailto:[email protected]>> 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 > > >>> <[email protected]<mailto:[email protected]>> 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 > > >>> [email protected]<mailto:[email protected]> > > >>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > _______________________________________________ > > > HackRF-dev mailing list > > > [email protected]<mailto:[email protected]> > > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > _______________________________________________ > > HackRF-dev mailing list > > [email protected]<mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > > HackRF-dev mailing list > > [email protected]<mailto:[email protected]> > > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > > > > _______________________________________________ > HackRF-dev mailing list > [email protected]<mailto:[email protected]> > 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 <[email protected]> To: Dominic Spill <[email protected]> Cc: Alexandru Csete <[email protected]>, hackrf-dev <[email protected]> Subject: Re: [Hackrf-dev] Why Hackrf only one time run and stop Message-ID: <[email protected]> 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 > On 14 Feb 2017, at 00:46, Dominic Spill <[email protected]> wrote: > > On 13 February 2017 at 14:38, Alexandru Csete <[email protected]> wrote: > > > > 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 :-( > > 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/20170214/08c7e8fe/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev ------------------------------ End of HackRF-dev Digest, Vol 53, Issue 6 ***************************************** _______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
