"Driveby" Update - Next Steps

So I'm just waiting a for a few more hardware items to add to the "Driveby" project.  Things like 12v and 5v power meters which show the voltages and amps being drawn.  Those meters will be mounted in the metal box that will surround all of the hardware related to this project.  There are some other things related to mounting this hardware in various smaller boxes in order to RF isolate each major component and reduce interference to the RTL receivers.

I suspect everything I need will be on-hand by this coming Friday.  I've already started to assemble some of the bits and pieces in the primary metal box container.  Basically everything will be mounted inside the one large box which is a rack-mountable box (just something I had available at the time)  This box is 14"x19"x10" so it's got plenty of room to isolate everything.  

There will be two 12v cigerette lighter male plugs (because my truck has two and also because this will ease the drain on each 12v main line).  One of the 12v lines will feed all of the 12v only equipment, and one of the 12v lines will feed a 10amp 5vdc converter which will power things like the Odroid XU3, and the powered usb hub and RTL dongles.  So the entire system runs on just 12vdc making it portable quite easily!  Even the 1Gbps Network Hub runs on 12vdc.

My ASUS X551M laptop which will be used to access the web server on the Nvidia Tegra TK1 even runs on 12vdc.  This was an important factor in my hardware choices as I really didn't want to run a 12vdc to 120VAC power inverter (although I suppose I could have I just didn't want to add that expense and make things more complicated).

So all that's really left at this point is finally putting all the hardware in a single box, make sure it has decent air flow for cooling, add RF ports in/out of the box, and figure out how best to RF isolate everything in the self contained box.

I already have the Mast that will mounted in the rear of my truck, the Discone antenna is already mounted on the mast.  I still need to resolve where I'll mount the GPS antenna and the digital compass (so that it's far enough away from the truck body to not be affected by the metal frame thus skewing the data related to the compass).  I'm planning to use some PVC to mount it far enough away from the body so that it's not impacted.  I just haven't built that yet, but that's probably a 30 minute job.

I expect to be able to do a REAL, LIVE test with all of this within about a week or two.  The sooner the better because I'm really interested in seeing the results of this project!

• So next steps is just to do as I've mentioned above.  Get it all finally assembled, and ready to drive.  Then head out on the road.
  
• I'll post pictures of the final assembly as soon as I get started on that...and progress through that as well as the final result prior to drive testing.
  
• Then I'll post some pix of everything ready to go in my truck as well as a pre-drive-test video and walk around.
  
• Then a video of the actual drive test.
  
• Then a video and blogged data from a complete drive test as well as the resulting Mapped data and any highlights along the way.

"Driveby" App Stationary Test

Today I tested the sensitivity of the "Driveby" app I've been working on the past month or so.  This wasn't a highly technical sensitivity test, but rather just an experiment to demonstrate how the application as a whole functions once it's warmed up, calibrated, and ready to run.  

During this test I used my 50 Mhz 57 foot long boom yagi antenna which is located at the top of a 47 foot high tower.  The feedline is LMR600.  I aimed the antenna at the start of the test due south at 180 degrees which is one of my more quite directions.  Midway through the test I rotated the large yagi 180 degrees from South to due North.  

North of me there is a 49 Mhz Baby Monitor.  So this is a pretty 'real-world' test of what I can expect from the graphing of the data while I'm driving around.

