search

pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
329 stars 203 forks source link

2 Channel Embedded Transceiver #686

Closed shinyRM closed 6 years ago

shinyRM commented 6 years ago

Hello,

I am trying to use the embedded source block with GNU Radio on the red pitaya. I am not using Alpine on the red pitaya for this since I cannot get GNU Radio to run. I am instead using the Debian red pitaya image with a clone of the latest "red-pitaya-notes".

I changed the start.sh script to have the right file paths and believe that I have the FPGA configured correctly to the "sdr embedded transceiver" mode since I can control the GPIO with the modified gpio-output.c from issue #685. (the blinking light on the red pitaya has also stopped, which I see as another indication since all the blinking has been removed in more recent configurations)

However, when I try to execute my gnu radio flow-graph/generated python on the red pitaya I keep getting a "Connection Refused" error. I have tried using the IP address of the red pitaya as well as its local 127.0.0.1 address with port 1001 but neither will work.

I was able to get an older version of the embedded source block to work before, but I would like to get it up an running with the newer blocks since the added 'port' option will let me decide to use IN1 or IN2 (at least that is my understanding of why this field was added).

Does something in my set up seem wrong/am I using the address and port fields wrong? Am I trying to use the embedded source blocks incorrectly?

Thank you

pavel-demin commented 6 years ago

In the current version of the embedded SDR transceiver project, the provided GNU Radio blocks are expected to run on a remote computer and to communicate with sdr-transceiver-emb running on Red Pitaya. I'm using sdr-transceiver-emb only for my tests of this project and sdr-transceiver-emb isn't started automatically. It should be built and started manually.

An old version of the GNU Radio blocks that was communicating directly with the FPGA can be found in the 2016.3 branch:

https://github.com/pavel-demin/red-pitaya-notes/tree/2016.3/projects/sdr_transceiver_emb/gnuradio

I think that this old version could be still adapted to the new FPGA configuration.

shinyRM commented 6 years ago

Thank you for your reply, I have done some work with the 2016.3 branch of the sdr-transceiver-emb and it works really well making the red pitaya a stand-alone SDR. Is there a way I can modify the block to be able to receive on IN2, or would the FPGA need to be configured differently as well?

For the new version, what is the difference between the sdr-transceiver and the sdr-transceiver-emb if they are both run remotely? Is there intent to get the sdr-transceiver-emb running back on the red pitaya, and if there is, is there anything I can do to help? (If not the introduction for the embedded SDR on the red pitaya notes page may need to be updated)

Ultimately I am trying to get a standalone two channel SDR, you've done a lot of awesome work with the red pitaya and I think it is really close to being able to do so.

As a sidenote, I don't know a lot about Alpine Linux and I am curious about the change to it. What inspired the change and how do you like it so far?

pavel-demin commented 6 years ago

For the new version, what is the difference between the sdr-transceiver and the sdr-transceiver-emb if they are both run remotely? Is there intent to get the sdr-transceiver-emb running back on the red pitaya, and if there is, is there anything I can do to help? (If not the introduction for the embedded SDR on the red pitaya notes page may need to be updated)

In its current version, the embedded SDR transceiver is part of the standalone SDR transceiver developed by Wolfgang Kiefer: http://www.wkiefer.de/x28/red_pitaya_stand_alone.htm http://www.wkiefer.de/x28/Red%20Pitaya.htm

This standalone SDR transceiver uses the STM32F7 discovery kit to run its GUI part. The WDSP library is used for the processing of the radio signals. All the DSP code is running on Red Pitaya. Here is a link to the code: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_emb/app/sdr-transceiver-emb.c

Initially I used GNU Radio but then had to switch to WDSP because WDSP performed significantly better.

As a sidenote, I don't know a lot about Alpine Linux and I am curious about the change to it. What inspired the change and how do you like it so far?

The short answer is in the Introduction section of my notes about the Alpine Linux distribution.

In a longer answer, I'd mention the following advantages of the SD card image based on the Alpine Linux distribution:

pavel-demin commented 6 years ago

I've just realized that there are two programs with the same name:

pavel-demin commented 6 years ago

Looks like I still have a copy of the old Debian based SD card image with GNU Radio and an old version of embedded SDR transceiver: https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABvkWa3_2EIsmwTfnNaZfG2a/sdr/red-pitaya-gnuradio-debian-8.5-armhf-20160621.zip?dl=1

