Great. The amp is not enabled by default, so that you don't cook your receiver in case you have some strong local sources.
Expect a bit more code churn later tonight; I've almost got airspy support working too. On Sun, Jun 28, 2015 at 6:07 PM, Tom <[email protected]> wrote: > Thanks, > > Its running quite well so far, got 6 planes with these settings and 10 > with the lna on. > On 29 Jun 2015 10:58 am, Chris Kuethe <[email protected]> wrote: > > I've adjusted the default gain to 32/48 from 40/62. > > On Sun, Jun 28, 2015 at 5:02 PM, Ilker Temir <[email protected]> wrote: > > Sure, I am glad it's been useful. > > Default gains are the maximums but they can be adjusted from the CLI with > --vga-gain and --lna-gain options. > > On Jun 28, 2015, at 4:44 PM, Tom <[email protected]> wrote: > > Thanks for making this, I think the default vga gain of 60 is quite much, > I had better luck with around 28. > > > > Have only been running it for a few min so I cant compare yet. > > > > > > *From:* HackRF-dev [mailto:[email protected] > <[email protected]>] *On Behalf Of *Ilker Temir > *Sent:* Monday, 29 June 2015 3:16 AM > *To:* [email protected] > *Subject:* Re: [Hackrf-dev] Adding HackRF support to dump1090 > > > > Here it goes: https://github.com/itemir/dump1090_hackrf > > I can get some reception from my window with the standard HackRF antenna. > > Ilkers-MacBook-Pro:dump1090_hackrf itemir$ ./dump1090 > No supported RTLSDR devices found. > HackRF successfully initialized (AMP Enable: 0, LNA Gain: 40, VGA Gain: > 62). > *5dab7437d7920a; > CRC: d7920a (ok) > Single bit error fixed, bit 10 > DF 11: All Call Reply. > Capability : Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne) > ICAO Address: ab7437 > > *5fa69b92ccd411; > CRC: ccd411 (ok) > Single bit error fixed, bit 13 > DF 11: All Call Reply. > Capability : Level 7 ??? > ICAO Address: a69b92 > > *5dab9091529b68; > CRC: 529b68 (ok) > Single bit error fixed, bit 24 > DF 11: All Call Reply. > Capability : Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne) > ICAO Address: ab9091 > > Feedback and contributions welcome. > > On 6/27/15 7:27 PM, Tom wrote: > > Well done. > > > > Look forward to trying this out. > > > > *From:* HackRF-dev [mailto:[email protected] > <[email protected]>] *On Behalf Of *Ilker Temir > *Sent:* Sunday, 28 June 2015 11:49 AM > *To:* Donald Pupecki > *Cc:* [email protected] > *Subject:* Re: [Hackrf-dev] Adding HackRF support to dump1090 > > > > Thanks! signed to unsigned conversion was the culprit. I first tested it > with cox by converting the file and then tweaked my code to do that within > the receive path. > > I now have a working port of dump1090 to HackRF. I need to do some cleanup > but as soon as done, will post it on GitHub and announce on this forum. > > On 6/27/15 1:29 PM, Donald Pupecki wrote: > > I don't believe hackrf_transfer and rtl_sdr output in the same format. > They are both 8 bit but the hackrf output is signed whereas the rtl output > is unsigned. > > If you get this working a hackrf please post the port on github or > somewhere as that would be sweet. > > On Jun 27, 2015 4:00 PM, "Ilker Temir" <[email protected]> wrote: > > Hello, > > I am trying to add HackRF support to Salvatore Sanfilippo's dump1090 tool ( > https://github.com/antirez/dump1090) as a learning exercise. The tool was > originally designed for RTL SDR devices. However, I can't seem to get this > port to work. > > To eliminate potential issues in my code, I simplified the troubleshooting > steps. Here are the basic set of troubleshooting steps I am using: > > Per tool's documentation, a data file can be captured with rtl_sdr utility > in the following way: > > rtl_sdr -f 1090000000 -s 2000000 -g 50 output.bin > > Then you can pipe it into dump1090 like this: > dump1090 --ifile output.bin > > I made an assumption that the HackRF equivalent of rtl_sdr command above > would be the following: > > hackrf_transfer -r output.bin -f 1090000000 -s 2000000 -p 0 -a 0 > -l 40 -g 62 > > However, capturing packets with HackRF this way and piping them into > dump1090 doesn't do anything. I have tried this sitting next to an airport > and capturing packets while planes were landing and taking off. I don't > have an RTL SDR dongle so I can't test the rtl_sdr command myself. It > didn't make to sense to buy a RTL SDR device after HackRF but if I can't > crack this, I am considering to buy one. > > BTW, I also tried different gain settings, and sample rate of 8e6 with > hackrf_transfer, no difference. That said, I never enabled amp_enable. > > Would anyone know if rtl_sdr and hackrf_transfer capture the packets in > the same way and format? Or do I need to do some kind of a conversion or > translation in between the two to make them compatible? > > Any help or idea will be appreciated. > > P.S. I am aware of gr-air-modes for HackRF to decode ADS-B signals. My > goal is to hack dump1090 and add HackRF support as a learning exercise. > > Thanks, > > Ilker > > > _______________________________________________ > 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 > > > > > -- > GDB has a 'break' feature; why doesn't it have 'fix' too? > > -- GDB has a 'break' feature; why doesn't it have 'fix' too?
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
