Re:VectorSourceBlock-GRC
Hello Isaac, Adding a delay block set to at least 24 could indeed allow you to see your square signal. But you can also solve the cause of the issue: By default, the time sink I assume you are using, is set to display 1024 samples at a time. So it waits for that amount of samples before plotting anything. In your case, you are generating only 1000 samples, so the time sink is stuck waiting for the last 24. The delay block, as part of its operation, starts by outputting samples with 0s according to its delay setting, so you can create the 24 you are missing that way. You can also set your time sink to display just 1000 samples, and you should see just what you generated. Hope that was clear, Cyrille Le 30 septembre 2021 08:36:34 GMT+02:00, "dominik.walach" a écrit : > > Hello Isaac, > > The solution is quite simple, just add a delay block to the flowgraph (see > the attachment). Vector Source pushes all the samples at the beginning faster > than Time Sink can even display it. > > Best, > > Dominik > Od "Discuss-gnuradio" > discuss-gnuradio-bounces+dominik.walach=pekasat@gnu.org > Komu discuss-gnuradio@gnu.org > Kopie > Datum Wed, 29 Sep 2021 17:25:04 -0500 > Předmět VectorSourceBlock-GRC > Hello > I'm Isaac. I'm trying to produce a 1KHz square signal for only one period. > So I decided to do it with the vector source block (500 ones and 500 zeros). > But when I run it with the option repeat = No, I only see zero. When I put > repeat=yes, I see the square but continuous, not only one period. > ¿What am I missing? Any help or advice is welcomed. > Regards > Isaac T. Cyrille Morin
Re: re-synchronize data transmission when parameter changes
Hi Marcus, Thank you very much for the detailed explanation. Basically, in my case, the two repeat blocks will be connected to two USRPs separately, and they are operated through two PCs. So sharing one repeat block might not be very practical. My thought was, when you first execute the transmission, the two channels are synchronized until you change the repetition factor in the two repeat blocks. Is it possible that each time the repetition factor changes, the whole flowgraphs restart just like I click the execute button at the beginning, then they are synchronized again? (it could be better still keeping the USRPs synchronized, but could do it again after restart) I tried stop(), wait(), start() and lock(), unlock() commands in the top_block, but seems they are not for that purpose. If the flowgraphs is not killed and execute again, the buffers are not flushed, so not exactly as restart the whole flowgraph. Could it be feasible in Gnuradio doing what I thought? Thank you and best regards, Wei Marcus Müller 于2021年9月29日周三 下午6:15写道： > Hi Wei, > > it sounds to me like a bit of an "esoteric" use to adjust the number of > repetitions at runtime for a transmission, but that should not stop you! > > Not all things can work, though: > > > For example, by asking the two repeat blocks always > > process the same amount of samples, > > No, that's not how GNU Radio works! > > > or each time I change the > > parameters, the two file sources re-transmit the file from the beginning > > simultaneously? > > That wouldn't solve the fact that the repetition factor of your two > "Repeat" blocks aren't set synchronously. > > Instead: > If you want, you can: > > Stream A -->|Streams to| |Vector to|---> > Stream B -->| Vector |--->|repeat|-->| Streams |---> > > By far the most elegant way would be if you wrote your own C++ repeat > block that has an arbitrary number (instead of just 1) input (and the > same number of outputs). Then, you could avoid the "Streams to vector" > and "vector to streams" trickery. > > Best regards, > Marcus > > On 29/09/2021 18.10, Huang Wei wrote: > > Hello everyone, > > > > I am testing the transmission of the same signal in parallel through two > > repeat blocks (see attached flowgraph). The repeat times of both repeat > > blocks are set by the same GUI range from 2 to 10. > > When I start running the flowgraph, the two output signals are exactly > > the same as expected. But when I change the repeat times from the GUI > > range, the two signals are not synchronized anymore (see attached signal > > plot). > > > > I am wondering, is there a way to keep the two signals always > > synchronized? For example, by asking the two repeat blocks always > > process the same amount of samples, or each time I change the > > parameters, the two file sources re-transmit the file from the beginning > > simultaneously? > > > > I am doing this because I want to transmit the signals simultaneously > > through two synchronized USRPs, and I don't want the mis-match of the > > signals due to changing the parameter in the repeat blocks every time. > > > > Appreciate if someone could help me! > > > > Regards, > > Wei > > > >
Re: re-synchronize data transmission when parameter changes
Hi Wei, On 30.09.21 12:04, Huang Wei wrote: > Hi Marcus, > > Thank you very much for the detailed explanation. > Basically, in my case, the two repeat blocks will be connected to two USRPs > separately, > and they are operated through two PCs. So sharing one repeat block might not > be very > practical. ah, ok. That's really a very different problem. > My thought was, when you first execute the transmission, the two channels are > synchronized > until you change the repetition factor in the two repeat blocks. Is it > possible that each > time the repetition factor changes, the whole flowgraphs restart just like I > click the > execute button at the beginning, then they are synchronized again? No, because the timing of the restart would be random. Best regards, Marcus
Releases v3.8.4.0 and v3.9.3.0
GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target date with hours to spare. For details, see the Github release pages: https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0 https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0 Next releases are expected in December.
Re: VectorSourceBlock-GRC
Hello Thank you for your replies. It works! Regards Isaac T. El jue, 30 sept 2021 a las 3:11, Cyrille Morin () escribió: > Hello Isaac, > > Adding a delay block set to at least 24 could indeed allow you to see your > square signal. > But you can also solve the cause of the issue: > By default, the time sink I assume you are using, is set to display 1024 > samples at a time. So it waits for that amount of samples before plotting > anything. In your case, you are generating only 1000 samples, so the time > sink is stuck waiting for the last 24. > The delay block, as part of its operation, starts by outputting samples > with 0s according to its delay setting, so you can create the 24 you are > missing that way. > You can also set your time sink to display just 1000 samples, and you > should see just what you generated. > > Hope that was clear, > Cyrille > > Le 30 septembre 2021 08:36:34 GMT+02:00, "dominik.walach" < > dominik.wal...@pekasat.com> a écrit : >> >> Hello Isaac, >> >> The solution is quite simple, just add a delay block to the flowgraph >> (see the attachment). Vector Source pushes all the samples at the beginning >> faster than Time Sink can even display it. >> >> Best, >> Dominik >> >> >> >> Od "Discuss-gnuradio" discuss-gnuradio-bounces+dominik.walach= >> pekasat@gnu.org >> Komu discuss-gnuradio@gnu.org >> Kopie >> Datum Wed, 29 Sep 2021 17:25:04 -0500 >> Předmět VectorSourceBlock-GRC >> >> Hello >> >> I'm Isaac. I'm trying to produce a 1KHz square signal for only one >> period. So I decided to do it with the vector source block (500 ones and >> 500 zeros). But when I run it with the option repeat = No, I only see zero. >> When I put repeat=yes, I see the square but continuous, not only one period. >> >> ¿What am I missing? Any help or advice is welcomed. >> >> Regards >> Isaac T. >> >> >> >> >> >> >> >> >> >> >> >> Cyrille Morin >
Re: Releases v3.8.4.0 and v3.9.3.0
Thanks for all everyone's efforts. We hope to give them a try. I’ve got a Soapy SDR question. Does anyone have a SDRPlay RSP1A running with Gnuradio 3.8. I’ve not been able to find a running example. Please send a link, if you’ve got a good example. Thanks! Glen For our successes in Radio Astronomy work see the memos at https://github.com/WVURAIL/lightwork > On Sep 30, 2021, at 7:39 PM, Jeff Long wrote: > > GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target > date with hours to spare. For details, see the Github release pages: > > https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0 > https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0 > > Next releases are expected in December.
Re: SoapySDR Question
I installed gr-soapy for 3.8 (using PyBOMBS), plugged in a RSP1A, and it worked. This is the LibreSpace code, as we don't have in-tree Soapy support in 3.8. I'd already installed the soapy libs (v0.8.1-g1cf5a539) and driver modules, also via PyBOMBS. Make sure it's not a soapy or usb problem by running SoapySDRUtil --probe My test was just a Soapy Source connected to a QT GUI Sink. Sample rate is 1M, and so is the bandwidth in the Soapy Source on the RF tab. Don't know if that matters. Everything else is defaults. On Thu, Sep 30, 2021 at 8:46 PM Glen Langston wrote: > Thanks for all everyone's efforts. > > We hope to give them a try. > > I’ve got a Soapy SDR question. Does anyone have a SDRPlay RSP1A running > with Gnuradio 3.8. I’ve not been able to find a running example. > > Please send a link, if you’ve got a good example. > > Thanks! > > Glen > > For our successes in Radio Astronomy work see the memos at > https://github.com/WVURAIL/lightwork > > > > On Sep 30, 2021, at 7:39 PM, Jeff Long wrote: > > > > GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September > target date with hours to spare. For details, see the Github release pages: > > > > https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0 > > https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0 > > > > Next releases are expected in December. > >
Re: SoapySDR Question
Hi Jeff, Thanks for your quick reply. I was having trouble figuring out what to put in the Soapy Source block. Do you have a flow graph example? Thanks Glen In the mean time I’ll try pybombs > On Sep 30, 2021, at 9:11 PM, Jeff Long wrote: > > I installed gr-soapy for 3.8 (using PyBOMBS), plugged in a RSP1A, and it > worked. This is the LibreSpace code, as we don't have in-tree Soapy support > in 3.8. > > I'd already installed the soapy libs (v0.8.1-g1cf5a539) and driver modules, > also via PyBOMBS. Make sure it's not a soapy or usb problem by running > > SoapySDRUtil --probe > > My test was just a Soapy Source connected to a QT GUI Sink. Sample rate is > 1M, and so is the bandwidth in the Soapy Source on the RF tab. Don't know if > that matters. Everything else is defaults. > > On Thu, Sep 30, 2021 at 8:46 PM Glen Langston > wrote: > Thanks for all everyone's efforts. > > We hope to give them a try. > > I’ve got a Soapy SDR question. Does anyone have a SDRPlay RSP1A running > with Gnuradio 3.8. I’ve not been able to find a running example. > > Please send a link, if you’ve got a good example. > > Thanks! > > Glen > > For our successes in Radio Astronomy work see the memos at > https://github.com/WVURAIL/lightwork > > > > On Sep 30, 2021, at 7:39 PM, Jeff Long wrote: > > > > GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target > > date with hours to spare. For details, see the Github release pages: > > > > https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0 > > https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0 > > > > Next releases are expected in December. >
