Reverse engineering the demo software

Discuss KerberosSDR - 4x Coherent RTL-SDR
Post Reply
GermanTerrible
Posts: 16
Joined: Wed Nov 21, 2018 10:00 am

Reverse engineering the demo software

Post by GermanTerrible » Wed Mar 04, 2020 2:47 pm

Hello,

I have done a little reverse engineering. I studied computer science, unfortunally I have forgotten most of what I learned, but I keep trying. Sorry if what I say is not 100% all right. Feel free to correct me if needed. Perhaps there are some people interested in the source code as well in this forum, so let's share what I have seen.

First of all, in the file run.sh I have found these lines:

113 sudo chrt -r 50 taskset -c $NPROC ionice -c 1 -n 0 ./_receiver/C/rtl_daq $BUFF_SIZE 2>$RTLDAQLOG 1| \
114 sudo chrt -r 50 taskset -c $NPROC ./_receiver/C/sync $BUFF_SIZE 2>$SYNCLOG 1| \
115 sudo chrt -r 50 taskset -c $NPROC ./_receiver/C/gate $BUFF_SIZE 2>$GATELOG 1| \
116 sudo nice -n -20 sudo -u $curr_user python3 -O _GUI/hydra_main_window.py $BUFF_SIZE $IPADDR &>$PYTHONLOG &

These are four executables, and the output of any of them is piped to the input of the following one:

* rtl_daq: rtl data adquisition??? This is the one that gets the raw data from the hardware
* sync: when properly set up by the last executable, it can independently delay the raw data from each rtl as needed, so all of them work coherently
* gate: when triggered by the last executable, it lets its input pass to the output; when not triggered, it discards its input; it needs to be explicitly triggered each time the last executable wants more raw data
* hydra_main_window.py: a Python script which performs several functions: interfacing the three, low level, former executables; performing the main signal processing; calculating the delays to be passed to sync, in order to achieve coherency; and draw the main window

I think that the raw data format is this: each sample is an unsigned 8-bit integer for the I part, and following it another unsigned 8-bit integer for the Q part. These samples are grouped in blocks. Inside each block the samples for the first rtl are sent together; then the samples for the second one are sent together, and so on.

I have done this because I am interested in modifying this software. My goal is to get the raw samples and process them to try myself a beamforming algorithm. I guess there are some ones in this forum that are trying anything similar, but perhaps they were unable to understand this stuff until now. I wish this helps.

I still could not implement it successfully, but the main points could be:

* Add to gate the posibility to be triggered forever. When gate reads a 1 from the pipe _receiver/C/gate_control_fifo it is triggered once:

50 fread(&trigger_read, sizeof(trigger_read), 1, fd);
51 if( (uint8_t) trigger_read == 1)
52 {
53 //fprintf(stderr,"Trigger received\n");
54 trigger++;
55 sem_wait(&trigger_sem);
56 }
57 else if( (uint8_t) trigger_read == 2)
58 {
59 fprintf(stderr,"[ EXIT ] FIFO read thread exiting \n");
60 exit_flag = 1;
61 break;
62 }
63 }

99 if(trigger == 1)
100 {
101
102 fwrite(buffer, sizeof(*buffer), read_size, stdout);
103 fflush(stdout);
104 trigger --;
105 sem_post(&trigger_sem);
106 }
107 else
108 {
109 //fprintf(stderr,"No trigger, dropping %d samples..\n", read_size);
110 }

I suppose it would be easiest to modify the code, in order to get triggered forever when it reads a 3, and keep gate in the pipeline.

* Modify the Python part: remove the GUI, remove most of the signal processing and keep hydra_receiver.py. Add a new main program that sets up the four rtls (center frequency, gain…), performs both synchronizations, asks the user to connect the antennas, triggers gate forever and starts dumping standard input to standard output.

I am not sure whether I can get it running myself, I will try on my own, but anyway, here are my ideas. Any feedback would be welcome, of course!

Regards.

myke
Posts: 38
Joined: Wed Aug 28, 2019 7:03 pm

Re: Reverse engineering the demo software

Post by myke » Tue Mar 17, 2020 7:41 pm

Seems to me, YOU HAVE FORGOTTEN NOTHING!!! Good to dig into the code and get your mind around what makes this work -- I'm not much of a coder however, I'm not doing to bad for an old man...

One important lesson is, in the forums - "SEARCH" is your friend ... take a look at this viewtopic.php?f=9&t=4987&p=12521&hilit=raw#p12521

GermanTerrible
Posts: 16
Joined: Wed Nov 21, 2018 10:00 am

Re: Reverse engineering the demo software

Post by GermanTerrible » Thu Mar 19, 2020 11:51 am

Thank you! And yes, you are right about the important lesson :-) But I suppose it is needed to trigger the gate forever.

Perhaps the gate would only be necessary when running in slow hardware?

rtlsdrblog
Site Admin
Posts: 2563
Joined: Mon Nov 19, 2012 11:54 pm

Re: Reverse engineering the demo software

Post by rtlsdrblog » Wed Mar 25, 2020 4:54 am

So the new code is being worked on now, and that will be quite a bit more advanced, but also fully documented. For now this is a brief overview of the current code:

rtl_daq: Yes this takes a chunk of data from the RTL-SDRs and buffers it
sync: Synchronizes the samples based on the USB delay determined by the DSP Python code during the correlation/sync procedure.
gate: The RTL-SDRs can pump data out much faster than the DSP code can process it. So to maintain sync and avoid a buffer overflow we need a program that dumps data that can't be processed. This is the gate.
hydra_main_window.py: The main DSP program. Accessing the DFing and passive radar libraries, and does the correlation/sync offset calculations.

If you're working on beam forming, take a look at the code of the pyARGUS library used in the DSP code https://pypi.org/project/pyargus/. It already has beamforming implementations. Just a matter of putting the right data in.

Post Reply