igorauad / gr-dvbs2rx

DVB-S2 Receiver Extensions for GNU Radio
https://igorauad.github.io/gr-dvbs2rx/
GNU General Public License v3.0
95 stars 23 forks source link

More SDR devices for dvbs2-tx and dvbs2-rx? #16

Closed jacintomfr closed 1 year ago

jacintomfr commented 1 year ago

Hello,

Great project, I like the idea of using command line options with no GUI, very useful for SBC, so is there a chance to update your project to work with hackrf or pluto sdr?

Tks

Jacinto

igorauad commented 1 year ago

Hi @jacintomfr ,

I'm sorry for the long delay.

I would happily extend the dvbs2-tx and dvbs2-rx support for common SDR boards. However, I've been waiting until these can be tested. I don't have a HackRF or PlutoSDR to experiment with, so I haven't added them yet. If you can test them and would like to help, we can work together on adding the support.

In the meantime, it is always easy to interface with dvbs2-tx or dvbs2-rx by building a small flowgraph in GNU Radio with the SDR sink or source block for Tx or Rx, respectively. For example, the example below would work to interface with dvbs2-rx:

pluto_sdr_source

The File Descriptor Sink block is configured with fd=1, meaning it will output to stdout. So you can pipe the output of this flowgraph into dvbs2-rx easily. By default, dvbs2-rx reads the IQ stream from stdin, so that will work out of the box. Just run something like:

./pluto_sdr_source.py | dvbs2-rx

The same holds with dvbs2-tx. By default, dvbs2-tx outputs to stdout, so you can pipe it into a flowgraph like the following, with a File Descriptor Source block configured with fd=0 (stdin):

pluto_sdr_sink

I hope that helps.

jacintomfr commented 1 year ago

Hi Igor,

thank you for your reply ... I'm using a lot the hackrf with gnuradio and gr-dvbs2 from drmpeg, I still have a firmware problem with my pluto-sdr, and because I have two hackrf's I decided to use them for DATV (they work OK and right now the pluto is very expensive), I'm amateur radio and on Sunday night I usually participate in a DATV meeting using QO-100 satellite, most of the time I use symbol rate 333k at 3/4 so my grc script is under heavy test for at least one hour ...

What I like about your version is the ability to pass command line information to gnuradio, I can't do that with gr-dvbs2, I mean I can pass the symbol rate and frequency + tx gain (instead of variable I use parameter) but fec and modulation type no, for example, no, I was able to do that but it's a lot more complex ... the parameter won't work with gr-dvbs2 blocks.

a small example of my script :

   -flush_packets 0 -f mpegts

"udp://"$OUT_IP":"$OUT_IP_PORT"?pkt_size=1316" \ | ../bin/dvbs2_tx_333_34b_nogui.py --symbol-rate "$SYMBOLRATE_K"000 --mod1 $mod0 --rate1 $rate0 --freq "$FREQ_OUTPUT"e6 --gain $LIME_GAIN

that's a stupid workaround on gnuradio but it works ...

I don't know if I was clear and sorry for my English!!! I will test your idea tomorrow and also I can send you my full script and grc, so that you can have a better idea of what I'm talking about.

thank you

Jacinto

I

On Wed, 11 Jan 2023 at 18:56, Igor Freire @.***> wrote:

Hi @jacintomfr https://github.com/jacintomfr ,

I'm sorry for the long delay.

I would happily extend the dvbs2-tx and dvbs2-rx support for common SDR boards. However, I've been waiting until these can be tested. I don't have a HackRF or PlutoSDR to experiment with, so I haven't added them yet. If you can test them and would like to help, we can work together on adding the support.

In the meantime, it is always easy to interface with dvbs2-tx or dvbs2-rx by building a small flowgraph in GNU Radio with the SDR sink or source block for Tx or Rx, respectively. For example, the example below would work to interface with dvbs2-rx:

[image: pluto_sdr_source] https://user-images.githubusercontent.com/5166844/211903189-c8dd6607-14f2-41ac-8043-cf929e465232.png

