HI all, I want to generate square signal (not necesarily 010101, but also random pattern) on LFTX board. Is it possible to output only one sample every f/2, if f is "symbol rate" in this case? So, for every symbol to output only one sample. At the moment I have a block which outputs with 500ksps symbols of 19.2k, which is quite a waste of resources. Best -- Nemanja Savić

Hi Nemanja, the ratio between symbol and sample rate depends on your modulation scheme and on the pulse shaping filter used. E.g. if you are using a RRC filter you need at least two samples per symbol. However, if you want to generate a square wave you don't need a pulse shaping filter at all but still you need to match the sample rate of your device. I'm not sure if I got your question right. Could you maybe elaborate a little more on your problem? Cheers, Julian On Mon, May 11, 2015 at 1:07 AM, Nemanja Savic via USRP-users < usrp-users@lists.ettus.com> wrote: > HI all, > > I want to generate square signal (not necesarily 010101, but also random > pattern) on LFTX board. > Is it possible to output only one sample every f/2, if f is "symbol rate" > in this case? So, for every symbol to output only one sample. > At the moment I have a block which outputs with 500ksps symbols of 19.2k, > which is quite a waste of resources. > > Best > > -- > Nemanja Savić > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -- Julian Arnold

Hi all, I want to generate square signal on my LFTC board. You can think of it as a RS232 signal: ___------___-----____----- at the moment I am providing samples with 500ksps. Which means that for symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of resources and I would like to provide only one sample per symbol. If the DAC level stays constant until next sample is provided, then since LFTX doesnt have any upconversion, it should be possible to generate above shown signal with only one sample per symbol. Best, Nemanja On Mon, May 11, 2015 at 11:00 AM, Julian Arnold <julian.arnold@ettus.com> wrote: > Hi Nemanja, > > the ratio between symbol and sample rate depends on your modulation scheme > and on the pulse shaping filter used. E.g. if you are using a RRC filter > you need at least two samples per symbol. > However, if you want to generate a square wave you don't need a pulse > shaping filter at all but still you need to match the sample rate of your > device. > > I'm not sure if I got your question right. Could you maybe elaborate a > little more on your problem? > > Cheers, > Julian > > On Mon, May 11, 2015 at 1:07 AM, Nemanja Savic via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> HI all, >> >> I want to generate square signal (not necesarily 010101, but also random >> pattern) on LFTX board. >> Is it possible to output only one sample every f/2, if f is "symbol rate" >> in this case? So, for every symbol to output only one sample. >> At the moment I have a block which outputs with 500ksps symbols of 19.2k, >> which is quite a waste of resources. >> >> Best >> >> -- >> Nemanja Savić >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > > > -- > Julian Arnold > -- Nemanja Savić

Unfortunatelly it is not possible, cause minimum sampling rate is 250ksps On Mon, May 11, 2015 at 12:22 PM, Nemanja Savic <vlasinac@gmail.com> wrote: > Hi all, > > I want to generate square signal on my LFTC board. You can think of it as > a RS232 signal: > > ___------___-----____----- > > at the moment I am providing samples with 500ksps. Which means that for > symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of resources > and I would like to provide only one sample per symbol. If the DAC level > stays constant until next sample is provided, then since LFTX doesnt have > any upconversion, it should be possible to generate above shown signal with > only one sample per symbol. > > Best, > Nemanja > > > On Mon, May 11, 2015 at 11:00 AM, Julian Arnold <julian.arnold@ettus.com> > wrote: > >> Hi Nemanja, >> >> the ratio between symbol and sample rate depends on your modulation scheme >> and on the pulse shaping filter used. E.g. if you are using a RRC filter >> you need at least two samples per symbol. >> However, if you want to generate a square wave you don't need a pulse >> shaping filter at all but still you need to match the sample rate of your >> device. >> >> I'm not sure if I got your question right. Could you maybe elaborate a >> little more on your problem? >> >> Cheers, >> Julian >> >> On Mon, May 11, 2015 at 1:07 AM, Nemanja Savic via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> HI all, >>> >>> I want to generate square signal (not necesarily 010101, but also random >>> pattern) on LFTX board. >>> Is it possible to output only one sample every f/2, if f is "symbol >>> rate" in this case? So, for every symbol to output only one sample. >>> At the moment I have a block which outputs with 500ksps symbols of >>> 19.2k, which is quite a waste of resources. >>> >>> Best >>> >>> -- >>> Nemanja Savić >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >> >> -- >> Julian Arnold >> > > > > -- > Nemanja Savić > -- Nemanja Savić

