One of the sensors I want to have available for the "DriveBy" PLN project is an onboard Digital Compass that Beaglebone Black can poll so that I can have live Compass on it's Web GUI.
This is what I chose to use.
It has already shipped and should arrive probably next week I suppose. It will connect to the BBB via the 10-port USB hub I have that already is working out GREAT!
Friday, November 21, 2014
Tethering Android and BeagleBone Black Ubuntu 14.04 that actually works
You can find details here
This is what I ended up doing to make it work for me:
On the Android Phone: Settings -> More Networks -> Tethering -> USB Tethering (Checked ON)
On Beaglebone Black:
This is what I ended up doing to make it work for me:
On the Android Phone: Settings -> More Networks -> Tethering -> USB Tethering (Checked ON)
On Beaglebone Black:
- Boot BBB
- Set Tethering ON in Android
- via ssh to BBB
- modprobe g_ether;
- ip link set usb0 up && dhcpcd usb0;
OTHER RANDOM NOTES NOT REALLY REQUIRED
- sudo su
- apt-get install traceroute iptables
- ifconfig usb0 up
- modprobe g_ether
- echo 1 > /proc/sys/net/ipv4/ip_forward
- iptables -t nat -F
- iptables -t nat -A POSTROUTING -j MASQUERADE
- dhcpcd usb0
- ip link set usb0 up && dhcpcd usb0
- ifconfig usb0 (check to see if you got a valid ip set now)
- ping www.google.com (test that dns and routing it working
- traceroute www.google.com (make sure we're actually using USB0 and not ETH0)
Sunday, November 16, 2014
Beaglebone Black & RTL Dongles Used Drive Testing Power Line Noise
So I've already mentioned before that I wanted to use some very inexpensive equipment to perform some Drive Testing experiments. Basically I want to measure Noise Floor in 4 Ham Radio Bands (50 Mhz, 144 Mhz, 222 Mhz, and 432 Mhz) while I drive all around Town. While this is happening I want to record GeoLocation for each reading logged, and plot on a map where the worst areas are, so that I can then return to those areas and try to hunt down the sources of the noise.
NOTE: all that's really left is to calibrate the NF measurements (obviously -78db and -34db reading aren't valid, but a little calibration and it'll be good to go)
I have the basic's of this system working now! I haven't actually done any drive testing yet, but I intend to very soon.
My experiments so far from home are very encouraging!
I've built a little Web interface which displays things like:
NOTE: all that's really left is to calibrate the NF measurements (obviously -78db and -34db reading aren't valid, but a little calibration and it'll be good to go)
I have the basic's of this system working now! I haven't actually done any drive testing yet, but I intend to very soon.
My experiments so far from home are very encouraging!
I've built a little Web interface which displays things like:
- System Load (of the beaglebone black)
- Disk space usage (of the beaglebone black for a mounted SD card which I store logged data to.
- There is a basic control panel which lets me start/stop the GPS, and Various attached RTL dongles. This process also moves logs to archive them when these processes are stopped.
- There areas in the web UI which show me GPS data logged, RTL Noise Floor measurements as they are made (live).
- There is a Google Map API which plots the Lat/Long and Noise Floor measurements for the recorded data. This allows me to then return to areas where Noise measurements where high.
My current GPS has a fair amount of 'drift' however it doesn't seem to exceed about 50 feet from the actual position. And for my initial test runs of this this is perfectly acceptable. Since this is still proof of concept. This gps only cost about $38.00 USD. So nice and cheap.
I have a Jackson Labs "FURY" GPS which cost me $380.00 some years ago, and is WAY more accurate. I intend to use that eventually. That should be FAIRLY simple! I just need to get a snap-on Serial Port for the Beaglebone black, or a USB/Serial port to connect it up. And 'gpsd' should work with it just fine.
Anyway I wanted to post that I've been busily working on this the past week or so. And today I can report I have 100% success on getting everything functional enough to begin actual drive testing within a week or so.
I'll post some video's of what I have currently running, as well as some still photo's of how it all is connected up soon.
73!
----------------------------------------------------------------------------------------------------------------
VIDEO OF RUNNING TEST:
STILL IMAGES OF THIS SETUP:
----------------------------------------------------------------------------------------------------------------
VIDEO OF RUNNING TEST:
STILL IMAGES OF THIS SETUP:
Monday, November 10, 2014
Working on Beaglebone Black, HackRF, GNURADIO + Ubuntu 14.04 ISO
Today I started work on building a working version of Ubuntu 14.04 LTS on Beaglebone Black with all the necessary stuff to run GNURADIO and HackRF. I tried a pre-built version of this recently that kinda 1/2 worked. So since I can't seem to get a fire lit under that version, I've decided to create my own.
Here is what I've done so far and it currently building as I write this. So I'll post updates on this post as they occur beyond what I have so far.
MICROSD INSTALLATION (REALLY PRETTY SIMPLE! Follow directions, requires access to a Linux OS)
SOME USEFUL URLS I found:
NOT THIS>>>https://github.com/mossmann/hackrf/wiki/Installing-gnuradio-on-Ubuntu-14.04-with-the-packaging-manager
NOT THIS>>>would have been nice by these packages aren't available in the ppa for 'armhf' devices :(
GNURADIO INSTALL VIA PYBOMBS
http://gnuradio.org/redmine/projects/pybombs/wiki
*** A note about Xwindows and SSH - BEGIN ***
I use a Windows 7 PC for my primary Desktop computer. I use SecureCRT for SSH from this computer to various things I need to SSH to.
In order to see various GUI's from the BeagleBone Black that are run under 'X' There are a few things I need to do in order to see the 'X' windows generated by this BeagleBone and Ubuntu setup.
In secureCRT check 'Forward X11 Packets' under "Connection" > "Port Forwarding".
Install "Xming": http://sourceforge.net/projects/xming/ Run xming on windows. SSH into BBB and try running something that requires 'X'. That's it. Works. Very simple. The key is having a local (on windows) "X server" running, and that your SSH client supports forwarding X11 Packets.
*** A note about Xwindows and SSH - END ***
=====================================================================
Insert your new Ubuntu 14.04 LTS MicroSD (created USING THESE directions)
CONNECT YOUR DHCP Network RJ45 to the BBB. (you'll need to locate the IP to SSH to from your DHCP/Router's list of connected devices mine shows up as 'ubuntu-armhf'. SSH to it like you would any normal port 22 ssh connection.
SSH to your BBB (U: ubuntu, P: ubuntu)
sudo su -
apt-get update
apt-get install software-properties-common python-software-properties
add-apt-repository ppa:gqrx/releases (you probably don't really need this)
apt-get update
apt-get upgrade
= Required for 'pybombs install'
apt-get install git
apt-get install python-qt4
apt-get install python-scipy
=====================================================================
= SET A TEMP SWAP FILE (you may not really need this but I suspect we will since we'll be doing a fair
= amount of COMPILING next. I tried without swap installed and with makewidth=4 (default) and the
= compiler ran out of memory.
=
= Running SWAP on a FLASH device is a BAD BAD idea. Great way to use up the limited lifetime of read/writes
= available on the device. Once you are done with all the compiling you'll want to disable this again!!!!
=
= Now, let's set up your swapfile.
=
cd /
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s
Ok, now you have a 2GB swapfile and it is enabled. Let's make it permanent.
# vi /etc/fstab
(add at the last line):
/swapfile none swap sw 0 0
SAVE....
(We'll remove this after we all done with compiling)
=====================================================================
cd /usr/local/src
git clone https://github.com/pybombs/pybombs.git && cd pybombs
EDIT: vi /usr/local/src/pybombs/config.dat
(CHANGE makewidth=4 to):
makewidth = 1
SAVE FILE
=====================================================================
= NOTE: THIS WILL TAKE A LONG WHILE!
=====================================================================
./app_store.py
SELECT
'gnuradio'
'gqrx'
'gr-osmosdr'
'hackrf'
NOTE: Your SSH TERM will be showing things that look like this...this is pretty normal.
NOTE: To return app_store.py you can cd /usr/local/src/pybombs/;./app_store.py anytime ALSO if your x access isn't working you can install packages with: ./pybomb install <package name>
GNURADIO compile via 'app_store.py' takes HOURS like this 6-10 hours at least. But it does complete! Probably could use 2-3 threads with the SWAP available, but I doubt it would much faster since there's only a SINGLE CORE.
SO after that error:
http://lists.nongnu.org/archive/html/discuss-gnuradio/2014-09/msg00248.html
cd /usr/local/src/pybombs/src/gnuradio/build/volk
cmake ../ -DCMAKE_C_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15" -DCMAKE_ASM_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15"
make
cd ..
make
Back to building again....(hope this works)....stay tuned....
About 8 hours after that.....This completed.
make install
./pybombs env
vi ~/bashrc
(at the bottom add)
source /usr/local/src/target/setup_env.sh
(save the file)
./pybombs install hackrf
./pybombs install gr-osmocom
./pybombs install osmo-sdr
Stop and see how things work now.... be back when I'm done checking the install out so far.
Anyway, I'm still waiting for volk_profile to work its magic while the single core BBB is crunching away on it. More when that completes.
SUCCESS!
After all this...I'm FINALLY able to access the HackRF via GNURADIO on my Beaglebone Black!
I'll post more info soon!
For all users to have access to the attached hackrf device follow This Guide
FYI on my BBB with Ubuntu 14.04 I had to use:
cp /usr/local/src/pybombs/src/hackrf/host/libhackrf/53-hackrf.rules /etc/udev/rules.d/.
then
udevadm control --reload-rules
then sudo vi /etc/group
next to the line with 'plugdev' I added 'ubuntu' to add the 'ubuntu' user to this group.
<save the file>
then
reboot now
And this worked as seen here:
ubuntu@ubuntu-armhf:~$ hackrf_info
Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: git-44df9d1
Part ID Number: 0xa000cb3c 0x0056434c
Serial Number: 0x00000000 0x00000000 0x457863c8 0x2e3d991f
Now gnuradio-companion will be able to access the hackrf device when being run by the user ubuntu.
Any further posts about this will be in NEW posts. This one is closed now.
Here is what I've done so far and it currently building as I write this. So I'll post updates on this post as they occur beyond what I have so far.
MICROSD INSTALLATION (REALLY PRETTY SIMPLE! Follow directions, requires access to a Linux OS)
SOME USEFUL URLS I found:
- http://www.armhf.com/boards/beaglebone-black/bbb-sd-install/
- http://www.kd0cq.com/2014/08/expand-partition-and-create-swap-file-on-beaglebone-black-ubuntu-sdr-img/
- http://www.celestialphotographer.com/2014/09/17/pybombs-gnuradio/
NOT THIS>>>https://github.com/mossmann/hackrf/wiki/Installing-gnuradio-on-Ubuntu-14.04-with-the-packaging-manager
NOT THIS>>>would have been nice by these packages aren't available in the ppa for 'armhf' devices :(
GNURADIO INSTALL VIA PYBOMBS
http://gnuradio.org/redmine/projects/pybombs/wiki
*** A note about Xwindows and SSH - BEGIN ***
I use a Windows 7 PC for my primary Desktop computer. I use SecureCRT for SSH from this computer to various things I need to SSH to.
In order to see various GUI's from the BeagleBone Black that are run under 'X' There are a few things I need to do in order to see the 'X' windows generated by this BeagleBone and Ubuntu setup.
In secureCRT check 'Forward X11 Packets' under "Connection" > "Port Forwarding".
Install "Xming": http://sourceforge.net/projects/xming/ Run xming on windows. SSH into BBB and try running something that requires 'X'. That's it. Works. Very simple. The key is having a local (on windows) "X server" running, and that your SSH client supports forwarding X11 Packets.
*** A note about Xwindows and SSH - END ***
=====================================================================
Insert your new Ubuntu 14.04 LTS MicroSD (created USING THESE directions)
CONNECT YOUR DHCP Network RJ45 to the BBB. (you'll need to locate the IP to SSH to from your DHCP/Router's list of connected devices mine shows up as 'ubuntu-armhf'. SSH to it like you would any normal port 22 ssh connection.
SSH to your BBB (U: ubuntu, P: ubuntu)
sudo su -
apt-get update
apt-get install software-properties-common python-software-properties
add-apt-repository ppa:gqrx/releases (you probably don't really need this)
apt-get update
apt-get upgrade
= Required for 'pybombs install'
apt-get install git
apt-get install python-qt4
apt-get install python-scipy
=====================================================================
= SET A TEMP SWAP FILE (you may not really need this but I suspect we will since we'll be doing a fair
= amount of COMPILING next. I tried without swap installed and with makewidth=4 (default) and the
= compiler ran out of memory.
=
= Running SWAP on a FLASH device is a BAD BAD idea. Great way to use up the limited lifetime of read/writes
= available on the device. Once you are done with all the compiling you'll want to disable this again!!!!
=
= Now, let's set up your swapfile.
=
cd /
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s
Ok, now you have a 2GB swapfile and it is enabled. Let's make it permanent.
# vi /etc/fstab
(add at the last line):
/swapfile none swap sw 0 0
SAVE....
(We'll remove this after we all done with compiling)
=====================================================================
cd /usr/local/src
git clone https://github.com/pybombs/pybombs.git && cd pybombs
EDIT: vi /usr/local/src/pybombs/config.dat
(CHANGE makewidth=4 to):
makewidth = 1
SAVE FILE
=====================================================================
= NOTE: THIS WILL TAKE A LONG WHILE!
=====================================================================
./app_store.py
SELECT
'gnuradio'
'gqrx'
'gr-osmosdr'
'hackrf'
NOTE: Your SSH TERM will be showing things that look like this...this is pretty normal.
NOTE: To return app_store.py you can cd /usr/local/src/pybombs/;./app_store.py anytime ALSO if your x access isn't working you can install packages with: ./pybomb install <package name>
GNURADIO compile via 'app_store.py' takes HOURS like this 6-10 hours at least. But it does complete! Probably could use 2-3 threads with the SWAP available, but I doubt it would much faster since there's only a SINGLE CORE.
http://lists.nongnu.org/archive/html/discuss-gnuradio/2014-09/msg00248.html
cd /usr/local/src/pybombs/src/gnuradio/build/volk
cmake ../ -DCMAKE_C_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15" -DCMAKE_ASM_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15"
make
cd ..
make
Back to building again....(hope this works)....stay tuned....
About 8 hours after that.....This completed.
make install
./pybombs env
vi ~/bashrc
(at the bottom add)
source /usr/local/src/target/setup_env.sh
(save the file)
./pybombs install hackrf
./pybombs install gr-osmocom
./pybombs install osmo-sdr
Stop and see how things work now.... be back when I'm done checking the install out so far.
"minutes" ? LOL try hours....
Ok so it's painfully obvious that this is REALLY not the best way to build for the ARM based OS. All of this is seriously SLOW. And by the time this done the SD card I'm using will probably be scrapped due to an overuse of read/write from the SWAP partition I've been using. BUT....
If this is ultimately successful at least I'll be able to create an ISO image that I can reuse for the short term.
I think next steps will be to use one of my larger RISC based CPU Linux boxes and do cross-compiling to the ARM based system. I have several 24 core, 24Gb Linux servers I can use to do this. And these builds would probably complete in total within about 15 minutes instead of DAYS.
Anyway, I'm still waiting for volk_profile to work its magic while the single core BBB is crunching away on it. More when that completes.
SUCCESS!
After all this...I'm FINALLY able to access the HackRF via GNURADIO on my Beaglebone Black!
I'll post more info soon!
For all users to have access to the attached hackrf device follow This Guide
FYI on my BBB with Ubuntu 14.04 I had to use:
cp /usr/local/src/pybombs/src/hackrf/host/libhackrf/53-hackrf.rules /etc/udev/rules.d/.
then
udevadm control --reload-rules
then sudo vi /etc/group
next to the line with 'plugdev' I added 'ubuntu' to add the 'ubuntu' user to this group.
<save the file>
then
reboot now
And this worked as seen here:
ubuntu@ubuntu-armhf:~$ hackrf_info
Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: git-44df9d1
Part ID Number: 0xa000cb3c 0x0056434c
Serial Number: 0x00000000 0x00000000 0x457863c8 0x2e3d991f
Now gnuradio-companion will be able to access the hackrf device when being run by the user ubuntu.
Any further posts about this will be in NEW posts. This one is closed now.
Saturday, November 8, 2014
Using GNURADIO-Companion and HackRF One as a CW beacon
This is just some testing I'm doing to learn really. I doubt this is the best way to do it, but it's ONE WAY that seems to be fairly simple.
In my next test for this I'll move to running this same flow-graph on the Beaglebone Black and see how well it performs. I'll post an update for that test on this posting below...once I've done it.
NOTE: I have noticed some fairly minor carrier drift as the hackrf gets warmed up. At these levels it doesn't get warm to the touch at all. But I assume it's related to internal warming. Regardless I think this can be overcome using a GPSDO and a 10Mhz clock signal into the HackRF. It already has SMA connectors ready for that, and I intend to try to do that soon as well and retest this again to see if I see any drift.
I'm constantly learning stuff with this, and I'm sure I'm probably not going about this the best way, but it does seem to work just fine. I'll post the GRC I'm using and details on how I got the WAV File Source setup in a while. (hint that's SUPER EASY!)
- THIS SITE will generate a WAV file @ "128 kb/sec bitrate, 8 kHz sample rate, 16 bit sample size, single channel, pulse-code modulated audio."
- Convert the sample rate down to 48kb/sec here
- Now you have your WAV FILE SOURCE for GNURADIO.
- Get this FILE. (grc file)
- Start up GNURADIO and open the GRC file noted above.
- Edit the WAV FILE SOURCE and change the path to that of the WAV FILE you created above.
- Click to generate the flow-graph.
- Click to run the flow-graph.
- Done.
Friday, November 7, 2014
Multi-Beacon Test using Beaglebone Black & HackRF One
I wanted to just do a simple loop test using hackrf_transfer and two beacon frequencies. One was on 50 Mhz and the other was on 144 Mhz, and the bash script just looped back and forth between both bands. The script had a few little hiccups, I added a 2sec sleep between transmissions which helped a bit, but hackrf_transfer running on Beaglebone Black appears to randomly stop returning to the command prompt. THIS COULD JUST BE, RF getting into the BBB as it seemed to happen on 144 Mhz transmissions only. Anyway, it wasn't terrible. For a simple IQ recording that was made on 50 Mhz.
I also tested running this on all bands from 80m to 23cm! LOL worked just fine for the most part.
Here is are the commands I used:
You can basically record on any frequency and it appears any mode. I believe this is just capturing the IQ. Once that's been capture you can retransmit whatever it was you recorded to file. In this case it was just USB-CW centered on 50.075.2 Mhz. On the Beaglebone Black I had to really drop the sample-rate down (-s) and I used -n 30,000,000 samples to stop it automatically around 15 seconds total was recorded in this time.
I used my FTDX-5000 to generate the signal I was recording. The message sent was "DE NW0W NW0W EM47 EM47 DE NWOW EM47 K" (or something close to that anyway)
hackrf_transfer -r /tmp/nw0w_bcn -n 30000000 -f 50075200 -l 32 -g 28 -b 1000000 -s 2000000
I found if I set the -s <sample rate> too fast it would chop the CW badly in places (randomly) even with nothing else running on the Beaglebone Black at the time. It really doesn't matter a ton, since 2Msps is more than enough to get a really nice recorded IQ message.
========================================================================
My RX cabability Ends about 1.7 Ghz - I couldn't test any higher at than this point
========================================================================
-- below here I verified with an RTL Dongle and SDR# --
1296 Ghz: hackrf_transfer -t /tmp/nw0w_bcn -f 1296848550 -x 20 -b 1000000 -s 2000000 (found @ 1296.850 Mhz)
903 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 903949050 -x 10 -b 1000000 -s 2000000 (found @ 903.950 Mhz)
432 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 432300965 -x 10 -b 1000000 -s 2000000 (found @ 432.301 Mhz)
222 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 222059350 -x 10 -b 1000000 -s 2000000 (found @ 222.059 Mhz)
144 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 144275590 -x 10 -b 1000000 -s 2000000 (found @ 144.275 Mhz)
-- below here I verified with FTDX-5000 --
50 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 50075350 -x 30 -b 1000000 -s 2000000 (found @ 50.072.2 Mhz)
28 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 28276390 -x 0 -b 1000000 -s 2000000 (found @ 28.276.0 Mhz)
21 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 21172430 -x 0 -b 1000000 -s 2000000 (found @ 21.172.0 Mhz)
18 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 18110470 -x 20 -b 1000000 -s 2000000 (found @ 18.110.0 Mhz)
14 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 14100510 -x 10 -b 1000000 -s 2000000 (found @ 14.100.0 Mhz)
10 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 10130550 -x 10 -b 1000000 -s 2000000 (found @ 10.130.0 Mhz)
7 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 7025590 -x 10 -b 1000000 -s 2000000 (found @ 7.256.0 Mhz)
3.5 Mhz: hackrf_transfer -t /tmp/nw0w_bcn -f 3579610 -x 20 -b 1000000 -s 2000000 (found @ 3.579.0 Mhz)
====================================================================
1.8 Mhz (NOT ENOUGH RF-OUT That I could measure)
====================================================================
So All you'd really have to do to make this work on all frequencies would be create a script that loop the commands above as one finshed to just loops to the next band to send the beacon msg. Since the msg I recorded takes 15 seconds it would take 180 seconds to rotate back around to transmit again on the same band. Of course a 10 second msg would take 120 seconds to rotate back around to the same band (so 2 minutes or 3 minutes). On HF that's fine. On >=50 Mhz that's probably way to long.
I haven't seen it be possible to transmit two signals at the same time. I haven't really tried to be honest. I suspect this would be problematic, and at the very least would cut the 32mw in half. Not to mention possible Intermod issues.
If you really shortened the message to something like "DE NW0W/B EM47" you could probably rotate around fairly quickly if you sent at 20wpm+. Which should be fine for something like CW skimmer to detect.
#!/bin/bash
for (( c=1; c<=10; c++ ))
do
sleep 2;
if [ $((c%2)) -eq 0 ];
then
echo "6m bcn running...\n";
hackrf_transfer -t /home/ubuntu/nw0w_bcn/nw0w_bcn_short -f 50075350 -x 0 -b 1000000 -s 2500000
echo "6m bcn done.\n";
else
echo "2m bcn running...\n";
hackrf_transfer -t /home/ubuntu/nw0w_bcn/nw0w_bcn_short -f 144275590 -x 15 -b 1000000 -s 2500000
echo "2m bcn done.\n";
fi
done
Subscribe to:
Posts (Atom)