The File Descriptor Sink block is configured with fd=1, meaning it will output to stdout. So you can pipe the output of this flowgraph into dvbs2-rx easily. By default, dvbs2-rx reads the IQ stream from stdin, so that will work out of the box. Just run something like:

./pluto_sdr_source.py | dvbs2-rx

The same holds with dvbs2-tx. By default, dvbs2-tx outputs to stdout, so you can pipe it into a flowgraph like the following, with a File Descriptor Source block configured with fd=0 (stdin):

[image: pluto_sdr_sink] https://user-images.githubusercontent.com/5166844/211904501-00022c1b-71ff-4aae-b4e9-6d2b562f36e1.png

I hope that helps.

— Reply to this email directly, view it on GitHub https://github.com/igorauad/gr-dvbs2rx/issues/16#issuecomment-1379408567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFR3UMMUOLXSPVQH7BV5JDWR4GAHANCNFSM6AAAAAARRW6HHM . You are receiving this because you were mentioned.Message ID: @.***>

jacintomfr commented 1 year ago

Hi Igor,

small question, I understand your idea for file descriptor source but how can I use UDP source for dvbs2-tx ? is possible with your version?

tks

Jacinto

On Wed, 11 Jan 2023 at 21:22, Jacinto Rebelo @.***> wrote:

Hi Igor,

thank you for your reply ... I'm using a lot the hackrf with gnuradio and gr-dvbs2 from drmpeg, I still have a firmware problem with my pluto-sdr, and because I have two hackrf's I decided to use them for DATV (they work OK and right now the pluto is very expensive), I'm amateur radio and on Sunday night I usually participate in a DATV meeting using QO-100 satellite, most of the time I use symbol rate 333k at 3/4 so my grc script is under heavy test for at least one hour ...

What I like about your version is the ability to pass command line information to gnuradio, I can't do that with gr-dvbs2, I mean I can pass the symbol rate and frequency + tx gain (instead of variable I use parameter) but fec and modulation type no, for example, no, I was able to do that but it's a lot more complex ... the parameter won't work with gr-dvbs2 blocks.

a small example of my script :

   -flush_packets 0 -f mpegts

"udp://"$OUT_IP":"$OUT_IP_PORT"?pkt_size=1316" \ | ../bin/dvbs2_tx_333_34b_nogui.py --symbol-rate "$SYMBOLRATE_K"000 --mod1 $mod0 --rate1 $rate0 --freq "$FREQ_OUTPUT"e6 --gain $LIME_GAIN

that's a stupid workaround on gnuradio but it works ...

I don't know if I was clear and sorry for my English!!! I will test your idea tomorrow and also I can send you my full script and grc, so that you can have a better idea of what I'm talking about.

thank you

Jacinto

I

On Wed, 11 Jan 2023 at 18:56, Igor Freire @.***> wrote:

Hi @jacintomfr https://github.com/jacintomfr ,

I'm sorry for the long delay.

I would happily extend the dvbs2-tx and dvbs2-rx support for common SDR boards. However, I've been waiting until these can be tested. I don't have a HackRF or PlutoSDR to experiment with, so I haven't added them yet. If you can test them and would like to help, we can work together on adding the support.

In the meantime, it is always easy to interface with dvbs2-tx or dvbs2-rx by building a small flowgraph in GNU Radio with the SDR sink or source block for Tx or Rx, respectively. For example, the example below would work to interface with dvbs2-rx:

[image: pluto_sdr_source] https://user-images.githubusercontent.com/5166844/211903189-c8dd6607-14f2-41ac-8043-cf929e465232.png

The File Descriptor Sink block is configured with fd=1, meaning it will output to stdout. So you can pipe the output of this flowgraph into dvbs2-rx easily. By default, dvbs2-rx reads the IQ stream from stdin, so that will work out of the box. Just run something like:

./pluto_sdr_source.py | dvbs2-rx

The same holds with dvbs2-tx. By default, dvbs2-tx outputs to stdout, so you can pipe it into a flowgraph like the following, with a File Descriptor Source block configured with fd=0 (stdin):

[image: pluto_sdr_sink] https://user-images.githubusercontent.com/5166844/211904501-00022c1b-71ff-4aae-b4e9-6d2b562f36e1.png

I hope that helps.

