Re: [Hackrf-dev] Air relay ADS-B to BTLE: How to add UART LCD and build

[Chuck McManis]

The arm-none-eabi compiler in the packages repo is an abomination :-)
get the one from launchpad, be sure to apt-get add gcc-multilib and
put the compiler in your path, done! Bonus because it is maintained by
ARM and comes with both newlib and newlib-nano specs for really small
code size.

--Chuck


On Tue, Sep 1, 2015 at 11:44 AM, Jiao Xianjun  wrote:
> Hi,
>
> I am planing to open my firmware in several steps. Here is the first step.
>
> (See detailed introduction here: http://sdr-x.github.io/UART1602LCD/ )
>
> When modifying firmware of HACKRF, debugging method is important. Actually
> you may add 1602LCD module and UART to hackrf board without changing
> anything of the board itself. Here are introduction and demo.
>
> 1. Hardware connection
>
> You should have 1602 LCD module and/or USB-UART dongle in your hand. The two
> things are very popular, you may google their information easily.
>
> 1602LCD HACKRF pin connection:
>
>   HACKRF P20 20 -- 1602LCD pin11
>   HACKRF P20 18 -- 1602LCD pin12
>   HACKRF P20 16 -- 1602LCD pin13
>   HACKRF P20 14 -- 1602LCD pin14
>   HACKRF P20 11 -- 1602LCD pin6
>   HACKRF P20  9 -- 1602LCD pin5
>   HACKRF P20  7 -- 1602LCD pin4
>   HACKRFVCC -- 1602LCD pin2 pin15
>   HACKRFGND -- 1602LCD pin1 pin3 pin16
>
> UART HACKRF pin connection:
>
>   HACKRF P25 1 GND-- GND of computer or USB-uart dongle
>   HACKRF P25 4 UART0 RXD  -- TXD of computer or USB-uart dongle
>   HACKRF P25 5 UART0 TXD  -- RXD of computer or USB-uart dongle
>
> For HACKRF P20 and P25 location and definition, you can refer to
> hackrf-one-assembly.pdf and hackrf-one-schematic.pdf in original HACKRF
> github repo.
>
> Photo of my 1602 LCD module connection
>
> Photo of my USB-UART dongle connection
>
> 2. Code example and demo
>
> After some struggling in dark, I finally can present you quite simple code
> to output information via UART or 1602 LCD screen.
>
> All you need are two files: CMakeLists.txt and hackrf_uart_1602lcd.c
>
> Put them in a new created directory hackrf_uart_1602lcd in firmware
> directory of original hackrf github repo, and build the hackrf_uart_1602lcd
> project (See part 3 for build method).
>
> I already put a workable code example here: hackrf-UART-1602LCD
>
> A firmware hackrf_uart_1602lcd.dfu is also put into
> firmware/hackrf_uart_1602lcd/build/ of above repo in case someone want to
> try it in RAM via DFU mode without building firmware.
>
> Here is a demo photo of the firmware running
>
> 3. Build firmware of above code by yourself
>
> Basically you can follow instructions in README of firmware directory in
> original HACKRF github repo to build firmware. For example:
>
>   cd firmware/hackrf_uart_1602lcd
>   mkdir build
>   cd build
>   cmake .. -DRUN_FROM=RAM
>   make
>   dfu-util --device 1fc9:000c --alt 0 --download hackrf_uart_1602lcd.dfu
>   (before dfu-util, make sure set your board into DFU mode)
>
> But somehow I need to do following things to make sure build go smoothly. If
> you can't build firmware, maybe you can give it a shot.
>
> remove "-s 0" in the line of hackrf-common.cmake: (here is a
> hackrf-common.cmake which is already modified)
>
>   COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu
>
> add "COMMAND dfu-prefix -s 0 -a _tmp.dfu" after above line in
> hackrf-common.cmake.
>
> Maybe you need to install this: git://gitorious.org/dfu-util/dfu-util.git (I
> already put one here dfu-util.tar.gz)
>
> Maybe you need this: sudo apt-get install python-yaml
>
> sudo apt-get install gcc-arm-none-eabi -- This compiler NOT WORK!!!
>
> USE THIS compiler!!! -->
> https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded
>
> !!! If you are using Ubuntu 14.04 and later, please be careful because there
> are packages with same name but produced by Debian and inherited by Ubuntu.
> Simply follow the above 3 steps, you may end up with gcc-arm-none-eabi from
> Ubuntu. So to install gcc-arm-none-eabi from ARM, steps are:
>
>   1). sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
>   2). sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
>   3). sudo apt-get update
>   4). sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q1-0trusty13
>   or
>   sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q1-0utopic14
>
> If you encounter some command not found error, maybe you need:
>
>   cd /usr/lib/arm-none-eabi
>   sudo ln -s /usr/arm-none-eabi/bin bin
>
>
>
> On Sun, Jul 12, 2015 at 10:03 AM, Michael Ossmann  wrote:
>>
>> On Sun, Jul 12, 2015 at 01:00:53AM +, Jason Cooper wrote:
>> >
>> > I should clarify:  I know about the various AIS SDR implementations
>> > out there.  I'm interested in running code on the hackrf with just a
>> > battery pack.  UI being my $mobile_device.
>>
>> That's why I mentioned the PortaPack implementation.  It runs on the
>> ARM.
>>
>> Mike
>
>
>
> ___
> HackRF-dev mailing list
> HackRF-dev@greatscottgadgets.com
> https://pairlist9.pair.net/