shinyRM commented 6 years ago

Thank you for all of your responses! I am definitely intrigued by WDSP and its performance. I appreciate the link to the old embedded SDR transciever and hopefully others will too, but I also want to give alpine/WDSP a shot:

I have been trying to edit/compile server/sdr-transceiver-emb.c to work with both IN1 and IN2. I am now using a pre-build alpine SD and using gcc to compile my edits directly on the red pitaya (I did replicate your development system and build the whole project, but that takes a lot longer and I only need to edit one c file).

Looking at the block_design.tcl for the embedded receiver, it looks like IN1 and IN2 are set up with: set_property OFFSET 0x4000[format %X [expr $i + 3]]000 [get_bd_addr_segs ps_0/Data/SEG_reader_${i}_reg0]

Since i will be 0 and 1, it looks like IN1 is at 40003000 and IN2 is at 40004000. Is referencing 40004000 the same way that this line from sdr_transceiver_emb.c references 40003000 going to give me access to IN2?

rx_data = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x40003000);

I have tried to confirm this myself by using both IN1 + IN2 this way, as well as only IN1 as the code has originally, but i am getting the message:

aplay: device_list:270: no soundcards found...

The port 1001 is being opened by the red pitaya when I execute the start.sh script, but I think I am only getting null data since no soundcards are found and nothing is output on the port when I am listening to it. Do you know why the red pitaya can't find the soundcard, or what I can do to try to fix it?
Thank you (I also changed the title of this issue since I am not trying to use GNU Radio anymore, would you prefer I created a separate issue instead?)

pavel-demin commented 6 years ago

Is referencing 40004000 the same way that this line from sdr_transceiver_emb.c references 40003000 going to give me access to IN2?

Yes, 40004000 is the address of the IN2 buffer. The rx_freq address should also be modified:

rx_freq = ((uint32_t *)(cfg + 8));

The port 1001 is being opened by the red pitaya when I execute the start.sh script, but I think I am only getting null data since no soundcards are found and nothing is output on the port when I am listening to it. Do you know why the red pitaya can't find the soundcard, or what I can do to try to fix it?

A soundcard is required for app/sdr-transceiver-emb.c but not for server/sdr-transceiver-emb.c.

If you just connect to port 1001 and wait for the data, then the server is blocked at line 125 waiting for a command: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_emb/server/sdr-transceiver-emb.c#L125

To get the RX data stream, send a 32-bit integer equal 1 as it's done in the GNU Radio block: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_emb/gnuradio/red_pitaya_emb.py#L41

shinyRM commented 6 years ago

Thank you, that is very helpful! I have edited the server/sdr-transceiver-emb.c so that sends IN1 data to port 1001 and IN2 data to port 1002. I also wrote two short python scripts, one to connect to either port and print the raw data to ensure connection using: sock.send(struct.pack('I',1)) or sock.send(struct.pack('I',4)) (I added another handler so there is five now, I changed rx_data_handler to rx_data1_handler and rx_data2_handler)

It seemed like both ports were getting data at different rates, so I used the red pitaya GNU radio blocks instead as well as a frequency/time sink to see the data better.
With the frequency/time sinks I could see the difference clearly, IN2 is not processing the data in the FPGA like IN1 is (which is expected given the block diagram in the red pitaya notes).

I do not have a lot of experience with FPGAs, but I am wondering if it is possible to set up the sdr-transceiver-emb block_design similarly to the sdr-transceiver design. I've been looking over both designs and have been trying to compare both of them:

In the block_design for the sdr-transceiver, there are two modules called trx_0 and trx_1 which are very similar in set up, the main differences are the 0 and 1 in variables as well as an offset to the memory map locations: 40001000 --> 40003000 40002000 --> 40004000 40010000 --> 40020000 40018000 --> 40028000

If I duplicate the correct sections of the sdr-transceiver-emb block_design.tcl and modify it similarly to how the sdr-transceiver block_design.tcl is set up, do you think will I be able to get IN2 to function like IN1?

There are also more memory map locations used in the embedded version (40000000 - 40020000) so just adding 2000 to these locations doesn't seem like it will work like in the non-embedded version. Is there a different offset you would recommend that won't overwrite or break anything that is already set up? (perhaps adding 10000 so 40001000 --> 40011000?)

Thank you again for all of your replies!