measuringeverything

[measuringeverything]

Earth is surrounded by the electromagnetic spectrum.This spectrum contains a range of different frequencies of electromagnetic radiation. The spectrum extends from frequencies caused by natural phenomenons everywhere in space to frequencies used by modern radio communication here on Earth.We created the BigWhoop: A system that will continuously monitor the spectrum and detect all signals within. We achieve this with low-cost , software-defined radio devices  for each ground node for BigWhoop. With your help, we can deploy hundreds of these nodes forming a global internet connected sensor array for monitoring the spectrum!

To give you an example: The more BigWhoop nodes that we have, the more aircraft signals can be received and tracked during their paths around the world. This way, the planes won’t get lost that easily. But the BigWhoop can do more. We can detect places of high spectrum activities such as radio towers and tell you, when a new music channel starts its broadcast service. Or we can find sweet spots of radio silence where radio telescopes can be placed and listen to weak cosmic radio sources, that would have been drowned in man-made radio noise otherwise.

In the very spirit of NASA Space Apps Challenge and the open-source movement, the global community can modify BigWhoop for their out-of-the-box projects like tracking cube-sats or something yet out of our imagination! And the best thing is, we can already use BigWhoop system on our Constellation computation grid with 60,000 PCs donated by citizen scientists worldwide!With BigWhoop we will start with global spectrum monitoring -with you we will do extraordinary things!

[measuringeverything]

Our current receiver prototype configuration needs two USB connections. What if you only have one? Parasitic power robbing! It works fine, no magic smoke was released, so we solder the rest together! :)

[measuringeverything]

SOCIS2014: Status Update Meeting Aug. 25th

  Software:

  Implemented a python fft script that takes a raw binary file containing 8-bit IQ data, does Fast Fourier Transform on it and finds the peak values and frequencies

Tested python fft script with matlab generated sine wave

Need to experiment with how IQ data is converted from -1 to +1 floating point number to 8 bit integer number 0 to 255

Need to package up a BONIC application as a stand-alone software package

Need to implement a simple application that detects a sudden level change of input IQ data

[measuringeverything]

First GPS tests with great outcome: We measured the PPM inaccuracy of the SDR quartz to about 30 to 35 ppm and it was also influenced by the operating temperature. Besides that, this offset was stable and we were able to find the pulse duration of about 2048060 samples. The SDR itself was set to record with 2048000 Hz. The reftick finding will be used to have the start for the relative measurement to further signal markers within the streams... But if you like, you find the three sample waves with IQ input here, hadez and bronsen (and a little me) coded a first prototype software for analysis, and below is my result. I know you can do it even faster and better than me, so have fun with the files and finding the refticks  :D. Keep you posted.