Re: [Hackrf-dev] Air relay ADS-B to BTLE: How to add UART LCD and build

[Jiao Xianjun]

Hi,

I am planing to open my firmware in several steps. Here is the first step.

(See detailed introduction here: http://sdr-x.github.io/UART1602LCD/ )

When modifying firmware of HACKRF, debugging method is important. Actually
you may add 1602LCD module and UART to hackrf board without changing
anything of the board itself. Here are introduction and demo.
1. Hardware connection

You should have 1602 LCD module and/or USB-UART dongle in your hand. The
two things are very popular, you may google their information easily.

1602LCD HACKRF pin connection:

  HACKRF P20 20 -- 1602LCD pin11
  HACKRF P20 18 -- 1602LCD pin12
  HACKRF P20 16 -- 1602LCD pin13
  HACKRF P20 14 -- 1602LCD pin14
  HACKRF P20 11 -- 1602LCD pin6
  HACKRF P20  9 -- 1602LCD pin5
  HACKRF P20  7 -- 1602LCD pin4
  HACKRFVCC -- 1602LCD pin2 pin15
  HACKRFGND -- 1602LCD pin1 pin3 pin16

UART HACKRF pin connection:

  HACKRF P25 1 GND-- GND of computer or USB-uart dongle
  HACKRF P25 4 UART0 RXD  -- TXD of computer or USB-uart dongle
  HACKRF P25 5 UART0 TXD  -- RXD of computer or USB-uart dongle

For HACKRF P20 and P25 location and definition, you can refer to
hackrf-one-assembly.pdf

and hackrf-one-schematic.pdf

in original HACKRF github repo .

Photo of my 1602 LCD module connection


Photo of my USB-UART dongle connection

2. Code example and demo

After some struggling in dark, I finally can present you quite simple code
to output information via UART or 1602 LCD screen.

All you need are two files: CMakeLists.txt

and hackrf_uart_1602lcd.c


Put them in a new created directory hackrf_uart_1602lcd

in firmware directory of original hackrf github repo, and build the
hackrf_uart_1602lcd project (See part 3 for build method).

I already put a workable code example here: hackrf-UART-1602LCD


A firmware hackrf_uart_1602lcd.dfu

is also put into firmware/hackrf_uart_1602lcd/build/

of above repo  in case
someone want to try it in RAM via DFU mode without building firmware.

Here is a demo photo of the firmware running

3. Build firmware of above code by yourself

Basically you can follow instructions in README
 of
firmware directory in original HACKRF github repo
 to build firmware. For example:

  cd firmware/hackrf_uart_1602lcd
  mkdir build
  cd build
  cmake .. -DRUN_FROM=RAM
  make
  dfu-util --device 1fc9:000c --alt 0 --download hackrf_uart_1602lcd.dfu
  (before dfu-util, make sure set your board into DFU mode)

But somehow I need to do following things to make sure build go smoothly.
If you can't build firmware, maybe you can give it a shot.

remove "-s 0" in the line of hackrf-common.cmake: (here is a
hackrf-common.cmake

which is already modified)

  COMMAND dfu-suffix --vid=0x1fc9 --pid=0x000c --did=0x0 -s 0 -a _tmp.dfu

add "COMMAND dfu-prefix -s 0 -a _tmp.dfu" after above line in
hackrf-common.cmake.

Maybe you need to install this: git://gitorious.org/dfu-util/dfu-util.git
(I already put one here dfu-util.tar.gz

)

Maybe you need this: sudo apt-get install python-yaml

sudo apt-get install gcc-arm-none-eabi -- *This compiler NOT WORK!!!*

*USE THIS compiler!!!* -->
https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded


!!! If you are using Ubuntu 14.04 and later, please be careful because
there are packages with same name but produced by Debian and inherited by
Ubuntu. Simply follow the above 3 steps, you may end up with
gcc-arm-none-eabi from Ubuntu. So to install gcc-arm-none-eabi from ARM,
steps are:

  1). sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
  2). sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
  3). sudo apt-get update
  4). sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q1-0trusty13
  or

Re: [Hackrf-dev] Odd issue on running hackrf_transfer multiple times in a row

[Shannon Holland]

No idea why I didn’t get all of your previous email - from the list archives it 
clearly was very different than what I got (should have thought to check the 
archives). This one is fine though :) Stupid Macs!