— Reply to this email directly, view it on GitHub https://github.com/igorauad/gr-dvbs2rx/issues/16#issuecomment-1379408567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFR3UMMUOLXSPVQH7BV5JDWR4GAHANCNFSM6AAAAAARRW6HHM . You are receiving this because you were mentioned.Message ID: @.***>

igorauad commented 1 year ago

Hi @jacintomfr ,

Interesting to hear about your use case. As for your question, you can definitely use the UDP source block with the suggested approach. The flowgraph would be like so:

udp_source_example

Of course, you would need to configure the UDP Source block properly.

Let's say you generate this flowgraph into a udp_source.py file. Then, you can run the following:

./udp_source.py | dvbs2-rx --sym-rate 333e3 --modcod qpsk3/4

That is, pipe the output from your flowgraph (with the UDP Source block) into dvbs2-rx. Then, you can configure dvbs2-rx as needed for your test. In the above example, I'm including the symbol rate and MODCOD parameters, but there are many others. You can check the parameters with dvbs2-rx --help.

jacintomfr commented 1 year ago

Hi Igor,

OK for RX I understand, for the moment my main interest is DVBS2-TX, How can I have the same with transmission? As far as I know, the dvbs2-tx receives a TS stream file, in my tx setup script as it's real-time encoding, I send it out as UDP, unless I can create a pipe file and dvbs2-tx will read it, but I'm concerned with the latency ... then I create your py file idea from the first post with File Descriptor Source with fd=0.

It's good exercise for the weekend even if it won't work ... what will be great is at least dvbs2-ts read direct UDP like dvbs2-tx --udp ip:port but probably this will imply small changes in your program ...

thank you for your time.

Jacinto

On Tue, 17 Jan 2023 at 00:47, Igor Freire @.***> wrote:

Hi @jacintomfr https://github.com/jacintomfr ,

Interesting to hear about your use case. As for your question, you can definitely use the UDP source block with the suggested approach. The flowgraph would be like so:

[image: udp_source_example] https://user-images.githubusercontent.com/5166844/212791046-4ce1c821-b1d0-41e1-9868-af16c65961ef.png

Of course, you would need to configure the UDP Source block properly.

Let's say you generate this flowgraph into a udp_source.py file. Then, you can run the following:

./udp_source.py | dvbs2-rx --sym-rate 333e3 --modcod qpsk3/4

That is, pipe the output from your flowgraph (with the UDP Source block) into dvbs2-rx. Then, you can configure dvbs2-rx as needed for your test. In the above example, I'm including the symbol rate and MODCOD parameters, but there are many others. You can check the parameters with dvbs2-rx --help.

— Reply to this email directly, view it on GitHub https://github.com/igorauad/gr-dvbs2rx/issues/16#issuecomment-1384735954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFR3ULUSMTHYYMWYREOTCLWSX2ZPANCNFSM6AAAAAARRW6HHM . You are receiving this because you were mentioned.Message ID: @.***>

sumanthraikar commented 1 year ago

Can anyone please confirm the functionality for Pluto SDR ? I have pluto SDR, but a little worried about hardware damages because of my rookie mistakes. I read some precautions in ettus usrp b210 dvbs2 SDR page about DC blocker and some stuff which is my main concern. If you can guide me at avoiding damages, I am willing to test it on Pluto SDR.

igorauad commented 1 year ago

Hi @jacintomfr ,

FYI, I have pushed preliminary support for the PlutoSDR today into the master branch. You can now run the dvbs2-tx application with option --sink plutosdr and the dvbs2-rx application with option --source plutosdr. However, since I don't have a Pluto SDR for testing, the implementation is still subject to experimental validation. If you are able to test with your PlutoSDR, I would appreciate any feedback.

Regarding the UDP transmission you mentioned, I would like to keep the scope of gr-dvbs2rx limited to processing the layers below MPEG TS. So the Tx application takes a TS on its input, and the Rx application outputs the decoded TS. Users can use other tools to handle how the TS is transported. You may find the right tools to transport TS over UDP using the tsp plugin. Or, if you want to do the reverse, send UDP encapsulated within a protocol like MPE over TS, see this example: https://github.com/igorauad/gr-dvbs2rx/blob/master/docs/usage.md#example-12.

