[Discuss-gnuradio] fails to add two data stream properly
Dear all, I'm trying add two streams together before sending to usrp_source, suppose they are signal A and signal B, signal A comes from burst transmission, so there exits gaps between two packets, while signal B is the real streaming data. I tried to use blocks.add_cc() function to add them together (already shifted them to different frequency before adding). However, I found that this function will only be called when both inputs have data. Therefore, we are going to lose a lot in signal B since signal A is on and off while signal B is almost continuously. I am wondering whether there exist some functions that can help to add burst signal and streaming data together without losing anything in both. I have been struggling with this for a long time.:( Thanks a lot for your help in advance! Best, Yang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] stop/start is not called in gr.basic_block
Hi Guys, I am trying to implement a simple block in python but it seems that stop and start is never called when I implement them. The bare bones python code would be this: class test(gr.basic_class): def __init__(self): gr.basic_block.__init__(self, name="test", in_sig=None, out_sig=None) def start(self): print "never called" return gr.basic_block.start(self) The same works in C++. I could not find any example that implements start/stp in python, but looking at the docs for gr.basic_block it should work. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] repeated saving binary file without stopping the gnuradio
Hi everyone, I have bought a new RTL-SDR dongle USB. The dongle had success receiving the continuous RF signal from function generator (FG) directly. I set the frequency and amplitude are 53.7 MHz and 1 mVpp. I connect the FG to the dongle directly and from the dongle, I connect to the USB port PC directly. I tried saving the waterfall output into binary file using gnuradio under Ubuntu 16.10 (64 bit) after stopping the gnuradio but now I have the problem to save the waterfall output in every 5 minutes into binary file repeatedly without stopping the gnuradio. I do not know how to solve it. I please and appreciate any help. Thank you very much. Regards Mario Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cheap sdr platform / OpenSource-Hardware
Yes, for some student and hobby experiments we need cheaper SDR. I like the idea of OpenSource-Hardware. Material cost is usually not too high. And it's possible to modify designs, improve it, strip down for cheaper variants ... A good toy for hardware-experimenting and to gain experience in electronics design. Some people are even more interested in the hardware designs than in SDR software. So, EDA files, schematics, ... The best for educational purpose is to have it all OpenSource. There are several OpenSource/OpenHardware SDR-Projects: FreeSRP http://freesrp.org/ http://electronics.kitchen/misc/freesrp/ HackRF http://greatscottgadgets.com/hackrf/ https://github.com/mossmann/hackrf LimeSDR/-mini https://wiki.myriadrf.org/LimeSDR-USB https://github.com/myriadrf/LimeSDR-Mini Kiwi SDR http://kiwisdr.com/kiwisdr/ http://kicad-pcb.org/made-with-kicad/kiwisdr/ some other projects https://github.com/myriadrf A64-OLinuXino, similar to Raspberry https://github.com/OLIMEX/OLINUXINO There's also a free OpenSource EDA Tool KiCad. It lacks several features, but you can use it even for bigger projects: http://kicad-pcb.org/made-with-kicad/ Am 29.09.2017 um 10:18 schrieb w xd: Hello guys, Have some suggestion on the cheaper SDR platform for us to use with the GNURADIO software? As a student, I cannot buy the expensive usrp ,but I want to learn the knowledge by the hardware and software. Any recommend? For example,use the hardware to do some experiments about LTE/WIFI. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing
The conversion error of clocks should be negligible compared to audio sample rate as we are dealing with microseconds timer. No. I'll stop contributing to this discussion now. The average sound card has a 25ppm clock accuracy, according to design specs of Texas Instrument audio ADC/DAC ICs. So, that's way, way better than your CPU clock, and even more better than your CPU clock sampled through a system call in a non-realtime userland application. I wish you the best with your application! I'm clearly not helping you, because I feel that you're still repeating things that I've already tried to explain. Best regards, Marcus On 10/04/2017 07:09 PM, Benny Alexandar wrote: >>Yeah. But that doesn't help at all, since clock recovery of any digital receiver will give you samples resampled to the transmitter's clock... >>Anyway, notice how you say "roughly". Now, compare that "roughness" to the "roughly the same" transmitter and receiver audio clock. >>You're at least in the same order of magnitude here, and my point is that by introducing yet another clock into this >>(the abyssimal bad PC clock), you're making things way worse than they need be, and atop of that, unnecessarily complicated. Actually there exist a resampler at the input as well. After clock recovery the base band samples are synchronized with transmitter. Then the symbols which make the transmission frames are timestamped. At this point we are in sync with transmitter. The conversion error of clocks should be negligible compared to audio sample rate as we are dealing with microseconds timer. If you read Fons paper again, you will find his paper uses *some* clock which can be CPU, or real-time or any clock. According to him "The stability of the timer used to get timestamps on both the input and output streams of the resampler doesn't matter much, it basically almost disappears from the equations. Any random variations will be smoothed by a DLL." >> Again, I don't see where you see the audio device clock in your system. >> I'd be very thankful if you could explain **that** to me, since well, there's no clock line between my sound card and my CPU. One way to make a sound card clock is to use the callback from JACK or ALSA and count samples. The code must be robust in the sense that at no time, must even a single sample be lost. With JACK this should be possible, and the callback happens precisely when the number of samples configured for the buffer is over. >> nd we're stating the original problem again. >> We don't know any of these rates relative to any other of these rates. Now the audio decoded is synchronized to transmitter rate and send to sound card. By using a resampler this audio clock is adjusted to sound card clock rate. -ben *From:* Benny Alexandar *Sent:* Tuesday, October 3, 2017 11:18 PM *To:* Marcus Müller; GNURadio Discussion List *Subject:* Re: [USRP-users] Audio Control loop testing By using the PC clock, and calling set time now with the current PC time before scheduling streaming. This will make the USRP tick counter roughly match the PC clock. usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); Then use the Jack audio clock and maps this audio clock to system one . At the input side USRP decides the input rate, slave the audio to this rate. -ben *From:* Benny Alexandar *Sent:* Friday, September 29, 2017 11:59 PM *To:* Marcus Müller; GNURadio Discussion List *Subject:* Re: [USRP-users] Audio Control loop testing >> you don't *get* the sound card clock anywhere in software. If you did, there would >> be no problem Jack uses audio clock and maps this audio clock to system one with the use of DLL (delay locked loop). -ben *From:* Benny Alexandar *Sent:* Wednesday, September 27, 2017 10:45 PM *To:* Marcus Müller; GNURadio Discussion List *Subject:* Re: [USRP-users] Audio Control loop testing >>Could you maybe elaborate how you're planning to solve all a),b),c) instead of asking for new feedback? For a) & b) will use the sound card clock and using micro seconds timer. And for c) run the decoded PCM through a FIFO buffer this is a local buffer which is not part of gnu-radio connect buffers, between the SRC and the play-out stage. The trade-off for this approach of course is increased latency. This way any variable work-load length is not going to affect and the local fifo will have fixed length. Timing errors needs to be filtered using DLL which is the same used in JACK. -ben And as also said earlier, I don't believe very much that it will work that easily, since the CPU clock is a) worse than the typical SDR and sound card clocks, b) has
Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing
>>Yeah. But that doesn't help at all, since clock recovery of any digital >>receiver will give you samples resampled to the transmitter's clock... >>Anyway, notice how you say "roughly". Now, compare that "roughness" to the >>"roughly the same" transmitter and receiver audio clock. >>You're at least in the same order of magnitude here, and my point is that by >>introducing yet another clock into this >>(the abyssimal bad PC clock), you're making things way worse than they need >>be, and atop of that, unnecessarily complicated. Actually there exist a resampler at the input as well. After clock recovery the base band samples are synchronized with transmitter. Then the symbols which make the transmission frames are timestamped. At this point we are in sync with transmitter. The conversion error of clocks should be negligible compared to audio sample rate as we are dealing with microseconds timer. If you read Fons paper again, you will find his paper uses *some* clock which can be CPU, or real-time or any clock. According to him "The stability of the timer used to get timestamps on both the input and output streams of the resampler doesn't matter much, it basically almost disappears from the equations. Any random variations will be smoothed by a DLL." >> Again, I don't see where you see the audio device clock in your system. >> I'd be very thankful if you could explain **that** to me, since well, >> there's no clock line between my sound card and my CPU. One way to make a sound card clock is to use the callback from JACK or ALSA and count samples. The code must be robust in the sense that at no time, must even a single sample be lost. With JACK this should be possible, and the callback happens precisely when the number of samples configured for the buffer is over. >> nd we're stating the original problem again. >> We don't know any of these rates relative to any other of these rates. Now the audio decoded is synchronized to transmitter rate and send to sound card. By using a resampler this audio clock is adjusted to sound card clock rate. -ben From: Benny Alexandar Sent: Tuesday, October 3, 2017 11:18 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing By using the PC clock, and calling set time now with the current PC time before scheduling streaming. This will make the USRP tick counter roughly match the PC clock. usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); Then use the Jack audio clock and maps this audio clock to system one . At the input side USRP decides the input rate, slave the audio to this rate. -ben From: Benny Alexandar Sent: Friday, September 29, 2017 11:59 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing >> you don't get the sound card clock anywhere in software. If you did, there >> would >> be no problem Jack uses audio clock and maps this audio clock to system one with the use of DLL (delay locked loop). -ben From: Benny Alexandar Sent: Wednesday, September 27, 2017 10:45 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing >>Could you maybe elaborate how you're planning to solve all a),b),c) instead >>of asking for new feedback? For a) & b) will use the sound card clock and using micro seconds timer. And for c) run the decoded PCM through a FIFO buffer this is a local buffer which is not part of gnu-radio connect buffers, between the SRC and the play-out stage. The trade-off for this approach of course is increased latency. This way any variable work-load length is not going to affect and the local fifo will have fixed length. Timing errors needs to be filtered using DLL which is the same used in JACK. -ben And as also said earlier, I don't believe very much that it will work that easily, since the CPU clock is a) worse than the typical SDR and sound card clocks, b) has different resolutions, c) and needs to still be sufficiently interpolatable for the jittery, variable-workload-length that GNU Radio has. The point c) is what's different for Jack internally, because that can work on fixed-length buffers. This is a comment that you've gotten from me (and by the way, Fons, too) multiple times now. Could you maybe elaborate how you're planning to solve all a),b),c) instead of asking for new feedback? From: Benny Alexandar Sent: Wednesday, September 27, 2017 6:50 AM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing Hi Marcus, As said earlier there is no true clock as such. We need to rely on CPU clock and measure the deviation. The reference clock is the transmitter time duration between two symbols which
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'square_ff'
Hi Seref, You'll have to explain what exactly you did. Where's the "square_ff" coming from? On 10/04/2017 05:00 PM, seref ay wrote: Hi everyone, I am using gr-iee802-11 transceiver by Bastian Bloessl. The flow graph is working fine, but when I try to add a new block with gr_modtool ( a simplle block that squares a floating constant ) then it throws this error: "AttributeError: 'module' object has no attribute 'square_ff'" . What could be the problem and how can I solve it? I am using Ubuntu 16.10 (64 bit). I please and appreciate any help. Thanks Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AttributeError: 'module' object has no attribute 'square_ff'
Hi everyone, I am using gr-iee802-11 transceiver by Bastian Bloessl. The flow graph is working fine, but when I try to add a new block with gr_modtool ( a simplle block that squares a floating constant ) then it throws this error: "AttributeError: 'module' object has no attribute 'square_ff'" . What could be the problem and how can I solve it? I am using Ubuntu 16.10 (64 bit). I please and appreciate any help. Thanks Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 4FSK demodulation
Hi, I have to come back with this question as I didn't receive an answer the first time. Is there any better way to demodulate 4FSK than using a constellation receiver? Right now, my RX path is FM demod -> M clock sync -> constellation decoder. It does seem like a non optimal way of recovering 4FSK symbols. Can it be done better? Thanks for any answers, Adrian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