needle length = 368640 samples per frame = 1 samples = 368640 select samples 368688 gap# | start index | start offset | p2p samples | p2p seconds || [data below] 0 23 1130555 1130555 0.55201209729 1 24 3178626 2048071 1.0000043944 2 25 5226697 2048071 1.0000043944 3 25 7274767 2048070 1.00000390613 4 23 9322838 2048071 1.0000043944 5 24 11370909 2048071 1.0000043944 6 23 13418980 2048071 1.0000043944 7 25 15467050 2048070 1.00000390613 needle length = 368640 samples per frame = 1 samples = 368640 select samples 368660 gap# | start index | start offset | p2p samples | p2p seconds || [data below] 0 10 1719348 1719348 0.839499976075 1 10 3744284 2024936 0.98870834965 2 10 5792344 2048060 0.999999023467 3 10 7840404 2048060 0.999999023467 4 10 9888464 2048060 0.999999023467 5 10 11936524 2048060 0.999999023467 6 9 13984396 2047872 0.999907229371 7 11 16032456 2048060 0.999999023467 8 11 18080516 2048060 0.999999023467 9 9 20128576 2048060 0.999999023467 10 11 22176636 2048060 0.999999023467 11 9 24224696 2048060 0.999999023467 12 11 26272756 2048060 0.999999023467 13 11 28320816 2048060 0.999999023467 14 9 30368875 2048059 0.999998535201 15 11 32416935 2048060 0.999999023467 16 11 34464995 2048060 0.999999023467 17 10 36513054 2048059 0.999998535201 18 10 38561114 2048060 0.999999023467 19 10 40609174 2048060 0.999999023467 20 9 42657233 2048059 0.999998535201 21 9 44705293 2048060 0.999999023467 22 11 46753353 2048060 0.999999023467 23 10 48801412 2048059 0.999998535201 24 10 50849470 2048058 0.999998046934 25 9 52897531 2048061 0.999999511734 26 10 54945590 2048059 0.999998535201 27 10 56993650 2048060 0.999999023467 needle length = 368640 samples per frame = 1 samples = 368640 select samples 368688 gap# | start index | start offset | p2p samples | p2p seconds || [data below] 0 23 294799 294799 0.143944824219 1 23 2342862 2048063 1.00003076172 2 25 4390924 2048062 1.00003027344 3 24 6438986 2048062 1.00003027344 4 23 8487050 2048064 1.00003125 5 24 10534948 2047898 0.999950195312 6 24 12583173 2048225 1.00010986328 7 24 14631236 2048063 1.00003076172 8 25 16679261 2048025 1.00001220703 9 24 18727363 2048102 1.00004980469 10 25 20775427 2048064 1.00003125 11 23 22823485 2048058 1.00002832031 12 24 24871488 2048003 1.00000146484 13 24 26919563 2048075 1.00003662109 14 23 28967672 2048109 1.00005322266 15 24 31015710 2048038 1.00001855469 16 24 33063728 2048018 1.00000878906 17 24 35111771 2048043 1.00002099609 18 23 37159922 2048151 1.00007373047 19 23 39207984 2048062 1.00003027344 20 25 41256047 2048063 1.00003076172 21 24 43304108 2048061 1.00002978516 22 24 45352108 2048000 1.0 23 24 47400233 2048125 1.00006103516 24 23 49448272 2048039 1.00001904297 25 23 51496357 2048085 1.00004150391 26 25 53544420 2048063 1.00003076172 27 24 55592485 2048065 1.00003173828 28 24 57640508 2048023 1.00001123047 29 25 59688607 2048099 1.00004833984 30 25 61736669 2048062 1.00003027344 31 23 63784722 2048053 1.00002587891 32 23 65832792 2048070 1.00003417969 33 23 67880855 2048063 1.00003076172 34 23 69928917 2048062 1.00003027344 35 23 71976980 2048063 1.00003076172 36 24 74025043 2048063 1.00003076172

[measuringeverything]

Does our RTL-SDR dongle survive direct 1 pulse-per-second feeding to its antenna input? That was a question we raised and thought about for about 1 attosecond before we decide “hell yeah, let’s try that and see what happens!”. And it worked out pretty neat! That’s cool if sdr hardware is cheap as dirt and you can replace it very easily. But before I bore you with impulsive reaction facts, what you see on the waterfall diagrams is a rock radio station near Stuttgart and our test pulse that came in every 2342ms for 100ms. We expected the additional voltage to level up the input power, but it did the opposite. It saturated the first capacitor and then added to the adc reducing the sensitivity. But it also served our goal to have a trigger mark in the input signal. And best thing, in fm we could still listen to the Blues Brothers without any disturbance! ;)

[measuringeverything]

Marta is doing a pretty fine work on the lone-pseudoranger code she is doing for Google Summer of Code. The code calculates the position of the beacon signals. In this case, two satellites are beeping around, the red and the blue sat and by using all those white circled ground stations, their tracks can be determined. There are further images here on flickr.

The next steps are to improve accuracy by adding some filtering and clustering mechanisms. Stay tuned…

[measuringeverything]

World turns, as she should! Satellite’s orbiting, and tracking as good as we could! (green: simulated satellite position, red calculated satellite position)

[measuringeverything]

Coast lines behave like fractals! It took some time to sketch all continents and some islands for the “land filter”. Only on land, ground stations are placed. But only, where humans live permanently, so the pole areas are not included. On these, and islands, ground stations shall be placed manually.

[measuringeverything]

Based on this image, we included a "land" filter, so that ground stations are only placed withing the land zones. Or at least we think so. We still have to test it with the other continents...

[measuringeverything]