You can definitely use the GNU Radio UDP source and sink blocks discussed previously on your Tx setup, although I don't know whether it will work well for real-time streaming. I assume you can play with the socket buffer lengths until you get reasonable results.

In summary the setup would involve the following:

I hope this helps.

Thanks

igorauad commented 1 year ago

Can anyone please confirm the functionality for Pluto SDR ? I have pluto SDR, but a little worried about hardware damages because of my rookie mistakes. I read some precautions in ettus usrp b210 dvbs2 SDR page about DC blocker and some stuff which is my main concern. If you can guide me at avoiding damages, I am willing to test it on Pluto SDR.

Hi @sumanthraikar , I can't help with PlutoSDR-specific advice, as I haven't used one yet. But, in general, if you are connecting a Tx interface directly to an Rx interface through a coax cable, make sure you have an attenuator in between and don't overpower the Rx interface. Check the max power the Rx can handle and the max power the Tx can output. Then, put enough attenuation to make sure the Tx signal never exceeds the max Rx power, if you want to operate on the safe side. Finally, run the Tx/Rx applications with reasonable initial gain settings and tune the gain as needed.

From a quick look at the AD9363 datasheet, it seems the max input power (on Rx) is 2.5 dBm and the maximum output power (on Tx) is 8 dBm, so you don't need too much attenuation. However, you could start with an attenuator like 30 dB. There should still be enough power to make the communication work.

I believe the Transmit Power section in https://wiki.analog.com/university/tools/pluto/users/transmit may be helpful.

sumanthraikar commented 1 year ago

Can anyone please confirm the functionality for Pluto SDR ? I have pluto SDR, but a little worried about hardware damages because of my rookie mistakes. I read some precautions in ettus usrp b210 dvbs2 SDR page about DC blocker and some stuff which is my main concern. If you can guide me at avoiding damages, I am willing to test it on Pluto SDR.

Hi @sumanthraikar , I can't help with PlutoSDR-specific advice, as I haven't used one yet. But, in general, if you are connecting a Tx interface directly to an Rx interface through a coax cable, make sure you have an attenuator in between and don't overpower the Rx interface. Check the max power the Rx can handle and the max power the Tx can output. Then, put enough attenuation to make sure the Tx signal never exceeds the max Rx power, if you want to operate on the safe side. Finally, run the Tx/Rx applications with reasonable initial gain settings and tune the gain as needed.

From a quick look at the AD9363 datasheet, it seems the max input power (on Rx) is 2.5 dBm and the maximum output power (on Tx) is 8 dBm, so you don't need too much attenuation. However, you could start with an attenuator like 30 dB. There should still be enough power to make the communication work.

I believe the Transmit Power section in https://wiki.analog.com/university/tools/pluto/users/transmit may be helpful.

Thanks for reply @igorauad, I am planning to test the cases as follows

  1. Use Pluto or some SDR to receive DVBS2 from satellite in real-time and to get a live feed of video
  2. Create custom DVBS2 transmitter and receiver and exchange a video stream among independent SDR’s I also had a rookie doubt, if satellites are broadcasting the usual DishTV channels at 10Ghz how is it that an SDR which only has ADC which can sample only upto 6GHz to receive the signal, is there any other concept behind this? For my use case I want to receive the live TV video channels (any free channels in India )
igorauad commented 1 year ago

Hi @sumanthraikar ,

I also had a rookie doubt, if satellites are broadcasting the usual DishTV channels at 10Ghz how is it that an SDR which only has ADC which can sample only upto 6GHz to receive the signal, is there any other concept behind this?

You need an LNB to downconvert the Ku-band signal to L-band, which the SDR will sample. You may find it useful to learn about the Blockstream Satellite project and navigate its hardware guide, especially the DIY section. However, if you would like to ask more questions, please feel free to open a separate issue or contact me directly so that we keep the focus here on the original issue. I'd be happy to help if I can.

Regards

igorauad commented 1 year ago

Hi @jacintomfr , I will close this issue for now. Please feel free to reopen if you have more questions.