After a month or so working with the Beaglebone Black (which I really do like) I've come to the conclusion that it's just simply not powerful enough to run my "Driveby" app that I've been working on. So I've ordered one each of these to move forward.
The Parallella can run 16 cores and I'll be using that running Linux to manage the numerous RTL Dongle Receivers for the project.
The Nvidia TK1 will handle some of the data crunching and Web App portion of the application. This board comes with a SATA connector and I've ordered a small 120Gb SSD drive to attach to it as well. I will likely setup NFS on this board/ssd and allow the Parallella to write it's log data there over a network connected.
This is probably a LOT more horsepower than I really need. But puts me in a better position for expansion or later reuse of the various bits from this project for other projects.
These probably won't be here until late next week I suspect.
It's not so much that the Beaglebone Black is bad or underpowered generally speaking. It's actually a fantastic device for the $55.00 I paid for it. I could have also clustered them, but that would add complexity to an otherwise simple system. $55.00 PER CORE it just more than I am willing to pay is the bottom line. It doesn't feel or behave the way I would like my application to running on a single core. And cuts me down to about 45% of the total capacity I would actually like to have when it's running at 200% of the cpu's capability. That's just not good scenario long term, and eventually would end up failing. It definitely will not scale for my applications requirements in a cost effective way.
I have other plans for the Beaglebone Black however, so it will DEFINITELY be reused in another project I am 100% sure of that :-)
Ok I'm just thinking out loud here: So the Beaglebone Black is a nice little package and there seems to be a lot of support for it out in the wild. However, it can really only DO a few things at a time before the single core CPU gets swamped. It's possible that someone could 'cluster' them but I don't think it would be as efficient as using something like a QUAD-CORE board like the ODROID-XU3 or a Adapteva Parallella-16(16-CORE). I suspect that my "Driveby" application may end up running on two boards networked together. One Odriod-XU3 as a storage device/webserver/mobile-desktop (since it has more ram than the Parallella has) and One Parallella-16 to connect to the RTL Dongles AND a HackRF (perhaps). One interesting aspect to the Parallella-16 is that is has access to an onboard FPGA. A pretty decent one at that! The shame in both of these is their limited/fixed Ram 2Gb on the Odriod and 1Gb on the Parallella. Not expandable on the boards. Both boards are fairly cheap at between $150 and $180 minus accessories. And considering that some of these are faster than low end laptops that's pretty cool! Not to mention most of them draw about the same power as a cellphone (or less!). Anyway....I'll continue with the Beaglebone Black for now. I have a second unused one on hand that I could network together with the one I've been using to ease CPU swamping. However I just don't really like the idea of having to do that at this point so I may just hold off until I can find something like the boards I've mentioned in the post OR possibly something even more exciting in the near future! It is truly a good time to be involved in computing as there is a new surge to produce highly optimized low power, high performance computer devices these day.
So I've been talking about creating a system that I can drive around with in my truck and measure the Noise Floor on several frequencies at the same time. In order to track down local sources of Power Line Noise and identify power poles that need some attention by the local power company "Ameren UE". See previous blog posts here to get details leading up to todays 'stationary test of multiple frequencies running simultaneously". In this test I'm using the Beaglebone Black, 4 RTL dongle receivers, 1 antenna shared by all 4 dongles, and a small web-app that runs on the Beaglebone which I've been working on this past week. For a simulated noise source I create a gnuradio flow-graph that generates CW (morse code) on the 4 bands I'm interested in testing today. The transmitter being used for this test is a 32 milliwatt HackRF One transmitting into a 10db attenuator at fairly low power to protect the RTL receivers. In the video I hope to show the Web App I've called "Driveby". Which is doing all of the monitoring of the GPS, reception data from the 4 RTL dongles, as well as REAL TIME graphing of all the data and REAL TIME mapping of the data based on the GPS coordinates. You will see the web-app "Driveby" running live, as well as the GNURADIO Flow Graph running and I will be changing the frequency it's transmitting on by selecting various radio buttons on the GNURADIO app. Don't get confused. The GNURADIO app and HackRF One are simply being used to generate RF noise. They won't be part of the actual Drive Testing I will be doing. This is just being used to simulate noise in order to test the Beaglbone Black Web application I've created. Video is uploading now and I'll update this blog post with that shortly.
The case is approximately 14"x7"x7". Which is plenty of room for the Beaglebone and Cape, 12vdc/5vdc converter, 10-port USB hub, and 4-port splitter plus small filters.
It's nothing too fancy, but it's water tight, and just the right dimensions for everything that'll be part of this mobile setup.
I plan to add an external power, and antenna port, as well as an two external USB port and possibly a power switch and status LED initially.
I will likely add a serial port connection for a remote Jackson Labs 'Fury' GPS in the future for greater accuracy than the $38 L10 GPS I am using now.
I'm also planning to add a remote Digital Compass which uses USB. One of the external USB ports will connect to the Samsung Galaxy Note II (which is used to access the web server on the Beaglebone via USB0 networking) and the second external USB will connect to the remote Compass (since it can not be mounted around the metal case.
All in all this seems like a durable and cheap enough case. Course there were other options, but I've always preferred Military case like this for enclosing things where durability and the possibility of getting knocked around exists.
This case, and the remote compass should arrive next week sometime.
I'll use double sided copper pcb boards cut and soldered together to separate all the discrete components inside the case, and to help reduce RFI within the case. Of course I'll post photo's here as that part of the project progresses.
12vdc to 5vdc @ 10amps 5vdc power supply which runs of 12vdc. $10.26 USD Cigerette Lighter Adapter 12vdc connection used to power the power supply above. $9.99 USD These two items make up the 5vdc power supply I'll be using to power:
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!
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 (CheckedON) 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)
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:
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:
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:
*** 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.
"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.
One this video you are listening to the CW that was generated in a WAV file and is being sent to the HackRF One via GNURADIO using USB. The result is a pretty clean CW tone being received by my FTDX-5000 on 50.075.2 Mhz. 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."
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)
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.
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.
BASH SCRIPT I USED ON BEAGLEBONE BLACK: #!/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
NOTE: RTL SDR Dongle (instead of HackRf) would be only $10.00. The trade off using the RTL dongle for the most part, I suspect, would be that you'd be RX bandwidth limited. This means about 2.4Mhz of BW vs. 20 Mhz BW. I've used RTL's over > 2.4Mhz Ranges before. IT WORKS! However there are a LOT of coding tricks you have to do to make this happen, and it really ends up NOT SO NICE in the end...but definitely USEABLE.
I suspect 2.4Mhz is plenty wide enough for detecting Power line noise. :-) But again, I'm using the HackRF One for this project to gain experience using it, and to see if I am able to use similar code that I used before with the RTL's to pull power levels (noise/signal levels).
So that's the list (so far) cabling and other stuff I pretty much have a TON of already. As well as Antenna's and the GPS antenna. So I shouldn't really need much other than this list. Again, I'm not just planning to use this gear for this project. I have several others things I'd like to work on with the HackRF, including a beacon project (proof of concept only really).
Yeah, so I've been wanting to do some drive testing in my area to see if I can accurately identify some local power poles which emit HUGE amounts of RF noise from time to time. Pretty much anytime the winds are around 7mph or more the power lines start to sing. Trouble is it's difficult to ID which ones are at fault because of the nature of what sets them off (winds). Anyway...I've had this idea for quite a while. When I used to work for a cell phone company we would do what we called "Drive Testing" in a particular cell area and record signal strengths as we drove around to then create a map of how well the Cell Site system was performing or not. I'd like to use the same concept except use the HackRF One and a Beaglebone Black (equipped with an onboard GPS) to accurately record noise measurements as I drive around. My primary concern is at 50 Mhz, however, I've learned from past experience that Power Line noise can 'sing' on many frequencies as some better than others. So that adds another dimension to things "Frequency-Hop" (very quickly!) while driving around (very slowly). In the past I used a Laptop do do things like and an RTL SDR Dongle. Which worked, but I had to stop, look at the noise level with my eye on the screen, look at my GPS to record it's location, change the VFO on the RTL, and repeat. Trouble is this is extremely slow. And you really don't get the same level of accuracy unless you can frequency-hop and record instantly say maybe 4-5 times PER SECOND. THAT is what I'm intending to do with this project. This is a VERY SIMPLE block diagram describing how I think this MIGHT work (just an alpha drawing at this point which I'm sure will need to be revised.
Fig 1.
So one of the nice things about this setup is that it appears VERY SIMPLE.
Really, the truth is, it would be even simpler to do some of this (from a hardware standpoint) to simply attach the HackRF One to an Android Phone and do everything in an Android App. Since the app could use the GPS in the phone. However, I'm not going to go that route mostly because I don't really like programming for Android. And the Beaglebone Black has LINUX which is something I work with daily as a professional and THAT comes as second nature to me. Plus the BeagleBone setup is REALLY CHEAP, so why dedicate my PHONE doing something utilitarian and fairly mundane? Well anyway, I just don't feel like it :-) Doing it in Android would mean that I'd have to deal a lot more with lower level areas related to SDR than I really want to.
Doing this with Linux means I can write things quickly and use a TON of already built libraries in Python, GNURADIO, OsmoSDR etc....(read: why reinvent the wheel?)
So the next bit is just almost too simple...
write some simple code to sample the onboard GPS (get time, and lat/long, Altitude)
write some simple code to set the HackRF frequency to 50Mhz, 144Mhz, 222Mhz,432 Mhz (good choices for PLN)
Sample the HackRF noise floor for .25 seconds on each frequency (and repeat until the end of the test)
record to storage time, lat/log, frequency, noise floor measurement
And that basically the concept. (minus a lot of logic steps and SDR mumbo-jumbo) [remember this is just high level talk at this point, but it's not much more difficult that this described.
It's also possible to use something called hackrf_transfer to record to a WAV file based on some command line parameters. So I could have an extra step here where if the Noise floor reaches a particular level I could automatically start to record the audio (this would stop the loop mentioned above though, but it's a thought that might be interesting).
Ok so now we return home from our leisurely drive test. We can download the data we captured and format the data so we can MAP IT. Then generate a map of all the samples using color coded overlays to highlight the strong, medium, and weak noise areas.
This might also be something we could incorporate into a small web-app built into the Beaglebone. KML mapping with Google earth is pretty simple for one thing. I've done that sort of thing before. NOW this is where the WiFi ability would be cool. We COULD use something like my SamSung Galaxy Note II to access the web-server running on the BeagleBone and use the 7" display on the Note II so see the map. So this is something I'll be keeping in mind as this all progresses.
But the first steps are to just get the data first. How and when it's ultimately displayed is the NEXT Phase of this.
BY THE WAY! THIS DOESN'T REQUIRE THE HACKRF ONE. This can easily be done just use the Beaglebone and an RTL SDR Dongle (which only costs about $10). I'm just wanting to use the HackRF One for this project to gain some experience with it. I already have a HUGE amount of experience doing some really cool sampling with the RTL SDR Dongles (review much earlier posts about things like Solar Flare HF blackouts, and spotting Jupiter) on this blog.
The Beaglebone Black 4Gb version is only $55.00 now! WoW! That's probably one of the cheapest Linux Computers you'll ever see. Here they are @ Mouser but you can find them all over the place just do a search for them. They're really being widely supported by a lot of companies including Texas Instruments. A lot of other companies are making addition breakout boards for things like WiFi, Serial Ports, etc...You can stack up for 4 of those add-on board to one BBB. That really makes for a fairly powerful little computer. Little in size, not capabilities! I've been wanting to pick up a bunch of these units, but have been preoccupied by other stuff. One of the things I'd like to attempt with them is to create a 10-node Hadoop Cluster :-) (google "Apache Hadoop" sometime when you have the time to read) Hadoop clusters have the ability to scale over HUGE amounts of data. Which is something I do professionally so this is just a little pet side project idea non-ham-radio related really. Anyway, I'm half thinking about using the new HackRf with the BeagleBone Black to play around with some SDR ideas I have. Like implementing a multi-band Beacon that can do WSPR, CW, and Chirp-Radar. But this is just some hi-fal-oot-in dreaming at this point. Just some idea's I've been kicking around at trying to make a reality. Another SDR Idea I've had is to add GPS tracking, using one of the very cool miniture GPS devices that will click onto the BB. And at the same time connect the HackRF to the BB, and be able to do DRIVE AROUND - Power Line Noise sensing with very accurate GPS locations. This would only require some fairly simple coding I think, the BeagleBone, the HackRF, and the 'click' type GPS add-on (more about the 'click-boards' soon). Then it would just be a matter of taking noise readings every second while I drive around. NO LAPTOP REQUIRED. After the drive-around, I'd download the data gathered on the BB's storage card, and MAP IT! VERY COOL IDEA I think! Anyway, I just wanted to share these little magical servers with you. I'll post updates when all the stuff arrives, and I've actually done something with them.
Yesterday 10/31/2014 I ordered a new "HackRF One" See Details
My plans are to play around with creating a multi-band beacon which emits 15dbm ( or about 31.6 mW) CW. Once I've managed to do that the obvious extension to me is to try to implement some of my previous work with "CDAR" using the HackRF as the radio. At this point this is just something to play with this winter. I like to have little projects to putz around with when it's too cold outside for anything else. (read: helps avoid cabin fever :-) I'll post findings as I go here. ------------------------------------------------------------------------------------------------------------------- From this GreatScottGadgets site this is what it says about this device: ================================================================== "HackRF One from Great Scott Gadgets is a Software Defined Radio peripheral capable of transmission or reception of radio signals from 10 MHz to 6 GHz. Designed to enable test and development of modern and next generation radio technologies, HackRF One is an open source hardware platform that can be used as a USB peripheral or programmed for stand-alone operation.
10 MHz to 6 GHz operating frequency
half-duplex transceiver
up to 20 million samples per second
8-bit quadrature samples (8-bit I and 8-bit Q)
compatible with GNU Radio, SDR#, and more
software-configurable RX and TX gain and baseband filter
software-controlled antenna port power (50 mA at 3.3 V)
SMA female antenna connector
SMA female clock input and output for synchronization
