Hello guys,
Is https://github.com/buoyboy/pre-cog down
or I am the only one not being able to have access?
-George
https://github.com/jmalsbury/pre-cog
https://github.com/buoyboy/pre-cog
On Mon, Feb 4, 2013 at 7:41 PM, George S. <
Hi,
Even I am not able to open it. even the wiki of pre-cog isn’t
opening.
But the wiki is down… 404.
On Mon, Feb 4, 2013 at 9:47 PM, John M.
[email protected]wrote:
Is https://github.com/buoyboy/pre-cog down
Discuss-gnuradio mailing list
–
Alex,
Dreams can come true just believe.
Hi John,
I suspected that this was where it has transferred. Though, by
installing
pre-cog along with the extras and using
the packet_framing of precog instead of extras I get the following error
as
I posted before,
gr_fir_fff: using SSE
Uhandler caught exception: in method
‘gr_block_gw_message_type_work_args_return_value_set’,
argument 2 of type ‘int’
Traceback (most recent call last):
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py”,
line 53, in eval
try: self._callback()
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py”,
line 124, in __gr_block_handle
) for i in self.__out_indexes],
TypeError: in method
‘gr_block_gw_message_type_work_args_return_value_set’,
argument 2 of type ‘int’
thread[thread-per-block[5]: <gr_block mod_pkts2 (3)>]: caught
unrecognized
exception************
What is more, after replacing packet_framer with the framer of extras
repo,
by trying to simulate
only the PHY level of precog
transmitter
(Vector_source → stream_to_blob → GMSK_mod → packet_framer →
multiplier → Burst-Tag → USRP_sink)
and on the other side
receiver:
(USRP_source → packet_deframer → GMSK_demod → blob_to_s)
On 2/4/13 10:42 PM, John M. wrote:
https://github.com/jmalsbury/pre-cog
https://github.com/buoyboy/pre-cog
On Mon, Feb 4, 2013 at 7:41 PM, George S. <
[email protected]> wrote:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Sklivanitis Georgios
Ph.D Student
Communications Division,
Department of Electronics and Electrical Engineering
University at Buffalo, The State University of New York
North Campus, Office 205, Furnas Hall
Buffalo, NY 14260www.acsu.buffalo.edu/~gsklivan
Hi John,
I suspected that this was where it has transferred. Though, by
installing pre-cog along with the extras and using
the packet_framing of precog instead of extras I get the following error
as I posted before,
gr_fir_fff: using SSE
Uhandler caught exception: in method
‘gr_block_gw_message_type_work_args_return_value_set’, argument 2 of
type ‘int’
Traceback (most recent call last):
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py”,
line 53, in eval
try: self._callback()
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py”,
line 124, in __gr_block_handle
) for i in self.__out_indexes],
TypeError: in method
‘gr_block_gw_message_type_work_args_return_value_set’, argument 2 of
type ‘int’
thread[thread-per-block[5]: <gr_block mod_pkts2 (3)>]: caught
unrecognized exception
What is more, after replacing packet_framer with the framer of extras
repo, and trying to simulate
only the PHY level of precog
transmitter
(Vector_source -> stream_to_blob -> GMSK_mod -> packet_framer ->
multiplier -> Burst-Tag -> USRP_sink)
and on the other side
receiver:
(USRP_source -> packet_deframer -> GMSK_demod -> blob_to_stream ->
file_sink)
I cannot see any data coming even with the USRP’s front ends connected
with a coaxial cable.
I am using USRP2s and RFX2400 daughtercards.
Thanks,
-George
On 2/4/13 10:42 PM, John M. wrote:
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
Sklivanitis Georgios
Ph.D Student
Communications Division,
Department of Electronics and Electrical Engineering
University at Buffalo, The State University of New York
North Campus, Office 205, Furnas Hall
Buffalo, NY 14260
www.acsu.buffalo.edu/~gsklivan
I am sorry, it was a typo.
The grc file generating the reported error is attached.
-George
The file worked for me, but I’m testing with a machine with an older
version of GNU Radio (3.6.2). I will upgrade and retest. In the
meantime,
can you remove the burst gate and tell me if the flowgraph runs without
error?
-John
On Mon, Feb 4, 2013 at 8:06 PM, George S. <
… GMSK_mod -> packet_framer -> multiplier -> Burst-Tag …
the packet_framer should come before the modulator. Not after. Is this
actually how it is connected or is there just a typo?
Send me the GRC file.
On Mon, Feb 4, 2013 at 7:54 PM, George S. <
George,
I don’t have any hardware where I am, so I have the UHD source disabled.
The speed (or lack there of) of the python block may be what is causing
this issue. It’s also possible that the async. nature of the msg-based
blocks means there’s no back pressure on your vector_source block and it
is
generating samples as quickly as the cpu allows. (anyone, chime in if
you
know better?) When I insert a throttle before the stream to blob
conversion, things seem to work OK.
See attached.
I’ve also attached another example for you to work with that has working
mod and demod setup with a ‘heartbeat’ block that generates a periodic
message.
-John
On Mon, Feb 4, 2013 at 8:28 PM, George S. <
John,
Thanks for the attachments.
I think that “the async. nature of the msg-based blocks means there’s no
back pressure on your vector_source block” was the problem.
Thanks again,
-George
I am in v3.6.2.-3 and the problem still appears after removing the burst
gate.
Moreover, is there a way to test the data after the conversion of the
stream to blobs, either through Octave or Matlab (by connecting a file
sink
at the flowgraph)?
-George