Sylvain

Hi, tl;dr: "No" > I want to generate square signal on my LFTC board. You can think of it as a > RS232 signal: > > ___------___-----____----- > > at the moment I am providing samples with 500ksps. Which means that for > symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of resources > and I would like to provide only one sample per symbol. If the DAC level > stays constant until next sample is provided, then since LFTX doesnt have > any upconversion, it should be possible to generate above shown signal with > only one sample per symbol. The HW could do it. But you'd have to change sw and fpga quite a bit to achieve it ... To do this, you'd need either: - An DAC clock of Fbaud which means a very low master clock rate. None of the USRP do that. (some even have fixed DAC clock, but you didn't specfy which USRP you use). - A higher DAC clock, but then just repeat the data -> The current DUC code doesn't do that, it will always apply a filter when upsampling. You best best would be a X300 with some custom RFNoC block that does simple sample repeating. Cheers, Sylvain

 Sylvain

Hi Nemanja, Sylvain is right -- the USRP takes the samples at the sample rate you specify, and constructs an analog signal out of this, guaranteeing that there's no aliasing -- which means the maximum frequency your signal can have is given by Nyquist's theorem. Hence, if you were able to generate a real-valued LFTX output with 19.2kS/s, your maximum signal frequency would be 9.6kHz -- and a "perfect" rectangular signal has infinite bandwidth, but can be well aproximated by using sampling rates significantly higher than the symbol rate. Since the USRPs are meant to be universal, you'll have to generate these higher rate signals yourself -- normally on a PC (for which 500kS/s shouldn't really make much of a load, by the way), or in the FPGA fabric by modifying the FPGA image / using RFNoC. I think this might be about talking to serial hardware using one of the RF outputs: Using a USRP's DAC is really a bit of a convoluted way of doing this. Is there a reason you're not simply using any cheap USB-to-Serial converter? Best regards, Marcus On 05/11/2015 12:35 PM, Sylvain Munaut via USRP-users wrote: > Hi, > > tl;dr: "No" > > >> I want to generate square signal on my LFTC board. You can think of it as a >> RS232 signal: >> >> ___------___-----____----- >> >> at the moment I am providing samples with 500ksps. Which means that for >> symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of resources >> and I would like to provide only one sample per symbol. If the DAC level >> stays constant until next sample is provided, then since LFTX doesnt have >> any upconversion, it should be possible to generate above shown signal with >> only one sample per symbol. > The HW could do it. > > But you'd have to change sw and fpga quite a bit to achieve it ... > > To do this, you'd need either: > > - An DAC clock of Fbaud which means a very low master clock rate. > None of the USRP do that. (some even have fixed DAC clock, but you > didn't specfy which USRP you use). > > - A higher DAC clock, but then just repeat the data -> The current > DUC code doesn't do that, it will always apply a filter when > upsampling. > > You best best would be a X300 with some custom RFNoC block that does > simple sample repeating. > > > > > Cheers, > > Sylvain > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 Sylvain

This is somehow connected with my previous posts where I explained my setup. I am using LFTX signal to modulate carrier of the signal generator, ... I use 500 ksps, and symbol rate is 19.2 kBaud, which means that for every symbol I send 500/19.2 samples. My idea was to reduce that by sending only one sample at the begining of the symbol. In that case the level would stay constant till the next sample (in this case also symbo) arives. But why I was thinkig about this is, that at the begining of the script I always get U from USRP, and I didn't know why it can't get enough samples. On Mon, May 11, 2015 at 1:29 PM, Marcus Müller <usrp-users@lists.ettus.com> wrote: > Hi Nemanja, > > Sylvain is right -- the USRP takes the samples at the sample rate you > specify, and constructs an analog signal out of this, guaranteeing that > there's no aliasing -- which means the maximum frequency your signal can > have is given by Nyquist's theorem. > > Hence, if you were able to generate a real-valued LFTX output with > 19.2kS/s, your maximum signal frequency would be 9.6kHz -- and a > "perfect" rectangular signal has infinite bandwidth, but can be well > aproximated by using sampling rates significantly higher than the symbol > rate. Since the USRPs are meant to be universal, you'll have to generate > these higher rate signals yourself -- normally on a PC (for which > 500kS/s shouldn't really make much of a load, by the way), or in the > FPGA fabric by modifying the FPGA image / using RFNoC. > > I think this might be about talking to serial hardware using one of the > RF outputs: Using a USRP's DAC is really a bit of a convoluted way of > doing this. Is there a reason you're not simply using any cheap > USB-to-Serial converter? > > Best regards, > Marcus > > On 05/11/2015 12:35 PM, Sylvain Munaut via USRP-users wrote: > > Hi, > > > > tl;dr: "No" > > > > > >> I want to generate square signal on my LFTC board. You can think of it > as a > >> RS232 signal: > >> > >> ___------___-----____----- > >> > >> at the moment I am providing samples with 500ksps. Which means that for > >> symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of > resources > >> and I would like to provide only one sample per symbol. If the DAC level > >> stays constant until next sample is provided, then since LFTX doesnt > have > >> any upconversion, it should be possible to generate above shown signal > with > >> only one sample per symbol. > > The HW could do it. > > > > But you'd have to change sw and fpga quite a bit to achieve it ... > > > > To do this, you'd need either: > > > > - An DAC clock of Fbaud which means a very low master clock rate. > > None of the USRP do that. (some even have fixed DAC clock, but you > > didn't specfy which USRP you use). > > > > - A higher DAC clock, but then just repeat the data -> The current > > DUC code doesn't do that, it will always apply a filter when > > upsampling. > > > > You best best would be a X300 with some custom RFNoC block that does > > simple sample repeating. > > > > > > > > > > Cheers, > > > > Sylvain > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Nemanja Savić

 Hi Nemanja,

 Sylvain is right -- the USRP takes the samples at the sample rate you
 specify, and constructs an analog signal out of this, guaranteeing
 that
 there's no aliasing -- which means the maximum frequency your
 signal can
 have is given by Nyquist's theorem.

 Hence, if you were able to generate a real-valued LFTX output with
 19.2kS/s, your maximum signal frequency would be 9.6kHz -- and a
 "perfect" rectangular signal has infinite bandwidth, but can be well
 aproximated by using sampling rates significantly higher than the
 symbol
 rate. Since the USRPs are meant to be universal, you'll have to
 generate
 these higher rate signals yourself -- normally on a PC (for which
 500kS/s shouldn't really make much of a load, by the way), or in the
 FPGA fabric by modifying the FPGA image / using RFNoC.

 I think this might be about talking to serial hardware using one
 of the
 RF outputs: Using a USRP's DAC is really a bit of a convoluted way of
 doing this. Is there a reason you're not simply using any cheap
 USB-to-Serial converter?

 Best regards,
 Marcus

 On 05/11/2015 12:35 PM, Sylvain Munaut via USRP-users wrote:

 think of it as a

 that for

 of resources

 DAC level

 doesnt have

 signal with

 Sylvain

 _______________________________________________
 USRP-users mailing list
 USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Nemanja, > But why I was thinkig about this is, that at the begining of the > script I always get U from USRP, and I didn't know why it can't get > enough samples. Ah! Ok, that's an interesting one, because I'm almost certain it's very little about CPU load but more about application latency. So, what I do to solve these in a general purpose way is (if the application is not already using timed commands) * I look for where i do tx_streamer->issue_stream_cmd(...); * I modify the stream_cmd_t I issue there to contain a timespec, and stream_now=false * I set the time spec to my_multi_usrp->get_time_now() + uhd::time_spec_t(1), giving me nearly 1 second to set everything up * on the first recv() call, I set the timeout to 1s however, I still stand by the fact that using a megasamples DAC to do serial binary communication is indeed wasteful -- if you'd explain why this needs to be done using the USRP's DAC (instead of some <10€ serial cable), I think we might come up with a solution that might make your life a bit easier. Best regards, Marcus On 05/11/2015 02:14 PM, Nemanja Savic wrote: > This is somehow connected with my previous posts where I explained my > setup. I am using LFTX signal to modulate carrier of the signal > generator, ... > I use 500 ksps, and symbol rate is 19.2 kBaud, which means that for > every symbol I send 500/19.2 samples. My idea was to reduce that by > sending only one sample at the begining of the symbol. In that case > the level would stay constant till the next sample (in this case also > symbo) arives. > > But why I was thinkig about this is, that at the begining of the > script I always get U from USRP, and I didn't know why it can't get > enough samples. > > On Mon, May 11, 2015 at 1:29 PM, Marcus Müller > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hi Nemanja, > > Sylvain is right -- the USRP takes the samples at the sample rate you > specify, and constructs an analog signal out of this, guaranteeing > that > there's no aliasing -- which means the maximum frequency your > signal can > have is given by Nyquist's theorem. > > Hence, if you were able to generate a real-valued LFTX output with > 19.2kS/s, your maximum signal frequency would be 9.6kHz -- and a > "perfect" rectangular signal has infinite bandwidth, but can be well > aproximated by using sampling rates significantly higher than the > symbol > rate. Since the USRPs are meant to be universal, you'll have to > generate > these higher rate signals yourself -- normally on a PC (for which > 500kS/s shouldn't really make much of a load, by the way), or in the > FPGA fabric by modifying the FPGA image / using RFNoC. > > I think this might be about talking to serial hardware using one > of the > RF outputs: Using a USRP's DAC is really a bit of a convoluted way of > doing this. Is there a reason you're not simply using any cheap > USB-to-Serial converter? > > Best regards, > Marcus > > On 05/11/2015 12:35 PM, Sylvain Munaut via USRP-users wrote: > > Hi, > > > > tl;dr: "No" > > > > > >> I want to generate square signal on my LFTC board. You can > think of it as a > >> RS232 signal: > >> > >> ___------___-----____----- > >> > >> at the moment I am providing samples with 500ksps. Which means > that for > >> symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste > of resources > >> and I would like to provide only one sample per symbol. If the > DAC level > >> stays constant until next sample is provided, then since LFTX > doesnt have > >> any upconversion, it should be possible to generate above shown > signal with > >> only one sample per symbol. > > The HW could do it. > > > > But you'd have to change sw and fpga quite a bit to achieve it ... > > > > To do this, you'd need either: > > > > - An DAC clock of Fbaud which means a very low master clock rate. > > None of the USRP do that. (some even have fixed DAC clock, but you > > didn't specfy which USRP you use). > > > > - A higher DAC clock, but then just repeat the data -> The current > > DUC code doesn't do that, it will always apply a filter when > > upsampling. > > > > You best best would be a X300 with some custom RFNoC block that does > > simple sample repeating. > > > > > > > > > > Cheers, > > > > Sylvain > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > -- > Nemanja Savić

 Sylvain

Hi all, Maybe it would be also wise to move this conversation into a new thread. At first I started with serial cable but didn't like to have start and stop bits, that was somehow not enough pseudorandom for me :) Then I decided to pack everything in the USRP, so yes I changed resistors to bump amplification in order to reach TTL level required by signal generator. Everything was fine, but as you saw in my previous threads I have two subflographs, TX and RX. TX finishes after given number of packets is generated, but I didn't know how to catch that TX has finished and then use that informtaion for stopping RX. In order to solve this I calculated time needed to transmit given number of frames and I just use sleep in my flowgraph to know when to stop (again not the best solution). When the setup was kind of usable I realized following: 1) The number of preambles that I receive in my RX path is lower than the number of preambles that I transmit. I realized that TX path starts earlier and already outputs some samples before TX path is set. I didn't know how to cope with this so I tried with introducing some dummy symbols at the begining of the stream, but it didn't help. The only thing that helped (a bit) was to start my flowgraph then to stop it and to add tx path and finally run it again. The question is how to have RX ready before TX starts. 2) I always get U at the begining so I also thought that might be the problem, but as Marcus said it shouldn't be a problem for decent computer. 3) It happens sometimes that I don't get any samples into my rx flowgraph which a big problem cause I want to make long extensive BER estimation and don't want something like that. This are basically problems that I have. Concerning your (Marcus) suggestions, I am not familiar with any of theese functions, i will have to check the documentation. Best, Nemanja On Mon, May 11, 2015 at 2:37 PM, Marcus Müller <marcus.mueller@ettus.com> wrote: > Hi Nemanja, > > But why I was thinkig about this is, that at the begining of the script I > always get U from USRP, and I didn't know why it can't get enough samples. > > Ah! Ok, that's an interesting one, because I'm almost certain it's very > little about CPU load but more about application latency. > So, what I do to solve these in a general purpose way is (if the > application is not already using timed commands) > * I look for where i do tx_streamer->issue_stream_cmd(...); > * I modify the stream_cmd_t I issue there to contain a timespec, and > stream_now=false > * I set the time spec to my_multi_usrp->get_time_now() + > uhd::time_spec_t(1), giving me nearly 1 second to set everything up > * on the first recv() call, I set the timeout to 1s > > however, I still stand by the fact that using a megasamples DAC to do > serial binary communication is indeed wasteful -- if you'd explain why this > needs to be done using the USRP's DAC (instead of some <10€ serial cable), > I think we might come up with a solution that might make your life a bit > easier. > > Best regards, > Marcus > > > On 05/11/2015 02:14 PM, Nemanja Savic wrote: > > This is somehow connected with my previous posts where I explained my > setup. I am using LFTX signal to modulate carrier of the signal generator, > ... > I use 500 ksps, and symbol rate is 19.2 kBaud, which means that for every > symbol I send 500/19.2 samples. My idea was to reduce that by sending only > one sample at the begining of the symbol. In that case the level would stay > constant till the next sample (in this case also symbo) arives. > > But why I was thinkig about this is, that at the begining of the script I > always get U from USRP, and I didn't know why it can't get enough samples. > > On Mon, May 11, 2015 at 1:29 PM, Marcus Müller <usrp-users@lists.ettus.com > > wrote: > >> Hi Nemanja, >> >> Sylvain is right -- the USRP takes the samples at the sample rate you >> specify, and constructs an analog signal out of this, guaranteeing that >> there's no aliasing -- which means the maximum frequency your signal can >> have is given by Nyquist's theorem. >> >> Hence, if you were able to generate a real-valued LFTX output with >> 19.2kS/s, your maximum signal frequency would be 9.6kHz -- and a >> "perfect" rectangular signal has infinite bandwidth, but can be well >> aproximated by using sampling rates significantly higher than the symbol >> rate. Since the USRPs are meant to be universal, you'll have to generate >> these higher rate signals yourself -- normally on a PC (for which >> 500kS/s shouldn't really make much of a load, by the way), or in the >> FPGA fabric by modifying the FPGA image / using RFNoC. >> >> I think this might be about talking to serial hardware using one of the >> RF outputs: Using a USRP's DAC is really a bit of a convoluted way of >> doing this. Is there a reason you're not simply using any cheap >> USB-to-Serial converter? >> >> Best regards, >> Marcus >> >> On 05/11/2015 12:35 PM, Sylvain Munaut via USRP-users wrote: >> > Hi, >> > >> > tl;dr: "No" >> > >> > >> >> I want to generate square signal on my LFTC board. You can think of it >> as a >> >> RS232 signal: >> >> >> >> ___------___-----____----- >> >> >> >> at the moment I am providing samples with 500ksps. Which means that for >> >> symbol 1 I provide Fs/Fbaud symbols. This can be quite a waste of >> resources >> >> and I would like to provide only one sample per symbol. If the DAC >> level >> >> stays constant until next sample is provided, then since LFTX doesnt >> have >> >> any upconversion, it should be possible to generate above shown signal >> with >> >> only one sample per symbol. >> > The HW could do it. >> > >> > But you'd have to change sw and fpga quite a bit to achieve it ... >> > >> > To do this, you'd need either: >> > >> > - An DAC clock of Fbaud which means a very low master clock rate. >> > None of the USRP do that. (some even have fixed DAC clock, but you >> > didn't specfy which USRP you use). >> > >> > - A higher DAC clock, but then just repeat the data -> The current >> > DUC code doesn't do that, it will always apply a filter when >> > upsampling. >> > >> > You best best would be a X300 with some custom RFNoC block that does >> > simple sample repeating. >> > >> > >> > >> > >> > Cheers, >> > >> > Sylvain >> > >> > _______________________________________________ >> > USRP-users mailing list >> > USRP-users@lists.ettus.com >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > > > -- > Nemanja Savić > > > -- Nemanja Savić