> On Sep 1, 2015, at 8:32 AM, Dominic Spill  wrote:
> 
> Good point!  Although the greater range of values in the first capture
> is still something that I would like to look at.  Also, the very small
> range of values that you see overall.

I was able to get the test mode (for standard rate bluetooth) going with the 
uberttooth which gave me a much stronger signal to look at. I also shifted the 
frequency to be a 1Mhz offset from the BT channel I was looking at to remove 
the DC offset issues. This got me to a much happier place where I was able to 
receive something that clearly wasn’t noise.

But, doesn’t resolve the odd issues I was seeing earlier…

In response to your question regarding HACKRF_ERROR_STREAMING_EXIT_CALLED: that 
seems to be a function of specifying a sample count. If I just leave the 
transfer running and ctrl-c I’m not seeing this. However, either case produces 
similar results.

> 
>> I’ve played with different rx gain settings (as well as turning the antenna 
>> amp on and off) and really see very little change in the recorded data. 
>> Looking at a FFT waterfall (using baudline) I do see an changes but am still 
>> not having any luck finding any sort of apparent signal from all the noise. 
>> Switching antennas did help a bit.
> 
> What are you using for your antenna?

I was initially using the ubertooth antenna (with adapters). I’ve switched to a 
higher gain 2.4Ghz antenna (which also helped). No idea what the real specs on 
this one are however.

> Yes.  There is a transmit test in the firmware, it can be enabled from
> ubertooth-util.  You can also produce test patterns from CSR Bluetooth
> dongles using the bccmd tool, which is how I was able to write the
> first version of gr-bluetooth.

Thank you! I got the ubertooth-util tx test going (which helped a lot). I’ll 
check out the CSR dongles as well - don’t think I have one laying around but 
they look cheap :)

> That code is quite old, but I don't think it should be too much effort
> to get it working with libbtbb (the Bluetooth baseband library).  It's
> definitely on my list of projects to revive but it's not going to
> happen very soon.  Any help would be gladly received; pull requests
> are especially welcome.

I’ll take another look and see if I can figure out what’s up - I really didn’t 
do much more before than just try to run it and see the exception.

> 
>> Any suggestions as to what I can do to improve things on the Rx side would 
>> be greatly appreciated!
> 
> Could you try some simple reception tasks with the HackRF, e.g. FM [1]
> or ADS-B [2] ?  I think that will give us a better idea of whether the
> radio is working correctly.  We can then address the out of date
> gr-bluetooth code.

I think I have that issue resolved with the ubertooth transmit test. I can try 
out the FM Rx test tonight when I get home (I don’t have a suitable antenna 
here at work).

Thank you!

Shannon

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

Re: [Hackrf-dev] Odd issue on running hackrf_transfer multiple times in a row

[Dominic Spill]

On 29 August 2015 at 13:46, Shannon Holland  wrote:
>
> The first set of readings would still appear to have a larger dynamic range 
> by just looking at numbers (the real part bumping between 02->04->f9 verus 
> 02->03->02) but I’m also wondering if part of the difference I’m seeing is a 
> change in DC offset?

Good point!  Although the greater range of values in the first capture
is still something that I would like to look at.  Also, the very small
range of values that you see overall.

> I’ve played with different rx gain settings (as well as turning the antenna 
> amp on and off) and really see very little change in the recorded data. 
> Looking at a FFT waterfall (using baudline) I do see an changes but am still 
> not having any luck finding any sort of apparent signal from all the noise. 
> Switching antennas did help a bit.

What are you using for your antenna?

> can I generate a controlled transmit pattern from the ubertooth?

Yes.  There is a transmit test in the firmware, it can be enabled from
ubertooth-util.  You can also produce test patterns from CSR Bluetooth
dongles using the bccmd tool, which is how I was able to write the
first version of gr-bluetooth.

> Dominic, I did find your excellent report on implementing a software 
> Bluetooth stack in gnu radio. I’ve installed the gr-bluetooth modules but 
> haven’t had a whole lot of luck getting them to run just yet (I was trying 
> the included test samples but am getting a python error 'AttributeError: 
> 'module' object has no attribute ‘multi_LAP’ - haven’t looked into that yet).

That code is quite old, but I don't think it should be too much effort
to get it working with libbtbb (the Bluetooth baseband library).  It's
definitely on my list of projects to revive but it's not going to
happen very soon.  Any help would be gladly received; pull requests
are especially welcome.

> Any suggestions as to what I can do to improve things on the Rx side would be 
> greatly appreciated!

Could you try some simple reception tasks with the HackRF, e.g. FM [1]
or ADS-B [2] ?  I think that will give us a better idea of whether the
radio is working correctly.  We can then address the out of date
gr-bluetooth code.

Dominic

[1] http://greatscottgadgets.com/sdr/1/ (there's an FM Rx GRC
flowgraph in the resources section of the page).
[2] https://github.com/itemir/dump1090_sdrplus
___
HackRF-dev mailing list
HackRF-dev@greatscottgadgets.com
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev