Re: [Discuss-gnuradio] CDMA
Alfred, not all of what you are saying here can be true at the same time! In your previous email you said that gr-cdma is downloaded in "\home\gr-cdma" Now you are saying that this directory is actually "/home/alfred/gr-cdma" which is correct anyway? if the latter, then you have to set your prefix in the cdma_parameters file equal to "/home/alfred/gr-cdma/" Do that and then retry to import it in python. Also, as has been mentioned numerous times on this list, I strongly advise you to NOT do all these as root but as a regular user. Achilleas On Tue, Sep 29, 2015 at 9:36 AM, alfred noble wrote: > Thank you Achilleas > about permission , yes I am doing it as root > I opened the terminal in gr-cdma directory and ran 'ls -l' command as you > said , and I see all files and folder in this directory such as app , cmake > and also python and other , then in the same terminal I ran the command > 'pwd' and I received the following , > /home/alfred/gr-cdma > > Thanks > Alfred > > > On Tue, Sep 29, 2015 at 4:21 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> can you go inside the gr-cdma directory and do "ls -l". >> you should see several directories like apps, python etc. >> Now do "pwd" in the linux prompt and let us know the result. >> >> On Tue, Sep 29, 2015 at 8:43 AM, alfred noble >> wrote: >> >>> Thanks >>> My operating system is Ubuntu 15.04 64 bit >>> >>> Alfred >>> >>> On Tue, Sep 29, 2015 at 3:49 PM, Achilleas Anastasopoulos < >>> achilleas.anastasopou...@gmail.com> wrote: >>> What operating system are you working on? Achilleas On Sep 29, 2015, at 2:22 AM, alfred noble wrote: Thanks when I did git clone https://github.com/anastas/gr-cdma.git the file (gr-cdma) was downloaded in the following directory home\gr-cdma as it was expected Best regards Alfred >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Python block inputting vectors of random sizes
Good day everyone
Could some please explain to me where I'm missinterpreting how to implement
a block. My block code is
import numpy as np
from gnuradio import gr
class compress_ff(gr.sync_block):
"""
Compressing Block
"""
def __init__(self, n, m):
global phi
N = n
M = m
phi =
np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy"
%{"M":M,"N":N})
gr.sync_block.__init__(self,
name="compress_cc",
in_sig=[(np.float32,N)],
out_sig=[(np.float32,M)])
def work(self, input_items, output_items):
in0 = input_items[0]
print "compin0"
print np.shape(in0)
in0 = in0.conj().transpose()
out = np.dot(phi,in0)
out = out.conj().transpose()
# <+signal processing here+>
output_items[0][:] = out
return len(output_items[0])
which I would expect to take in an N length vector and return an M length
vector. However my input vector, in0. Seems to be arbitarially (random
number, N) in size. The random number is a multiple of four which I presume
is due to the data type. I have matching data types so I am confuse as to
why its not creating a (1,N) vector. Any help would be greatly appreciated.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
Thank you so much Achilleas Every thing is fine , PROBLEM SOLVED I'm looking forward to reciprocating your help as soon as possible Thank you so much again and every one in this group. *Best wishes * *Alfred* On Tue, Sep 29, 2015 at 5:55 PM, Achilleas Anastasopoulos wrote: > Alfred, > > not all of what you are saying here can be true at the same time! > > In your previous email you said that gr-cdma is downloaded in > "\home\gr-cdma" > Now you are saying that this directory is actually > "/home/alfred/gr-cdma" > > which is correct anyway? > > if the latter, then you have to set your prefix in the cdma_parameters > file equal to > "/home/alfred/gr-cdma/" > > Do that and then retry to import it in python. > > Also, as has been mentioned numerous times on this list, I strongly advise > you to NOT do all these as root but as a regular user. > > Achilleas > > > On Tue, Sep 29, 2015 at 9:36 AM, alfred noble > wrote: > >> Thank you Achilleas >> about permission , yes I am doing it as root >> I opened the terminal in gr-cdma directory and ran 'ls -l' command as you >> said , and I see all files and folder in this directory such as app , cmake >> and also python and other , then in the same terminal I ran the command >> 'pwd' and I received the following , >> /home/alfred/gr-cdma >> >> Thanks >> Alfred >> >> >> On Tue, Sep 29, 2015 at 4:21 PM, Achilleas Anastasopoulos < >> anas...@umich.edu> wrote: >> >>> can you go inside the gr-cdma directory and do "ls -l". >>> you should see several directories like apps, python etc. >>> Now do "pwd" in the linux prompt and let us know the result. >>> >>> On Tue, Sep 29, 2015 at 8:43 AM, alfred noble >>> wrote: >>> Thanks My operating system is Ubuntu 15.04 64 bit Alfred On Tue, Sep 29, 2015 at 3:49 PM, Achilleas Anastasopoulos < achilleas.anastasopou...@gmail.com> wrote: > What operating system are you working on? > > Achilleas > > On Sep 29, 2015, at 2:22 AM, alfred noble > wrote: > > Thanks > when I did git clone https://github.com/anastas/gr-cdma.git > the file (gr-cdma) was downloaded in the following directory > home\gr-cdma > as it was expected > > Best regards > Alfred > > >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Connecting a message input port in hier_block2 disconnects a stream output port
Dear all, I've done some debugging in gnuradio-runtime and made the following observations: - When not connecting the message ports in my example, gnuradio-runtime flattens the hier block, so that only the child blocks remain in the flattened flowgraph. This behavior is correct. - Connecting the message port of the hier_block2 results in the flattening process to only partly succeed. The flatten_aux function fails to determine that the message ports of the hier_block2 are hierarchical, and therefore the message ports (and hier block itself) remain in the flattened graph as normal connections instead of being resolved. The output ports of the hier block are furthermore disconnected (I'm not sure why exactly) which causes the flowgraph validation to fail. - Tracing back why flatten_aux determines that the message ports are not hierarchical, I found the following lines in hier_block2_detail.cc: -- bool hier_out = (d_owner == src.get()) && src->message_port_is_hier_out (srcport);; bool hier_in = (d_owner == dst.get()) && dst->message_port_is_hier_in (dstport); -- At first it seemed to me that this was a small error because d_owner is always top_block for the connections of my hier_block2 and therefore the expression will evaluate to false. Changing these lines to the following resolves the problem I described above: --- bool hier_out = (d_owner != src.get()) && src->message_port_is_hier_out (srcport); bool hier_in = (d_owner != dst.get()) && dst->message_port_is_hier_in (dstport); --- Now, the ports are correctly determined to be hierarchical, and flatten_aux flattens the hier block in the example I provided (I can also successfully connect a debug_message() block residing within the hier_block2 to the message_prober). However, one QA test related to the hier block now fails, so this is probably not an ideal approach and I need to do some further digging to resolve this matter. Kind regards, Pieter Robyns 2015-09-27 19:09 GMT+02:00 Pieter ROBYNS : > Dear all, > > While experimenting with hier_block2 I noticed that connecting an input > message port appears to disconnect an unrelated stream output port. I've > attached a simple example Python script to show what I mean. > > Basically, the example script creates a hier_block2 with a null source and > throttle block. The hier_block2 is then connected to a null sink. > Furthermore, it has an input message_port for control messages. The script > runs fine when the input message_port is not connected. However, when > connecting the message_port, the following error is returned: > > RuntimeError: hier_block_test(2): insufficient connected output ports (1 > needed, 0 connected) > > Am I missing something or might this be a bug? If I change the hier_block2 > to have 0 stream outputs (in the output signature), the error goes away, > but in my use case I need to have one stream output and one control message > input. > > > Kind regards, > Pieter Robyns > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Accessing write_eo, write_io in GRC.
Hi everyone! I have a GNURadio project running on Kubuntu 14.04 using GNURadio Companion v3.7.2.1 along with several OOT blocks that I wrote. (I know I'm a bit behind on the releases.) A lot of the code was originally written in v3.6 so some of what follows may be me conflating old interface with newer. I have custom hardware that uses Ettus USRP boards. I've been bypassing the custom front-end and just adjusting the expected center frequency on the UHD: USRP Source block but now I'd like to actually control the hardware. That means I'd like to access the write_eo() and write_io() calls so I can enable and initialize the output pins on the USRP and write to an external PLL LO for down conversion to set frequency. My 3.6-based code just called write_io from the usrp instance in C++ code. But I can't figure out how to get to the USRP write_eo and write_io calls from a 3.7.2.1 GNURadio Companion starting point. I've tried adding code to the Python output of GRC like this: ### self.u = uhd.usrp_source( device_addr="fpga=usrp1_fpga_4rx.rbf", stream_args=uhd.stream-args(cpu_format="fc32", channels=range(4),),) # I added this line to GNURadio Companion output code self.u.write_oe (1, 0x, 0x) ### but Python can't find the write_oe or write_io methods. Am I missing an import in Python? A path? Is there anyway to do this in the GRC blocks so I don't have to modify the output Python? Do I have to do this as an OOT block and call the uhd usrp make myself? (although I don't see the write_io or write_oe methods in usrp_source.h anymore) Thanks in advance, Kathy Hertzog ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] foreacast (mis)behavior for gating block
I am writing a block that acts as a gate: it only consumes when locked and passes samples when unlocked. The gate state is generally controlled by tags on its input stream. Thus there is no a priori known input/output relationship. When testing, the block performs as expected until some number of samples are processed (input to the block) after which it seems general_work is no longer called. Adding a number of debug statements, I find at the point of starvation I get the following repeated forecast sequence w/o a call to general_work in between gr::debug :INFO: frame_sync_c0 - Forecast 4096 gr::debug :INFO: frame_sync_c0 - Forecast 2048 gr::debug :INFO: frame_sync_c0 - Forecast 1024 gr::debug :INFO: frame_sync_c0 - Forecast 512 gr::debug :INFO: frame_sync_c0 - Forecast 256 gr::debug :INFO: frame_sync_c0 - Forecast 128 gr::debug :INFO: frame_sync_c0 - Forecast 64 gr::debug :INFO: frame_sync_c0 - Forecast 32 gr::debug :INFO: frame_sync_c0 - Forecast 16 gr::debug :INFO: frame_sync_c0 - Forecast 8 gr::debug :INFO: frame_sync_c0 - Forecast 4 gr::debug :INFO: frame_sync_c0 - Forecast 2 gr::debug :INFO: frame_sync_c0 - Forecast 1 Any suggestions for further investigation would be appreciated. Jared. -- Jared Dulmage Engineering Specialist Digital Comm. and Implementation Dept. Aerospace Corporation 310-336-3140 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Connecting a message input port in hier_block2 disconnects a stream output port
Dear all, I've done some debugging in gnuradio-runtime and made the following observations: - When not connecting the message ports in my example, gnuradio-runtime flattens the hier block, so that only the child blocks remain in the flattened flowgraph. This behavior is correct. - Connecting the message port of the hier_block2 results in the flattening process to only partly succeed. The flatten_aux function fails to determine that the message ports of the hier_block2 are hierarchical, and therefore the message ports (and hier block itself) remain in the flattened graph as normal connections instead of being resolved. The output ports of the hier block are furthermore disconnected (I'm not sure why exactly) which causes the flowgraph validation to fail. - Tracing back why flatten_aux determines that the message ports are not hierarchical, I found the following lines in hier_block2_detail.cc: -- bool hier_out = (d_owner == src.get()) && src->message_port_is_hier_out (srcport);; bool hier_in = (d_owner == dst.get()) && dst->message_port_is_hier_in (dstport); -- At first it seemed to me that this was a small error because d_owner is always top_block for the connections of my hier_block2 and therefore the expression will evaluate to false. Changing these lines to the following resolves the problem I described above: --- bool hier_out = (d_owner != src.get()) && src->message_port_is_hier_out (srcport); bool hier_in = (d_owner != dst.get()) && dst->message_port_is_hier_in (dstport); --- Now, the ports are correctly determined to be hierarchical, and flatten_aux flattens the hier block in the example I provided (I can also successfully connect a debug_message() block residing within the hier_block2 to the message_prober). However, one QA test related to the hier block now fails, so this is probably not an ideal approach and I need to do some further digging to resolve this matter. Kind regards, Pieter Robyns 2015-09-27 19:09 GMT+02:00 Pieter ROBYNS : > Dear all, > > While experimenting with hier_block2 I noticed that connecting an input > message port appears to disconnect an unrelated stream output port. I've > attached a simple example Python script to show what I mean. > > Basically, the example script creates a hier_block2 with a null source and > throttle block. The hier_block2 is then connected to a null sink. > Furthermore, it has an input message_port for control messages. The script > runs fine when the input message_port is not connected. However, when > connecting the message_port, the following error is returned: > > RuntimeError: hier_block_test(2): insufficient connected output ports (1 > needed, 0 connected) > > Am I missing something or might this be a bug? If I change the hier_block2 > to have 0 stream outputs (in the output signature), the error goes away, > but in my use case I need to have one stream output and one control message > input. > > > Kind regards, > Pieter Robyns > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Radio Buttons that are Output as well as Inputs
?Hi guys, I am using radio buttons to change source parameters, namely coding rate and constellation order. I also have an adaptive mode. When I enable this, I want the radio buttons to become outputs instead of inputs showing the value chosen by the algorithm. Is there any way to do this? Thanks!! David NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
