Re: [Discuss-gnuradio] gr-eventstream OOT module
On 04/17/2017 05:26 PM, Cinaed Simson wrote: Hi - anyone using gr-eventstream? If I recall correctly, gr-eventstream depends upon gr-mapper gr-framers gr-burst python-bitarray it does not depend on any of these ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-eventstream OOT module
Hi - anyone using gr-eventstream? If I recall correctly, gr-eventstream depends upon gr-mapper gr-framers gr-burst python-bitarray Out of the 4 OOT modules above, 3 fail the make test gr-framer, gr-mapper, and gr-eventstream all fail - gr-mapper passed. python-bitarray was installed by the OS. In python, I can import mapper import framer import burst import bitarray but I can't import es I'm installing these OOT modules under gnuradio-3.7.11 release using swig-2.0 gcc-4.9.2 and Debian 8. The failed OOT modules appear to be at least 2 years old. I'm assuming these OOT modules are independent of the hardware, e.g, I don't need UHD libraries installed. Any ideas? -- Cinaed root@cartan:/opt/gnuradio/src/gr-modules/gr-framers/build# make test Running tests... Test project /opt/gnuradio/src/gr-modules/gr-framers/build Start 1: test_framers 1/6 Test #1: test_framers . Passed0.01 sec Start 2: setup_tests 2/6 Test #2: setup_tests ..***Failed 17.00 sec Start 3: qa_gr_messages 3/6 Test #3: qa_gr_messages ...***Failed0.49 sec Start 4: qa_gr_hdlc_framer_b 4/6 Test #4: qa_gr_hdlc_framer_b ..***Failed0.34 sec Start 5: qa_gr_hdlc_deframer_b 5/6 Test #5: qa_gr_hdlc_deframer_b Passed0.35 sec Start 6: hdlc_framer_lib_test 6/6 Test #6: hdlc_framer_lib_test . Passed0.24 sec 50% tests passed, 3 tests failed out of 6 Total Test time (real) = 18.45 sec root@cartan:/opt/gnuradio/src/gr-modules/gr-burst/build# make test Running tests... Test project /opt/gnuradio/src/gr-modules/gr-burst/build Start 1: test_burst 1/2 Test #1: test_burst ...***Failed0.03 sec Start 2: qa_gr_messages 2/2 Test #2: qa_gr_messages ...***Failed0.61 sec 0% tests passed, 2 tests failed out of 2 Total Test time (real) = 0.65 sec The following tests FAILED: 1 - test_burst (Failed) 2 - qa_gr_messages (Failed) Errors while running CTest Makefile:117: recipe for target 'test' failed make: *** [test] Error 8 root@cartan:/opt/gnuradio/src/gr-modules/gr-event stream/build# make test Running tests... Test project /opt/gnuradio/src/gr-modules/gr-event stream/build Start 1: qa_es 1/1 Test #1: qa_es ***Failed0.39 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.39 sec The following tests FAILED: 1 - qa_es (Failed) Errors while running CTest Makefile:117: recipe for target 'test' failed make: *** [test] Error 8 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge Bandwidth Issues
My guess is that you're operating over USB-2.0, which can only sustain an *aggregate* (TX and RX) of ca 8Msps, as far as I know. On 2017-04-17 12:17, Santos Campos wrote: > Hello! > > I'm trying to use a b200mini to implement a relay with 6MHz of bandwidth. > Would it be feasible to do this as a time division to be able to use the same > center frequency? > > I know to not alias any data, the sampling frequency must be at least the > nyquist rate. The specs from the board seem like it can handle those > parameters easily, but it throws a channal capacity error upon running code. > > Any advice on what I'm doing wrong? > > Thanks and appreciated! > -- > > /* > Santos Campos > University of Michigan '17 | Computer Engineering > Virtual EM Inc | Engineering Intern > santosecampos.com [1] > (269)419-5113 > */ > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Links: -- [1] http://santosecampos.com___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Huge Bandwidth Issues
Hello! I'm trying to use a b200mini to implement a relay with 6MHz of bandwidth. Would it be feasible to do this as a time division to be able to use the same center frequency? I know to not alias any data, the sampling frequency must be at least the nyquist rate. The specs from the board seem like it can handle those parameters easily, but it throws a channal capacity error upon running code. Any advice on what I'm doing wrong? Thanks and appreciated! -- /* Santos Campos University of Michigan '17 | Computer Engineering Virtual EM Inc | Engineering Intern santosecampos.com (269)419-5113 */ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge delay with Osmocom sink
El 17/04/17 a las 13:58, Daniel Estévez escribió: > I was running at 1Msps. I've tested the same flowgraph at 10Msps and the > delay is now around 1 second, which seems fine. > > Is it possible to tweak the buffer sizes in an easy manner so I could > get the same effect at 1Msps? I've found that by setting a low value for "Max Output Buffer" in the cosine source then I get very little delay, even if running at 1Msps. Regards, Daniel. signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge delay with Osmocom sink
El 17/04/17 a las 13:04, Marcus Müller escribió: > Hi Daniel, > > I'm not overly happy with the splitting using Throttle: Sooner or later, > it's going to turn out either your PC or your SDR device are a few ppm > faster clocked, and then your throttle rate doesn't match your actual > sample consumption rate, and then some buffers are going to over- or > underflow. Hi Marcus, Of course, that was just a quick test. The throttle was deemed to fail eventuall due to sample rate mismatch. > The buffers are the reason you're seeing this: GNU Radio works on a > buffer interface, which means every block is producing samples as fast > as possible – that is, until the output buffer is full. Buffering is a > wanted effect – it allows for higher computational efficiency, and is > absolutely necessary when marrying a device with a fixed, deterministic > timing (i.e. the DAC/ADC of an SDR device) with a variable-scheduling, > non-deterministic computer (i.e. software running in a general-purpose > operating system on a general-purpose CPU). > > Now, 5s sounds like way too much. Maybe you're operating your SDR device > at a very low sampling rate? Try to use a higher one (and drop the > throttle and UDP sink/source split). That would make the buffers (which > keep their size in samples) "shorter" in terms of time. I was running at 1Msps. I've tested the same flowgraph at 10Msps and the delay is now around 1 second, which seems fine. Is it possible to tweak the buffer sizes in an easy manner so I could get the same effect at 1Msps? Regards, Daniel. signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge delay with Osmocom sink
Hi Daniel, I'm not overly happy with the splitting using Throttle: Sooner or later, it's going to turn out either your PC or your SDR device are a few ppm faster clocked, and then your throttle rate doesn't match your actual sample consumption rate, and then some buffers are going to over- or underflow. The buffers are the reason you're seeing this: GNU Radio works on a buffer interface, which means every block is producing samples as fast as possible – that is, until the output buffer is full. Buffering is a wanted effect – it allows for higher computational efficiency, and is absolutely necessary when marrying a device with a fixed, deterministic timing (i.e. the DAC/ADC of an SDR device) with a variable-scheduling, non-deterministic computer (i.e. software running in a general-purpose operating system on a general-purpose CPU). Now, 5s sounds like way too much. Maybe you're operating your SDR device at a very low sampling rate? Try to use a higher one (and drop the throttle and UDP sink/source split). That would make the buffers (which keep their size in samples) "shorter" in terms of time. Best regards, Marcus On 17.04.2017 12:29, Daniel Estévez wrote: > Hi guys, > > I'm using the Osmocom sink with a LimeSDR. I'm testing with a very > simple flowgraph (attached): a cosine source's amplitude is toggled > according to the state of a QT push button, thus getting a crude CW > transmitter. > > The problem I'm seeing is that there is a huge delay (about 5 seconds) > between the moment I press the button to the moment that the RF goes out > on the air. I think that the cause is that the LimeSDR takes around 5 > seconds to start working, so the cosine source is holding back 5 seconds > worth of samples until the Oscomocom sink starts consuming samples. > > If I split this flowgraph into two as follows: > > 1st) cosine -> throttle -> udp sink > 2nd) upd source -> osmocom sink > > and I start the second flowgraph and then the first, then I get little > delay, but this is a very ugly hack. > > Is there a good way to solve this issue? > > Regards, > > Dani. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Huge delay with Osmocom sink
Hi guys, I'm using the Osmocom sink with a LimeSDR. I'm testing with a very simple flowgraph (attached): a cosine source's amplitude is toggled according to the state of a QT push button, thus getting a crude CW transmitter. The problem I'm seeing is that there is a huge delay (about 5 seconds) between the moment I press the button to the moment that the RF goes out on the air. I think that the cause is that the LimeSDR takes around 5 seconds to start working, so the cosine source is holding back 5 seconds worth of samples until the Oscomocom sink starts consuming samples. If I split this flowgraph into two as follows: 1st) cosine -> throttle -> udp sink 2nd) upd source -> osmocom sink and I start the second flowgraph and then the first, then I get little delay, but this is a very ugly hack. Is there a good way to solve this issue? Regards, Dani. test.grc Description: application/gnuradio-grc signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
