Re: [Discuss-gnuradio] pipe trick
At 03:02 AM 4/10/2005 -0400, you wrote: How are you _reading_ the data from the pipe? Even if you're flushing the data into the pipe after every write, the reader could be buffering it. Tks Dave - yes, yesterday I put a vector_sink_b after the file_descriptor_source of the pipe and verified that it is reading ALL the date sent across it. That is, after sending 20 \0xaa characters, the vector contains (170, 170, 170, 170 ... 170, 170) all 20 of them. The little trickle of data going out to the usrp every byte written is interesting and just now measured this: bytes written to pipe size of output to usrp meaning - --- 2 49144 6143 complex samples 49144 / 8 6143+1 = 3 * 2048 2048 is size of bytes_to_syms interpolation 3 65528 8191 complex samples 8192+1 = 4 * 2048 4 81912 10239 complex samples 10239+1 = 5 * 2048 etc Every byte written to the pipe is /supposed/ to produce 8 * 2048 * 25 = 409600 samples the output rate to the usrp is 1.6msps (usrp interpolates by 80 to get 128e6) so it only has to write about 4 characters / second to the pipe to keep it stuffed ( or approximately 3.906 as Spock would say ).Then, as soon as I close the pipe after getting these little 'ticks' of data, boom, it takes off and processes the data at full speed and produces the correct output and prints text on a nearby receiver and psk31 software. This didn't happen with a pipe head and a sound card sink - only with the usrp at the tail. Even changed the bytes_to_syms interpolation back to 256 as in the sound card version, but still get the same issue with the usrp. Interestingly, the X25 interp fir filter doesn't show up mathematically in the output, even tho it's in the stream. It's like the entire gnuradio stream is being clocked by the pipe and the X2048 bytes_to_syms interpolator at the beginning. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pipe trick
Proviso: I could be *seriously* misunderstanding what's up here. If so, my apologies and please ignore. Have you tried setting the pipe reads/writes to O_NONBLOCK, and checking on read to see whether anything actually arrived? Obviously you wouldn't want to be spinning on empty reads, so select() would be your friend. Frank AB2KT Chuck Swiger wrote: At 03:02 AM 4/10/2005 -0400, you wrote: How are you _reading_ the data from the pipe? Even if you're flushing the data into the pipe after every write, the reader could be buffering it. Tks Dave - yes, yesterday I put a vector_sink_b after the file_descriptor_source of the pipe and verified that it is reading ALL the date sent across it. That is, after sending 20 \0xaa characters, the vector contains (170, 170, 170, 170 ... 170, 170) all 20 of them. The little trickle of data going out to the usrp every byte written is interesting and just now measured this: bytes written to pipe size of output to usrp meaning - --- 2 49144 6143 complex samples 49144 / 8 6143+1 = 3 * 2048 2048 is size of bytes_to_syms interpolation 3 65528 8191 complex samples 8192+1 = 4 * 2048 4 81912 10239 complex samples 10239+1 = 5 * 2048 etc Every byte written to the pipe is /supposed/ to produce 8 * 2048 * 25 = 409600 samples the output rate to the usrp is 1.6msps (usrp interpolates by 80 to get 128e6) so it only has to write about 4 characters / second to the pipe to keep it stuffed ( or approximately 3.906 as Spock would say ).Then, as soon as I close the pipe after getting these little 'ticks' of data, boom, it takes off and processes the data at full speed and produces the correct output and prints text on a nearby receiver and psk31 software. This didn't happen with a pipe head and a sound card sink - only with the usrp at the tail. Even changed the bytes_to_syms interpolation back to 256 as in the sound card version, but still get the same issue with the usrp. Interestingly, the X25 interp fir filter doesn't show up mathematically in the output, even tho it's in the stream. It's like the entire gnuradio stream is being clocked by the pipe and the X2048 bytes_to_syms interpolator at the beginning. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Affordable A/D board available soon
I am working on a low-cost A/D board that samples at 24 MSPS with 12 bits of resolution and expect to have ten boards ready by the end of April. There is information about it at http://comsec.com/wiki?N1ibtSoftwareRadioBoard. I wanted to let people on this list know about it for a couple of reasons. One, I'm hoping to have it ready soon enough that it might be of some legal use in combatting the broadcast flag ruling. Two, the hardware is coming along fine, but given how quickly July 1st is coming, I may want to ask for help with programming the FX2, the FPGA, and any tweaks that may be necessary in GNU Radio itself. I'm aiming to make this board cost about $100 to keep it affordable for students, and the schematic and Gerber files are posted online (though I haven't yet built and tested the board). It's a two-layer board, designed with Eagle Light, using a 100-pin FX2, a Xilinx Spartan-3 FPGA, and a AD9225 ADC. The initial run will be ten boards, and I'll be happy to lend or sell them to people willing to assist with firmware/software development, particularly in the Boston area. Thanks, Will Ware ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pipe trick
I examined the internal buffering and thread scheduling code in the GnuRadio core. The scheduler is "sink-driven", as I understand it, relying on USRP polling to pull data from the internal buffers. It has been arranged to have sufficient data ready to go, since the USRP must transmit isochronously. Modifying the scheduler is non-trivial because of the issues in getting the right amount of data for each processing block. The way it's written now works ok for continuous flows, but is not too good for "event driven" packet radios. Even for continuous flows, there is a little bit of a problem with matching the transmit and receive clocks. The MSK modulation tolerates this ok, but wouldn't work so well at high bitrates. We are interested in pursuing an event-driven scheduler and transmit keying so that we could adapt this code to a packet radio. What's holding us off is that we don't want to deviate from GR mainline development. It would be nice to have an idea what the schedule is. At 09:40 AM 4/10/2005, Chuck Swiger wrote: At 03:02 AM 4/10/2005 -0400, you wrote: How are you _reading_ the data from the pipe? Even if you're flushing the data into the pipe after every write, the reader could be buffering it. Tks Dave - yes, yesterday I put a vector_sink_b after the file_descriptor_source of the pipe and verified that it is reading ALL the date sent across it. That is, after sending 20 \0xaa characters, the vector contains (170, 170, 170, 170 ... 170, 170) all 20 of them. The little trickle of data going out to the usrp every byte written is interesting and just now measured this: bytes written to pipe size of output to usrp meaning - --- 2 49144 6143 complex samples 49144 / 8 6143+1 = 3 * 2048 2048 is size of bytes_to_syms interpolation 3 65528 8191 complex samples 8192+1 = 4 * 2048 4 81912 10239 complex samples 10239+1 = 5 * 2048 etc Every byte written to the pipe is /supposed/ to produce 8 * 2048 * 25 = 409600 samples the output rate to the usrp is 1.6msps (usrp interpolates by 80 to get 128e6) so it only has to write about 4 characters / second to the pipe to keep it stuffed ( or approximately 3.906 as Spock would say ). Then, as soon as I close the pipe after getting these little 'ticks' of data, boom, it takes off and processes the data at full speed and produces the correct output and prints text on a nearby receiver and psk31 software. This didn't happen with a pipe head and a sound card sink - only with the usrp at the tail. Even changed the bytes_to_syms interpolation back to 256 as in the sound card version, but still get the same issue with the usrp. Interestingly, the X25 interp fir filter doesn't show up mathematically in the output, even tho it's in the stream. It's like the entire gnuradio stream is being clocked by the pipe and the X2048 bytes_to_syms interpolator at the beginning. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Affordable A/D board available soon
Will Ware wrote: http://comsec.com/wiki?N1ibtSoftwareRadioBoard. I like it! -rick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installation Guide
Since there seems to be a lot of questions on getting all the software installed for GNU radio, I've put together an installation guide and shell scripts to hopefully greatly simplify the process: http://www.kd7lmo.net/ground_gnuradio_install.html All comments and suggestions are appreciated. If they are helpful, maybe someone can post them to the Wiki or link to these pages from the Wiki. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