Once more in the history of this project i got some magic smoke … Because our current hardware platform, the bladeRF, is very complex, i decided to do some of the basic FPGA tests on a cheaper and really simple FPGA- Evaluation board. Now the board has arrived and first of all i connected it to a power source … booom! … magic smoke and no flashing lights. That’s the problem with “Made in China”, it’s cheap, but the documentation is very bad and so i didn’t know that the polarity was reversed. But i’m lucky and now after desoldering a broken capacitor the board is working and ready for the first live tests of all the things currently running only in my simulations.

[measuringeverything]

Testing the NMEA-Output of the GPS-Reciever was successfull. The position and time, currently transfered as raw data directly over an arduino to my pc, will be give us information about the position of a DGSN ground station and the exact timestamp which is needed for calculation of the satellites position. In future all the evaluation of the GPS data will be done hardwired by a fpga chip. The needed coding is currently in develop …

[measuringeverything]

First of all, i’m sorry. I wanted to share my progress at Google Summer of Code 2014 (GSOC14) and the Distributed Ground Station Network (DGSN) on this blog. Now more than a half of the time of GSOC14 is over an there’s nothing yet i posted so far. But in the next few days i will catch up and presenting all what i’ve done so far, i promise!

[measuringeverything]

Status Update Meeting July 14th

Hardware:

Planning to test antenna in the following week when ISS signals are available

Software:

Modified rtl-sdr to read from a sample file containing recording specifications and rtl_adsb to receive input from a file instead of a device

...

[measuringeverything]

Okay, we have "contact", virtually, as lines connecting the ground stations to the calculated satellite position. This was done for several beacon signals during half an orbit. What is special about this is, that the pseudo-ranging, the basis for trilateration, was varied by purpose with a random length based on time delay between 1 ns and 100 us. More photos and a first plot can be found on -> flickr.

[measuringeverything]

First part of mapping is ready! We use Marble for visualization of (artificially generated) ground stations. Now is time for satellites!

[measuringeverything]

[ESA]Status Update Meeting Doc

Status Update Meeting June 30th

  Hardware:

  The antenna that comes with the USB dongle is not strong enough to receive signals from ISS

  I’ve got a few antennas of longer lengths / different shapes and also the adapters needed to connect them to the USB dongle, but there would be no ISS in the following week according to the NASA website, so I’m currently waiting to see when I could test out the new antennas

  Software:

  Rtl-sdr is the GNU branch that supports RT2832 devices (which is the USB dongle family that we use), this would be the base of any modification I’m planning to make in order to make it meet our goal for the project

  In addition, GNU Radio is to be used for any additional analysis (but only on the central unit, so plan is by the end GNU Radio does not need to be installed in processing unit. I’m currently learning how to use GNU Radio and signal processing in general

  GQRX is also to be used, for testing purpose, to see if Antenna is capable of receiving satellite signals, and additional frequencies that we could test on

  Currently, I’m working on modifying rtl-sdr to read from a sample file that specifies that frequency, sample-rate, output-file, and all other parameters that might be useful to specify (status: done); and I am modifying rtl_adsb to receive input from a file instead of a device (expected finish date: Monday June 30th); I’m also planning to modify rtl_fm for additional testing to ensure we are able to read from a file and decode it into audio (expected finish date: Sunday July 7th), this step is to ensure that signals are recorded correctly

  Eventually, I’m planning to have a program that feeds signals from a file to USB device, so we don’t have to modify every single function that takes input from the device, in other words, trick the computer to think that the signals are from device when they are pre-recorded (expected finish date: Sunday July 14th)

  I have my own Makefile for modified rtl-sdr so I could keep track of dependencies

  I am also planning to write a script for setting up the USB dongle for first use on Linux, I would test the program on a fresh-installed Linux to make sure it works (and all the dependencies are fine) and afterwards I would proceed with modifying it for Windows

[measuringeverything]

After 4 hours of crawling through the source code, Marta and me (Andreas) found the logical bug in the positioning source code. It was a hard task, but finally we found it. This good feeling is reward enough and why Google Summer of Code is so much fun! :) The bug was, that the s variable was fixed, but we needed it flexible. It was a leftover from the first tests with fixed data-sets. It is now working correctly and we can go on. We will keep you updated!