Part of this experiment when I actually do take this all on the road is to map out locations where 49 Mhz Baby Monitors physically located.  (Yes I know that MAY seem creepy to those of you how have never operated on the 50 Mhz ham band you wouldn't understand).  So the reason behind attempting to locate these baby monitors as part of this project is that there are all sorts of noise sources.  Band pass filters in radio's and after the radio can really only do so much, and in fact they're not really effective at all in eliminating noise from the 49Mhz range.  Most baby monitors is really quite broad, and can be really lousy RF neighbors.

So the reason for attempting to locate these monitors is so that I can later send the residence a post card, or even knock on their door, and attempt to explain the issue, and to offer them a much higher frequency (new) baby monitor perhaps in the 900Mhz or 1.2Ghz or higher realm and in the process eliminate yet another annoying major source of desensitizing man made noise  that is too close to 50 Mhz near by my home location.

The reason 50, 144, 222 and 432Mhz are also being scanned is because Power Line noise tends to show up in these frequency ranges quite well (at least around here it sure does).  This is the PRIMARY reason for this entire project to start with.  

This application records rf noise levels in 5 RF frequency ranges:

• 49.7-50.0 Mhz
• 50-50.3 Mhz
• 144.2-144.5 Mhz
• 222.3-222.6 Mhz
• 432.1-432.4 Mhz

So I'm getting noise floor readings for 300 Khz in each range noted above.

The Nvidia Tegra TK1 functions as a GPS, COMPASS monitor getting Lat/Long readings, and AZ/EL/SPEED data while I drive and logs that data to it's attached and NFS shared data directory.  The TK1 also provides the Web-GUI (graphical user interface).

The Odroid XU3 (which by now I've totally fallen in LOVE with!) has the 5 RTL Dongles connected to a 10 port USB 2.0 power hub, and it takes Noise Floor readings constantly once started up and logs that data over the NFS to the TK1's attached SSD drive.

The combination of these two systems make up the "Driveby" application.  Making it possible to "Geo-Tag" Noise Floor measurements while in motion.  This means that it's then possible to MAP both the Lat/Long and Noise Floor readings on something called a "heatmap" which utilizes Google Map API.  Low noise levels show up as Green, and progressively turn to Yellow, Orange and Red depending on the signal strength at any given location.

So for example driving down a 'RF Quiet" road would look like a Green line, and driving into and RF noisy location would show yellow, orange or red.  Driving out of the noisy area would return to green again.  

Once the entire area immediately around my home has been mapped like this I can then drive out in progressively greater radius from home and improve the mapped data.  For example a few miles from here are some very high power transmission lines, all around this old power line infrastructure region of the state are problem areas.  Without something like this to map those areas I think it would probably be nearly impossible to really know what was causing my 'locally' high noise floor (frequently above s9 @ 50 Mhz in several directions).

Once I have mapped the bad locations, I can then return with even better equipment and pin point the actual source of the RF noise.  Whether it is someones Home, or some power line transmission equipment, or a street lamp, or god knows what.  

It's fairly easy to drive around with a radio and your ears and spot areas that are bad, but having an automated system to listen, and log everything while you drive is WAY more accurate, way safer to actually do, and definitely more convenient.

A system like this can be used for all sorts of things not just what I'm using it for which is really a very high level very simple noise floor recorder.  

SEE ALSO (Next Steps)

ARM Server - WAVE of the FUTURE!

Android Tethered Connection through Ubuntu 14.04 Laptop setup as a Router to 10.x.x.x lan

So in order that all the micro-servers in the "Driveby" application could have internet access while I'm doing real drive-testing as well as the Laptop I'm using as the main System Interface to control everything and also access Google Maps to display mapped geo-tagged, RF Noise Levels I needed to setup the central Laptop to share it's Tethered internet connection on the Galaxy Note 2 and it's 3G/4G LTE.

I found this example and adapted it to suite my needs.

On the TK1 I used nm-connection-manager to setup the 10.0.1.x network connection.

On the Laptop I used the System > Networks GUI to setup the ETH0 10.0.1.x network connection.

Next on the LAPTOP I used detail found here to do this:

vi /etc/sysctl.conf
net.ipv4.ip_forward = 1

sysctl -p /etc/sysctl.conf

THEN this little bit of magic brings it all together.

When the Laptop is connected to the TETHERED connection:

root@driveby-lt:~# cat driveby_routing_usb
#!/bin/bash
sudo iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
sudo iptables -A FORWARD -i usb0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o usb0 -j ACCEPT
route delete default
route add default gw 192.168.42.129

When the Laptop is connected to the WIFI connection:

root@driveby-lt:~# cat driveby_routing_wlan 

#!/bin/bash

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

sudo iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT

route delete default

route add default gw 192.168.3.1

So when I'm connected to the WIFI internet connection on the Laptop I simply run as root:

~/driveby_routing_wlan

and when on the Tethered connection:

~/driveby_routing_usb0

I will probably add these deeper into the networking configuration so that I don't have to actually run these scripts manually.  But this works Great!

From the TK (note the chart layout above) I can now access the Global Internet via whatever REAL internet connection the Laptop currently has available be-it WIFI or Tethered connection.

In this way everything being used in the Driveby Application will have real time access to the internet if needed.  Pretty cool!

And I didn't have to pay for adding Hotspot on my tethered device.  This setup allows me to add as many devices to the sub-network on 10.x.x.x as I need to and the Laptop acts like a Masquerading Router!

Excellent!

Odroid XU3 - pretty amazing!

SO this week my Odroid XU3 arrived from ameridroid.com This little machine is nothing short of AMAZING compared with several other micro-pc ARM-based systems I've been using.

Of course all of the micro-pc's I've been trying out have their own set of unique 'amazing' points of interest.  The list of machine's I've been working with now is:

• Nvidia Tegra TK1
• Parallella 16
• Beaglebone Black
• and now the Odroid XU3

The XU3 sports 8 native cores!

 The TK1 is a dual core ARM cpu with 192 Cuda Core processor, the Parallella 16 is a quad core with an Epiphany chip that supports 16 cores, the Beaglebone Black is a single core.

Some of these charts below were made while I was compiling GNURADIO on the XU3.

The compile of GNURADIO via Pybombs is (almost) straight forward.  Except for the need to alter one of the cmake directives related to neon and volk.  It took about 1 hour to compile on the XU3 using -j2.

I'm not planning to use the XU3 immediately in the first live runs of the "Driveby" application I've been working on, because it's not really required to get some initial test data which I've been really anxious to get completed.

However, the plan (I think) is to replace the Parallella 16 with the XU3 for driving the RTL's as I'm pretty sure the XU3 will out perform the P16 while running 4-5 RTL's and maintain a lower system load average.  

In fact, it MAY be possible to run the entire Driveby application from ONLY the XU3 with 8 cores available.  The only down-side to the XU3 is that it doesn't support native SATA on the board itself to attach an SSD.  However, there is a $35 USB3.0 to SATA converter board that can at least allow attaching the SSD to the XU3 system.  While the performance would probably be less than that of the TK1's direct on board Sata connection, it would probably mean that I could run everything for this project on the XU3 and NOT require NFS at all as I'm doing now.

Anyway....there are TONs of options on my workbench now.  And you can NEVER have too many options!  IMHO.

"Driveby" app almost ready to run

This week I completed the Web Gui that runs the "Driveby" app I've been building.  Software-wise this is effectively done.  

What's left to complete is to build the hardware antenna mounting system that'll go in the back of my truck.  I have the primary discone antenna to be used with the RTL's and HackRF as well as all cabling.  I have up to 10 feet of antenna mast and I just need to get some PVC to build the stand off for the Yocto-3D compass (to keep it away from metal that can effect the accuracy of the compass readings.  Once I have that it probably won't take more than an hour or so to complete that stuff.

So probably around Christmas vacation time I'll be getting this all on the road for a maiden test run.

I'll post pix and video of how that goes as soon as I have some test results or until I have some test results.  I really think this will all 'just work' and be perfectly fine on the first run.  Testing from a stationary point so far seems to run flawlessly now.

The intent of this "Driveby" app has a core goal of being able to accurately indicate geo-location tagged areas with high RF noise levels and be able to be mapped real-time and reviewed after a drive test or compared with previous tests.  And to do all of this as cheaply as possible.  So far I'm very pleased with the hardware and the software and the costs.

More on all of this as soon as I have some REAL data to post.  Shouldn't be much longer!

Asus X551MAV Cheap Laptop

This week I bought an inexpensive Asus X551MAV from Amazon.  The price was $249.00 and the company I work for sent me an Amazon $150.00 gift card.  So total cost to me was only $99.00.  I then bought a Samsung EVO 840 120Gb SSD drive.  The first thing I did when the laptop arrived was setup the installed Windows 8.1.  Then I promptly removed the 500Gb 5400 rpm hard disk and replaced it with the 120Gb SSD drive.  Then inserted a USB stick with Ubuntu 14.04 and installed that on the new SSD.  30 Minutes or so later it was all functional and running Ubuntu.

Everything seems to work as it should.  Including the FN keys.  Max temp spec for this laptop is about 150c (Celsius).  It idles around 49c and max seen so far while compiling was around 53c.  SO the cooling fans appear to be working fine also.

I'm very pleased with this little 15.6" el-cheapo laptop running Linux.  Apps I've installed so far are Netbeans 8+ and SecureCRT 7.3+ as well as Chrome.  These are really all I need installed in any device to work professionally.  And this is all more than enough for what I do on these side projects.

Wifi works out of the box, Android Tethering works as tested with my Samsung Galaxy S3 and Galaxy Note 2.  So mobile internet access is also functional.  

The laptop only sports a dual core Celeron 2Ghz and 4Gb of Ram.  But again this is really all that I need (after 20yrs+) I've learned what works and doesn't for the things I do.

So the SSD performance is the KEY to making this laptop feel just like a higher end box.  Linux loads up from shutdown in about 15 seconds with the Graphical interface.

I was planning to use the Galaxy Note 2 (7" tablet) to access and run my new "Driveby" app however a 15.6" display is certainly much nicer!  For $174.00 start to finish this seems like a really cool way to go that is also very inexpensive!

I'd do it again, and that says a LOT I think.

Nvidia Jetson TK1 - Serial Console to the rescue

Today I was attempting to turn my TK1 into a wifi access point.  In the process I bunged up the eth0 interface and networking stopped working after a reboot.

After a mad scramble and a post to a Forum I realized I could access the computer via it's serial console.

Then another mad scramble to find my null-modem serial cable, and an adapter, and remember I had hard coded the serial port to 4800b for something else I use here.  

After I setup windows to use 115200/8/N/1 and attached the null modem serial cable and related adapters to get the connection to the hardware I used trusty SecureCRT to connect to the serial port via com4 and wa lah I saw the TK1 terminal booting after a reset.

THANK GOD For OLD SCHOOL knowledge!

I first used serial ports and null modem cables back in the late 80's and all that knowledge was still stuffed away in my aging brain!  

Also thankfully the hardware developers of the TK1 thought enough to add a Serial Port DB9 connection on the board! (rare these days!).

Anyway crisis averted.  I'd had visions of re-flashing the rootfs and redoing everything I've done for the past month until this serial port came into view.

Whew....

NFS between Nvidia Jetson TK1 and Parallella 16 - Delay Resolved

I've been working with the Nvidia Jetson TK1 and the Parallella 16 for the past few weeks and during this time I noticed a delay or 'stuttering' on log file updates over the NFS connection between them.  

This shows up in my "Driveby" application as a lack of 'responsive' updates on graphs and charts.  During the past week I noticed if I would get on the NFS Client side (the Parallella) and would do something like 'tail -f /mnt/nfs/disk1/driveby_data/*mhz_data.out' (the data files being logged from RTL's to NFS from Parallella to the NFS server running on the TK1) that this delay or stuttering would stop and the graphs and live data would react immediately.

I'm posting this so that if you are trying to use NFS Server and Client setup and notice things are NOT updating immediately you'll know how to resolve it.  This is NOT a Parallella or TK1 fault.  This is a 'feature' built into NFS to improve performance and reduce cycles required to operate NFS.  

At any rate the fix for my setup was to add some options to the NFS config and restart the NFS service then umount and mount the Client again.  Fairly simple actually.

On the NFS server (Nvidia TK1)  /etc/exports for my setup looks like this:

/export       192.168.3.0/24(rw,fsid=0,insecure,no_subtree_check,async,no_wdelay)

/export/disk1 192.168.3.0/24(rw,nohide,insecure,no_subtree_check,async,no_wdelay)

The addition was to add the 'no_wdelay' option.

then service nfs-kernel-server restart

On the NFS Client (Parallella 16) the /etc/fstab for my setup looks like this:

192.168.3.20:/ /mnt/nfs      nfs     rw,vers=4,hard,noac,intr,proto=tcp,noatime,nodiratime,rsize=8192,wsize=8192 0 0

The addition was to add the 'noac' option.

sudo umount /mnt/nfs
sudo mount -a

DONE

That's all there is to it.  While NFS documention indicates there might be a performance hit on the server and client I'm not seeing one.  Things are running at very acceptable loads and I don't see an increase running it like this vs. what it was doing before.

I just wanted to share this in case you ever need to keep NFS from lagging like my application requires.

"Driveby App" new Block Diagram

See Previous posts about this new system I've been working on.  This new diagram shows 12vdc and 5vdc devices as well as the Samsung Galaxy Note II (7" display) and some of the layout for the networking involved.  The "Driveby" app requires internet access to display the online Google Map data being plotted.  This is not required to do a drive test run, but should be nice to have.  The Galaxy Note II has built in LTE networking, the addition of a OTG USB adapter and a wired internet cable will allow access to the private network.  

I'm not sure yet if I'll be able to run both at the same time, but that's the plan at this point and kind of important if I intend to be able to display the maps while driving.

Click on the Image to see a larger version.

ODROID XU3 - One more mini Computer to test

I ordered a ODROID XU3 today to test after hearing from a trusted friend that these perform very well.  I want to test one using one of them in the "Driveby" App I'm working on.  (and of course if it doesn't do well with this application I have a TON of other uses for something like this in the future, just like all the others I've bought so far).

Here is a link to this one (this is a US distributor)

Here is the OEM link (this is the OEM from Korea)

• In case you are curious as to what other uses I've been talking about may be:
  
• A standalone SDR instead of running things on my PC offload the work to a standalone system like one of these mini-computers.
  
• A weather station accessible via the internet
  
• A azimuth and elevation indicator using a Yocto-3D for an EME Array
  
• A hybrid weather station/azimuth indicator/active antenna controller:
• A device which monitors weather conditions and rotates my large antenna to stay WITH the prevailing winds.

"Driveby" Project - Next Steps

A little background if you haven't been keeping up:

Currently the "Driveby" Project I've been working on (see earlier posts on this blog for more detail) uses a program named "rtl_power" to pull Noise Floor readings from 5 miniature radio receivers that come in the form of USB Dongles called "RTL"s (see: http://www.rtl-sdr.com/) for more detail about them.  

The idea behind this project is to be able to MAP real-world Geo-tagged noise floor readings.  This can be used for the primary purpose I intended for this application (mapping of problematic sources of RF Noise related to power lines in the area so that I can approach the local power company to resolve them) or any other sort of RF signal MAPPING.  Such as cellphone/cellsite coverage or FM broadcast coverage (and dead spots) among other things.

RTL dongles are CHEAP, and reliable, although not 100% stable (they drift a bit for the first 5 minutes of warm up) they can be used to measure changes in the RF Noise Floor (once warmed up).  While they don't really seem to be able to be calibrated to anything less than -87db all we're really looking for are relative changes to the noise floor while driving around a particular location (there is probably some complex math that could applied to these measurements that could be calibrated).  So for this project these inexpensive receivers are really just fine. 

These noise floor readings are logged to files over a NFS connection from the RTL's attached to the Parallella over to an Nvidia Jetson TK1 this TK1 has a 120Gb SSD attached to it via normal 4 pole power connector and Sata cabling.  (nothing special there really).  

The TK1 and the Parallella 16 are networked directly through a 1Gb Network Hub.

ANYWAY...this program named 'rtl_power' (see: here and code here) is something I've used for almost 2 years with various projects.  I've modified rtl_power in various ways in the past to suite my needs with really amazing results.  It's simple yet powerful when used correctly.

NEXT STEPS for Parallella within the Driveby project:

So I've been kicking around the idea of exploring the ability of Parallella to do the FFT's making full use of the Epiphany instead of doing them directly in a single thread as rtl_power currently does.  This is probably a bit advanced of my current knowledge and abilities, but seems like a good way to LEARN more (BTW if you are interested in getting involved with this migration to using the Epiphany to do RTL FFT's please let me know), and end up with something that takes full-advantage of the Parallella 16.  This was the actual real reason I bought this board.  

I also bought the Nvidia TK1 thinking at some point I could experiment with doing FFT's on it's 192 Cuda core processor (also currently beyond my abilities, but I intend to spend time learning).

Even without taking full advantage of these two boards, they provide enough Ram and core processors to run via USB a digital compass, a L10 GPS, and 5 RTL Dongles plus NFS, GPSD, virtualHub (required for the digital compass) and two Apache2 web servers all running at the same time.

NEXT STEPS for the Driveby project:

• Explore doing FFT's  from data steaming out of the RTL dongles, using Epiphany on Parallella.
• Improve the Web UI (so far it's just enough to get all the basic functionality required to control both servers (parallella and tk1) with all of it's ancillary attached hardware.
• Make code publicly available (open source of course).
• Provide detailed documentation of all hardware assembly and interconnections as well as code setup.
• Provide real-world demonstrations of the results the Driveby system is capable of.

Examples of what I have working so far:

• http://blog.dxers.info/2014/11/rolling-noise-floor-tests-multiple-bands.html
• https://www.youtube.com/watch?v=9Xf3oEGcFXc
• http://blog.dxers.info/2014/11/beaglebone-black-rtl-dongles-used-drive.html
• https://www.youtube.com/watch?v=5NDebeiW4K8

Jetson TK1 and Parallella 16 Desktop working together

The past week I've been working to get TK1 and Parallella (para) sharing the load of all the devices included in the "Driveby" project. 

This is the replacement system for the Beaglebone Black (bbb).  The BBB was able to run
all of these things now being run on the TK1 and PARA except that when more than one RTL was running things slowly began to load the system up to the point that things would become unreliable within about 20 minutes.

There's a LOT going on with this now.  Getting to this point required learning to compile and install a new Kernel on the TK1 that supports NFSD (network file sharing server).  And installing the correct Kernel and FPGA code on the Parallella so that USB would work reliably.

The new system design layout inblock diagram form looks like this (more or less):

This entire system runs off of 12vdc!  Included is also a (12v) DC-DC (5v) converter that powers the 10p USB2 hub RTL's and the Parallella.  The 12v leg powers the DC-DC converter as well as the Nvidia Jetson TK1, 4p USB3 hub, Digital Compass (yocto-3d), L10 GPS as well as a 1Gb Network hub.

The code for all of this hasn't really changed much.  Some file path changes were required, and that's really about it.

There are two Apache2 servers running.  One on the TK1 and one on the Para.  The primary control web GUI runs on the TK1, and it access the web service on the Para when turning on and off the RTL's.

I have still have a fair amount of Web Design and RPC to complete to make things run a little smoother, and look a little nicer.  However the system is basically ready to be used.

I need to lay out all the hardware in a container to keep things from sliding around and getting damaged while driving.  But besides those things this thing actually works!

Parallella 16 "Desktop" with RTL-SDR Tools working now...(1,2)

Parallella 16 install of RTL TOOLS

sudo vi /etc/passwd 
changed from /bin/tcsh to /bin/bash (but that's just me)
exit and log back in again

---

sudo apt-get install cmake libboost-all-dev libusb-1.0-0-dev -y

---

cd someplace you want this code to be located.  In my case I just did this in linaro's home (e.g. /home/linaro)

git clone git://git.osmocom.org/rtl-sdr.git

cd rtl-sdr/
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig

cmake ../ -DINSTALL_UDEV_RULES=ON

---

TEST if it's working:

rtl_eeprom -d 0

results in:

BTW I ran three instances of rtl_test -d[0-2] and NO samples were lost at FULL BANDWIDTH.  If this continues to work like this then we're really ONTO SOMETHING GOOD.

STILL NOT HOLDING MY BREATH.  There are just too many posts about how unreliable the USB has been.  I'll continue to HAMMER my Parallella 16 via USB for a while to see if this is a perm. resolution. (I doubt it will be, but hoping for some goodness).

POWERED DOWN...disconnected everything.

Waited for 2 hours then returned and started it all back up.  NO USB (again).  Figured this is what would happen.

I've also power cycled several times, and found that if I remove the network cable, remove power from the powered hub and  then apply power to the Parallella and quickly plug in the network plug that things will boot up and the USB will come up with it.

I suspect there might be a ground loop on board, or perhaps the hub is feeding power the board, I know some devices don't like to see that on boot up.

Parallella 16 "Desktop" a mistake?

I've been working with both the Parallella and the Jetson TK1 this week.  So far my experience with the "Parallella 16" has basically sucked.  50% of the time the network interface won't even come up.  100% of the timethe USB interface won't come up at all.  

Of the times I've been able to get the network interface to come up via DHCP on it's own it's been kind of a good feel to the computer itself.  However, it's instability and unreliable behavior thus far is making the Beaglebone Black look like a rock-solid-go-to-device.  Which is a SERIOUS DISAPPOINTMENT!

The USB issues apparently have been around for at least 6 months, and little or no REAL progress has been realized that an average user could employ.  Which is also VERY disturbing.  These computers where marketed as functionally working.  And at a fairly hefty price considering the work that will be involved for me to really make use of it.

The Parallella 16 "Desktop" comes with a LARGE heatsink that needs to be installed prior to powering it up.  (a simple process!)  With this heatsink in place, and the unit simply idling (doing nothing of use) the board temp. reaches it's acceptable high level (70c+) within minutes.  I placed a 120mm/12vdc fan next to it and the temp drops to about 46c.  in comparison I ran the HELL OUT OF the Beaglebone Black with a system load around 3!  And it barely got warm.

Needless to say, I'm seriously UNIMPRESSED with the Parallella at this point, not so much from it's ability to heat the room, but more to it's completely unreliable behavior when it comes to doing BASIC connectivity to the outside world.  USB and Networking are CORE to just about any device these days.  This shouldn't be THAT HARD for the boards developers to have working prior to sales!

All I can say is....pffff....on to something else unless they come up with something that will truly WOW me.  What a shame!

======================= UPDATE ============================

Okay so more putzing around with this machine.  Most likely this is ONLY an aberration.

I've seen others talk about how USB works and then mysteriously doesn't work.  SO take THIS information with a grain of salt.

Today I pulled replaced the 'headless' version of the 7010 FPGA and kernel with the "HDMI" version.

I also went into /etc/securetty and remarked out 'hvc0' and 'hvc1' which I don't think are required (but I could be mistaken).  Anyway dmesg showing the system was respawning hvc0 endlessly.   The respawns have stopped after a hard reboot. (ie. shutdown, power cycled).

Before the power-cycle I attached a 10-port usb-hub that has worked on all Linux boxes I have (and there's a PILE of them).  Attached to the usb-hub are 3 RTL TV Dongles, a wifi, a digital compass, and a usb microsd storage card.

Then I booted up Parallella and it came up just fine.  Without any network hiccup (this is the 3rd time today it came up ok via DHCP), I checked dmesg and no more respawning was happening.

Then I typed 'lsusb' and all the devices attached showed up via the USB!  I'm like WTF?

Well I've heard that the USB can be finiky and unreliable sometimes coming up and working and sometimes not at all.  So far in the 50 or so attempts I've tried to bring up USB at boot time it never would come up.  THIS was the FIRST time.

So I'll attempt some more power cycle/reboots and see how that goes.  I don't expect this to remain working.  But it would be nice!

Nvidia Jetson TK1 running GNURADIO

Tonight I completed building GNURADIO 3.7 on the Jetson TK1.

It wasn't too awful bad to get done.  I had several start/stops dealing with some compile errors, but all in all it wasn't that bad.  I learned some of the finer points from working with the Beaglebone Black and the ARMHF.  

So this is some progress at least with some work on the TK1.

Nvidia Jetson TK1 Is alive

My New Nvidia "Jetson TK1" Tegra computer arrived today.  Startup for this one consisted of connecting to the LAN, and attaching the supplied 12vc power source.  

Even with 5 RTL dongles, 1 mass storage device, a digital compass, and a GPS all attached via USB, the TK1 boots up in 16.834885 seconds !! ~ cool

Parallella 16 "Desktop" is alive

My Parallella 16 arrived this morning.   I installed Ubuntu 14.04 on it already and have it booted up and DHCP connected to my network.  Start up for this is a bit more complex than others http://www.parallella.org/create-sdcard/ However it did come up just fine.

I first attempted to create the bootable SDcard using a server I had available that runs Ubuntu 12.04 and I tried to follow the directions in the link above however, the directions weren't really that simple to follow and I got lost on step 5 and couldn't locate the /BOOT for the SD card.

So then I followed the Windows method and that worked perfectly!

LOTS OF WORK ON THIS AHEAD!