[Discuss-gnuradio] Flowgraph branching statements and transceiver

[Washbourne, Logan]

Hello all,

I am trying to figure out a way to allow for user input to dictate what
happens in my flowgraphs. Ideally I want to build a transceiver that will
constantly read in data until the user tries to send out a message. Once
the message has been sent then it goes back to reading data.

I have the TX and RX side of this working already, but its only a one way
system, the TX can only talk to the RX. I'd like to have it so they can
both talk and listen to each other.

I know in the Chat_app example user input is accepted and then sent out,
but it is embedded into an OOT block. Is there anyway to implement user
input and branching statements within the top_block or something like that?

I really appreciate your help,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DPSK DEMOD sync out option

[Washbourne, Logan]

It'll probably be best if you do that.

Thank you for looking into it.

I have another question while I have you. I was hoping that sync output was
going to be some sort of magical correlate/sync option. About a month ago I
was trying to get a messaging system to work over the air using two
USRP1's. I have recently started over in order to figure out why it wasn't
working. This week I was able to achieve a BER of .002% using DQPSK OTA,
however, I am using matlab to correlate and sync the preamble bits. I think
I finally have OTA transmission because I am using the DPSK Demod block,
which to my knowledge, uses FLL timing, polyphase timing and the like. I
was trying to use those blocks individually last month, but I never could
get a solid transmission going.

So my question is, can I correlate post demodulation or is the best way to
do it, pre modulation? Ideally I'd like to continue using the DPSK Demod
block and the bits coming out of it. Most of the correlate options I see in
GRC seem to want to use complex values.

I really appreciate your help,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Thu, Nov 19, 2015 at 11:41 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Logan,
>
> skimming through the xml that defines the DPSK Demod block,
> gr-digital/grc/digital_dxpsk_demod.xml, reveals that this option sets the
> "sync_out" variable, which is used nowhere. This means that it's without
> effect.
> Do you want to delete that option and open a pull request, or should I do
> that?
>
> Best regards,
> Marcus
>
> On 19.11.2015 18:35, Washbourne, Logan wrote:
>
> Hello all,
>
> I was wondering if anyone knew what the sync out option did on the DPSK
> Demod block. I can't seem to find any documentation on it, and I'm also
> having trouble finding the source code for it. Does it just use the generic
> mod_demod file?
>
> Thanks,
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] DPSK DEMOD sync out option

[Washbourne, Logan]

Hello all,

I was wondering if anyone knew what the sync out option did on the DPSK
Demod block. I can't seem to find any documentation on it, and I'm also
having trouble finding the source code for it. Does it just use the generic
mod_demod file?

Thanks,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DBPSK and USRPs

[Washbourne, Logan]

Thanks for the info guys! They are both using antennas btw. I came in this
morning and turned the RX gain up pretty high, roughly 45dB, and the
constellation plot on the RX side is starting to look pretty square, which
I think is a bad sign. My thoughts are that with the increase in gain,
there is too much noise coming through.

I've been toying with adding in a frequency offset on the TX side. I've
been adding and subtracting up to 30kHz from the center frequency and I
haven't seen any improvement in the constellation plot on the RX side.

Another thing that is confusing me, on the TX constellation plot, before it
gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not sure
where the 0 points are coming from. Since this is DBPSK, there should only
be -.5 and .5 groupings right?

Should this exercise be pretty straightforward?

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Oct 26, 2015 at 3:12 PM, <mle...@ripnet.com> wrote:

> Consulting now, the book of armaments, errr, UHD manual:
>
>
>
> http://files.ettus.com/manual/page_dboards.html#dboards_rfx
>
>
>
> The RFX series has no TX RF gain control, output magnitude is entirely
> dependent on baseband magnitude.
>
> There's 70dB of gain range on RX, however.  So, crank up the RX gain.
>
> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is
> probably putting out 5dBm, so at the RX end, that's maybe as much as
> -35dBm. If your RX is set properly, should be enough to see the signal.
>
>
>
>
>
>
> On 2015-10-26 15:46, Marcus Müller wrote:
>
> Hi!
>
> * looking at your constellation, relief comes setting in: It looks pretty
> circular to me; notice how the axes are scaled differently. So no
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the
> constellation sink not being able to achieve timing synchronization, i.e.
> it doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
>   * Rule of thumb: if(not clipping && in doubt) increase gain;
>   * What exactly is your "RF channel": antennas, direct cable with
> attenuator?
>   * The mistake I do every few months: Did you connect the antenna/cable
> to the wrong SMA port?
>
> Best regards,
> Marcus
> On 26.10.2015 20:33, Washbourne, Logan wrote:
>
> I looked at the spectrums of both sides and the RX side looks to be
> inundated with a lot of noise. I'm not sure if its my environment or my
> USRPs, but I really expected to see some resemblance of a signal. I am
> posting links to screencaps of the TX and RX sides.
>
> http://imgur.com/GBTHw8T- TX
> http://imgur.com/DBy8gqs - RX
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Can you compare the TX spectrum with the RX spectrum? Maybe it'd
>> worthwhile to first look at at e.g. 500kHz of RX spectrum to see whether,
>> due to frequency offset, some of the wanted signal simply gets cut off;
>> admittedly, with 2S/sym that's not too likely...
>>
>> Best regards,
>> Marcus
>>
>>
>> On 26.10.2015 19:16, Washbourne, Logan wrote:
>>
>> I am using 250k!
>>
>>
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller <marcus.muel...@ettus.com>
>> wrote:
>>
>>> Hello!
>>> what's the sampling rate you're using?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 26.10.2015 18:38, Washbourne, Logan wrote:
>>>
>>> Hello all,
>>>
>>> I'm trying to take a step back from my previous postings and try a
>>> simple approach to try and understand working with over the air
>>> communications with the USRPs. Let me know if it would be better to post
>>> this in the USRPs-Users list.
>>>
>>> I'm trying to have a simple TX and simple RX side so I can eliminate and
>>> unnecessary complications.
>>>
>>> The TX side has the following flowgraph: Vector
>>> Source(preamble+data)->DPSK Mod(DBPSK,2samples/symbol)-> Multiply
>>> Const(.707) -> UHD:USRP SINK(2.448GHz center freq, 10dB default gain)
>>>
>>> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) ->
>>> DPSK DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
>>>
>>> I'm checking the progress of the communication by looking at a

Re: [Discuss-gnuradio] DBPSK and USRPs

[Washbourne, Logan]

I looked at the spectrums of both sides and the RX side looks to be
inundated with a lot of noise. I'm not sure if its my environment or my
USRPs, but I really expected to see some resemblance of a signal. I am
posting links to screencaps of the TX and RX sides.

http://imgur.com/GBTHw8T- TX
http://imgur.com/DBy8gqs - RX

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Can you compare the TX spectrum with the RX spectrum? Maybe it'd
> worthwhile to first look at at e.g. 500kHz of RX spectrum to see whether,
> due to frequency offset, some of the wanted signal simply gets cut off;
> admittedly, with 2S/sym that's not too likely...
>
> Best regards,
> Marcus
>
>
> On 26.10.2015 19:16, Washbourne, Logan wrote:
>
> I am using 250k!
>
>
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Hello!
>> what's the sampling rate you're using?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 26.10.2015 18:38, Washbourne, Logan wrote:
>>
>> Hello all,
>>
>> I'm trying to take a step back from my previous postings and try a simple
>> approach to try and understand working with over the air communications
>> with the USRPs. Let me know if it would be better to post this in the
>> USRPs-Users list.
>>
>> I'm trying to have a simple TX and simple RX side so I can eliminate and
>> unnecessary complications.
>>
>> The TX side has the following flowgraph: Vector
>> Source(preamble+data)->DPSK Mod(DBPSK,2samples/symbol)-> Multiply
>> Const(.707) -> UHD:USRP SINK(2.448GHz center freq, 10dB default gain)
>>
>> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK
>> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
>>
>> I'm checking the progress of the communication by looking at a
>> constellation plot that is connected directly to the USRP SOURCE block on
>> the receiver side. I'm getting a very elliptical shape, more spread out in
>> the horizontal direction but not by much. I'm also looking at the bits from
>> the receiver side in matlab and my preamble is not showing up.
>>
>> These were the same problems I had when trying to use a correlated system
>> for OTA communications. I feel like I'm missing something really simple.
>>
>> Does anyone know of a simple TX, RX grc setup that I can use to test my
>> USRPs?
>>
>> Again, I really appreciate the help you guys give.
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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 mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DBPSK and USRPs

[Washbourne, Logan]

Tx and Rx are on their own USRP1s, the daughter board is the RFX2400. They
are roughl 3ft apart from each other on a desk. The Rx side is using the
RX2 port.

I will definitely try upping the gain when I get back into the office
tomorrow. I will check the SMA ports, I didn't configure these myself so I
should probably double check them anyways.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Oct 26, 2015 at 2:46 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi!
>
> * looking at your constellation, relief comes setting in: It looks pretty
> circular to me; notice how the axes are scaled differently. So no
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the
> constellation sink not being able to achieve timing synchronization, i.e.
> it doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
>   * Rule of thumb: if(not clipping && in doubt) increase gain;
>   * What exactly is your "RF channel": antennas, direct cable with
> attenuator?
>   * The mistake I do every few months: Did you connect the antenna/cable
> to the wrong SMA port?
>
> Best regards,
> Marcus
> On 26.10.2015 20:33, Washbourne, Logan wrote:
>
> I looked at the spectrums of both sides and the RX side looks to be
> inundated with a lot of noise. I'm not sure if its my environment or my
> USRPs, but I really expected to see some resemblance of a signal. I am
> posting links to screencaps of the TX and RX sides.
>
> http://imgur.com/GBTHw8T- TX
> http://imgur.com/DBy8gqs - RX
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Can you compare the TX spectrum with the RX spectrum? Maybe it'd
>> worthwhile to first look at at e.g. 500kHz of RX spectrum to see whether,
>> due to frequency offset, some of the wanted signal simply gets cut off;
>> admittedly, with 2S/sym that's not too likely...
>>
>> Best regards,
>> Marcus
>>
>>
>> On 26.10.2015 19:16, Washbourne, Logan wrote:
>>
>> I am using 250k!
>>
>>
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller <
>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote:
>>
>>> Hello!
>>> what's the sampling rate you're using?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 26.10.2015 18:38, Washbourne, Logan wrote:
>>>
>>> Hello all,
>>>
>>> I'm trying to take a step back from my previous postings and try a
>>> simple approach to try and understand working with over the air
>>> communications with the USRPs. Let me know if it would be better to post
>>> this in the USRPs-Users list.
>>>
>>> I'm trying to have a simple TX and simple RX side so I can eliminate and
>>> unnecessary complications.
>>>
>>> The TX side has the following flowgraph: Vector
>>> Source(preamble+data)->DPSK Mod(DBPSK,2samples/symbol)-> Multiply
>>> Const(.707) -> UHD:USRP SINK(2.448GHz center freq, 10dB default gain)
>>>
>>> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) ->
>>> DPSK DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
>>>
>>> I'm checking the progress of the communication by looking at a
>>> constellation plot that is connected directly to the USRP SOURCE block on
>>> the receiver side. I'm getting a very elliptical shape, more spread out in
>>> the horizontal direction but not by much. I'm also looking at the bits from
>>> the receiver side in matlab and my preamble is not showing up.
>>>
>>> These were the same problems I had when trying to use a correlated
>>> system for OTA communications. I feel like I'm missing something really
>>> simple.
>>>
>>> Does anyone know of a simple TX, RX grc setup that I can use to test my
>>> USRPs?
>>>
>>> Again, I really appreciate the help you guys give.
>>>
>>> Logan Washbourne
>>> Electrical Engineering Graduate Student
>>> (Electromagnetics)
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu

[Discuss-gnuradio] DBPSK and USRPs

[Washbourne, Logan]

Hello all,

I'm trying to take a step back from my previous postings and try a simple
approach to try and understand working with over the air communications
with the USRPs. Let me know if it would be better to post this in the
USRPs-Users list.

I'm trying to have a simple TX and simple RX side so I can eliminate and
unnecessary complications.

The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK
Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz
center freq, 10dB default gain)

RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK
DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink

I'm checking the progress of the communication by looking at a
constellation plot that is connected directly to the USRP SOURCE block on
the receiver side. I'm getting a very elliptical shape, more spread out in
the horizontal direction but not by much. I'm also looking at the bits from
the receiver side in matlab and my preamble is not showing up.

These were the same problems I had when trying to use a correlated system
for OTA communications. I feel like I'm missing something really simple.

Does anyone know of a simple TX, RX grc setup that I can use to test my
USRPs?

Again, I really appreciate the help you guys give.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DBPSK and USRPs

[Washbourne, Logan]

I am using 250k!



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hello!
> what's the sampling rate you're using?
>
> Best regards,
> Marcus
>
>
> On 26.10.2015 18:38, Washbourne, Logan wrote:
>
> Hello all,
>
> I'm trying to take a step back from my previous postings and try a simple
> approach to try and understand working with over the air communications
> with the USRPs. Let me know if it would be better to post this in the
> USRPs-Users list.
>
> I'm trying to have a simple TX and simple RX side so I can eliminate and
> unnecessary complications.
>
> The TX side has the following flowgraph: Vector
> Source(preamble+data)->DPSK Mod(DBPSK,2samples/symbol)-> Multiply
> Const(.707) -> UHD:USRP SINK(2.448GHz center freq, 10dB default gain)
>
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
>
> I'm checking the progress of the communication by looking at a
> constellation plot that is connected directly to the USRP SOURCE block on
> the receiver side. I'm getting a very elliptical shape, more spread out in
> the horizontal direction but not by much. I'm also looking at the bits from
> the receiver side in matlab and my preamble is not showing up.
>
> These were the same problems I had when trying to use a correlated system
> for OTA communications. I feel like I'm missing something really simple.
>
> Does anyone know of a simple TX, RX grc setup that I can use to test my
> USRPs?
>
> Again, I really appreciate the help you guys give.
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Sean,

Thanks for the tip! Is the k value the reference value in the AGC2 block or
the max gain? Would you mind explaining the equation you used a little
more? From what I understand of it, the seq is the 1's and 0's that make up
the pseudorandom preamble, N is the sequence length and i is the specific
value of the sequence when summing. Is that right or am I way off base?



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Oct 14, 2015 at 9:43 AM, Nowlan, Sean <sean.now...@gtri.gatech.edu>
wrote:

> ​We saw a lot of improvement in the performance of the Correlation
> Estimator block once we calculated a level for the AGC. In our case, we're
> looking for a BPSK preamble that is a pseudorandom sequence. The corr_est
> block is provided with the match-filtered version of the preamble sequence.
> So we calculated the average energy per sample of that sequence as K =
> \frac{ \sum_{i}^{N}(\abs{seq}^2) }{ N }. (Sorry if the LaTeX notation is a
> bit off). So K is the target level we use in the AGC2 block. This seems to
> work pretty well for us.
>
>
> Sean
>
>
> --
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> <discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org> on behalf
> of Washbourne, Logan <lwas...@ostatemail.okstate.edu>
> *Sent:* Tuesday, October 13, 2015 12:03 PM
> *To:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Correlation Estimator Over the Air
>
> Rich,
>
> Ah, that makes so much sense now. I was modulating all that came out of
> the costas loop and packing the bits into bytes which essentially means I
> was undoing the syncing the blocks before it were doing. This morning I
> tried searching for the preamble in the binary stream that was output from
> the constellation decoder and I found it. It was 98 samples in, which
> confused me, but now that I know I am looking for a tag then that makes
> perfect sense.
>
> I just tried that same process, looking for the preamble in the binary
> stream(using matlab) for the over the air program and I still can't find
> it, but I am going to play around with the AGC block and see if I can't
> tweak it enough to work.
>
> I really appreciate your help, I finally feel like I'm getting close to my
> goal.
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
>
> On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Logan,
>>
>> How are you doing this test to see if the bit stream comes out?
>>
>> The corr_est block correlates against a known sequence and when the
>> correlation output is above a threshold, tags the local maximum item around
>> that beak. Now it's up to you to do something with that tag. It places the
>> tag at the very front of the correlation sequence, so one of the first
>> things you need to do is handle the tag placement. You have some control
>> over that with the builtin delay paramter, but sometimes that's not enough.
>>
>> I would recommend taking a step back and proving you know how to do the
>> transformations that don't involve synchronization and channel correction.
>> Take your input data, map it to symbols, modulate it and then immediately
>> reverse the process. No channel, no noise, no synchronization. If you can't
>> make this simulation work, you are misunderstanding something.
>>
>> Rich
>>
>> On Mon, Oct 12, 2015 at 1:28 PM, Washbourne, Logan <
>> lwas...@ostatemail.okstate.edu> wrote:
>>
>>> Rich and others,
>>>
>>> I added the AGC block to RX side and after playing with the parameters
>>> for awhile I got a correlation spike! My next step was to confirm that my
>>> output equalled my input (byte-wise). In order to accomplish this, I added
>>> a Constellation Decoder block after the costas loop and used the
>>> constellation object as the input parameter. Then I repacked the bits into
>>> 8 bit bytes and saved it to a file. I also saved the input byte stream to a
>>> file. I looked at those files in Matlab and so far I have not been able to
>>> find the preamble in the output byte stream.
>>>
>>> After not being able to determine if this communication system was
>>> working( the TX and RX programs utilizing the USRPs), I took a step back
>>> and tried to figure out how to confirm if the test_corr_est.grc had the
>>> same output as its input and I'm running into the same problem, I haven't
>>> been able to find the preamble in the output.
>>>
>>> Both programs show a clear correlation

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Rich,

Ah, that makes so much sense now. I was modulating all that came out of the
costas loop and packing the bits into bytes which essentially means I was
undoing the syncing the blocks before it were doing. This morning I tried
searching for the preamble in the binary stream that was output from the
constellation decoder and I found it. It was 98 samples in, which confused
me, but now that I know I am looking for a tag then that makes perfect
sense.

I just tried that same process, looking for the preamble in the binary
stream(using matlab) for the over the air program and I still can't find
it, but I am going to play around with the AGC block and see if I can't
tweak it enough to work.

I really appreciate your help, I finally feel like I'm getting close to my
goal.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Oct 13, 2015 at 10:55 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Logan,
>
> How are you doing this test to see if the bit stream comes out?
>
> The corr_est block correlates against a known sequence and when the
> correlation output is above a threshold, tags the local maximum item around
> that beak. Now it's up to you to do something with that tag. It places the
> tag at the very front of the correlation sequence, so one of the first
> things you need to do is handle the tag placement. You have some control
> over that with the builtin delay paramter, but sometimes that's not enough.
>
> I would recommend taking a step back and proving you know how to do the
> transformations that don't involve synchronization and channel correction.
> Take your input data, map it to symbols, modulate it and then immediately
> reverse the process. No channel, no noise, no synchronization. If you can't
> make this simulation work, you are misunderstanding something.
>
> Rich
>
> On Mon, Oct 12, 2015 at 1:28 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> Rich and others,
>>
>> I added the AGC block to RX side and after playing with the parameters
>> for awhile I got a correlation spike! My next step was to confirm that my
>> output equalled my input (byte-wise). In order to accomplish this, I added
>> a Constellation Decoder block after the costas loop and used the
>> constellation object as the input parameter. Then I repacked the bits into
>> 8 bit bytes and saved it to a file. I also saved the input byte stream to a
>> file. I looked at those files in Matlab and so far I have not been able to
>> find the preamble in the output byte stream.
>>
>> After not being able to determine if this communication system was
>> working( the TX and RX programs utilizing the USRPs), I took a step back
>> and tried to figure out how to confirm if the test_corr_est.grc had the
>> same output as its input and I'm running into the same problem, I haven't
>> been able to find the preamble in the output.
>>
>> Both programs show a clear correlation spike, I just want to put my mind
>> at ease and verify if it's working through the actual bytes. One last note,
>> the packed output byte stream is roughly 5.5 times smaller than the input
>> byte stream, which I was expecting a really close 1:1 size, this makes me
>> think I am overlooking a consequence of one of the blocks, namely the
>> Correlation Estimator, Polyphase Clock Sync, or the Costas Loop.
>>
>> Does anyone have any suggestions?
>>
>> I know this thread is getting a little long, but I appreciate everyone's
>> patience with my questions.
>>
>>
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> Ah, yes. I suspect you don't have an AGC in your flowgraph? Whenever
>>> you're thresholding against some static number, you need to be sure your
>>> input signal is set to a known amplitude, which is what the AGC does for
>>> you. If you put an AGC in the chain you should see peak values that get
>>> close to your simulation values. The AGC produces a stable platform for the
>>> rest of your blocks to sit on.
>>>
>>> The AGC parameters can really play havoc with your system. The AGC can
>>> be the cause of a lot of headache. If you find yourself debugging something
>>> that makes no sense, often it's the AGC's fault, in my experience. I
>>> recommend you create a simulation that stresses the AGC and prove it will
>>> work as best you can before going to over the air.
>>>
>>> Rich
>>>
>>>
>>>
>>>

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Rich and others,

I added the AGC block to RX side and after playing with the parameters for
awhile I got a correlation spike! My next step was to confirm that my
output equalled my input (byte-wise). In order to accomplish this, I added
a Constellation Decoder block after the costas loop and used the
constellation object as the input parameter. Then I repacked the bits into
8 bit bytes and saved it to a file. I also saved the input byte stream to a
file. I looked at those files in Matlab and so far I have not been able to
find the preamble in the output byte stream.

After not being able to determine if this communication system was working(
the TX and RX programs utilizing the USRPs), I took a step back and tried
to figure out how to confirm if the test_corr_est.grc had the same output
as its input and I'm running into the same problem, I haven't been able to
find the preamble in the output.

Both programs show a clear correlation spike, I just want to put my mind at
ease and verify if it's working through the actual bytes. One last note,
the packed output byte stream is roughly 5.5 times smaller than the input
byte stream, which I was expecting a really close 1:1 size, this makes me
think I am overlooking a consequence of one of the blocks, namely the
Correlation Estimator, Polyphase Clock Sync, or the Costas Loop.

Does anyone have any suggestions?

I know this thread is getting a little long, but I appreciate everyone's
patience with my questions.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Ah, yes. I suspect you don't have an AGC in your flowgraph? Whenever
> you're thresholding against some static number, you need to be sure your
> input signal is set to a known amplitude, which is what the AGC does for
> you. If you put an AGC in the chain you should see peak values that get
> close to your simulation values. The AGC produces a stable platform for the
> rest of your blocks to sit on.
>
> The AGC parameters can really play havoc with your system. The AGC can be
> the cause of a lot of headache. If you find yourself debugging something
> that makes no sense, often it's the AGC's fault, in my experience. I
> recommend you create a simulation that stresses the AGC and prove it will
> work as best you can before going to over the air.
>
> Rich
>
>
>
> On Wed, Oct 7, 2015 at 9:09 AM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> Last time I replied to the mailing list, did it go directly to your
>> email? If so, I will double check next time to make sure it goes to the
>> list.
>>
>> Your explanation makes sense, with the limited knowledge of filtering
>> that I have.
>>
>> I changed the filter length on my RX side for the rrc_taps and nothing
>> seemed to change. But I think what the overarching problem is, is my metric
>> for success. The way I am determining if the communication has been
>> successful is the amplitude of the correlation value coming out of the
>> Correlation Estimator block. Through all of my testing over the air, the
>> correlation value hasn't seemed to have changed. I can register an
>> extremely small value, of .5-1.5 if I set the QT GUI TIME SINK to
>> autoscale, but the non-over the air version outputs a value of roughly 75,
>> which has been causing me to call the communication a failure.
>>
>> Do you have any advice?
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Wed, Oct 7, 2015 at 10:47 AM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> Previous email sent without me telling it to. Picking up from "Fuction
>>> coped below:"
>>>
>>> firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), eb,
>>> 5*sps*nfilts)
>>>
>>> The first nfilts is just gain of your filter. The next two paraters
>>> should work out to be the number of samples per symbol of the upsampled
>>> RRC. 1/float(sps) gives you 1/4 if sps = 4. Then to get samp/symb you have
>>> nfilts/(1/4) = 4*nfilts samp_symb, which is in fact the upsampled version
>>> you want. The point I'm trying to make, is you could have filled out the
>>> function this way and got the same result:
>>>
>>> firdes.root_raised_cosine(nfilts, nfilts*sps, 1, eb, 5*sps*nfilts)
>>>
>>> which feels more natural to me.
>>>
>>> The last paramter is the length of the filter in samples. The default
>>> does not match the built in length of the Constellation Modulator filter,
>>> which is hardcoded to 11 if I remember right. S

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Rich,

If you could send me that paper, I would really appreciate it. So I'm
looking at the test_corr_est.grc file and the only place I see the rrc_taps
being used is within the polyphase clock sync, which is on the RX side.
Should there be a rrc filter on the TX side as well?

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Sat, Oct 3, 2015 at 5:28 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> The taps you use should be the upsampled by nfilt version of your shaping
> filter at the tx, scaled appropriately to produce the desired output
> amplitude. If you're new to this, then you might need to find a good
> resource for polyphase filters and how they are used for timing recovery. I
> can reference a paper for you later on if needed. But, from grc if you used
> an rrc filter on the tx, it's a matter of making a call to the rrc filter
> in the taps parameter of the block. I think there is an example of this in
> the gr-digital/examples folder. I'm not in front of a computer so I can't
> check for you now.
>
> Rich
>
> Sent from my iPad
>
> On Oct 2, 2015, at 3:06 PM, lwas...@ostatemail.okstate.edu wrote:
>
> Sent from my Cyanogen phone
> On Oct 2, 2015 3:12 AM, Richard Bell <richard.be...@gmail.com> wrote:
> >
> > I can't open and look at your flow now, but it seems you have the
> necessary blocks in there. Here are some things that come to mind:
> >
> > 1) put a multiply const block in front of the usrp source at the tx. You
> don't want to feed values ranging from 1 to -1 but rather ~0.7 to -0.7.
> >
>
> I will try that today.
> > 2) keep usrp tx/rx analog gains below 20dB to avoid odd behavior. Keep
> the usrps close to each other for this debug. I use 15dB for initial
> testing.
> >
>
> I've kept it around 10dB normally, but I will double check.
> > 3) Costas loop will only fix small frequency offsets. Try adding an FLL
> block before timing sync.
> >
>
> Will do. I don't think it's even getting to the costas loop to be honest,
> it seems to not be tripping the correlation estimator block.
> > 4) are you sure you used the right taps for the pfb clock sync block?
> How did you confirm this?
> >
> I'm not sure if I used the right taps. I'm just using the ones that were
> included in the test_corr_est  GRC file. Do you have a method of
> confirmation that you would recommend?
> > 5) BPSK requires an equalizer if you have a bad channel. Are you using
> antennas or a coax cable?
> >
>
> I am using antennas. I'll look into the equalizer.
>
> Thank you for taking the time to help so far.
>
> > Rich
> >
> > Sent from my iPhone
> >
> > On Oct 1, 2015, at 6:20 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
> >
> >> Rich,
> >>
> >> The test_corr_est block has the flow graph as follows: vector source->
> constellation modulator -> stream mux(with null source) -> throttle ->
> channel model -> correlation estimator -> polyphase clock sync -> costas
> loop -> constellation and time gui sinks.
> >>
> >> For my modified TX grc file I used the following flowgraph: vector
> source -> constellation modulator -> stream mux(with null source) ->
> constellation and time gui sinks as well as the UHD: USRP sink
> >>
> >> For the RX grc: UHD: USRP Source -> correlation estimator -> polyphase
> clock sync -> costas loop-> constellation and time gui sinks.
> >>
> >> The grc files can be found at:
> https://github.com/loganwashbourne/Logan.git
> >>
> >> The files are called test_corr_est_TX and test_corr_est_RX.
> >>
> >> Thanks for your time,
> >>
> >>
> >> Logan Washbourne
> >> Electrical Engineering Graduate Student
> >> (Electromagnetics)
> >>
> >>
> >> On Thu, Oct 1, 2015 at 3:44 AM, Richard Bell <richard.be...@gmail.com>
> wrote:
> >>>
> >>> Hi Logan,
> >>>
> >>> Can you give more detail on your synchronization choices for BPSK so
> we can tell you what more you may need to do?
> >>>
> >>> Rich
> >>>
> >>> Sent from my iPhone
> >>>
> >>> > On Sep 30, 2015, at 7:14 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > This is somewhat of an update to a previous post I made from last
> week. After talking to Julian and Martin, it was made clear to me that I
> needed to use a correlation system to insure my rec

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Last time I replied to the mailing list, did it go directly to your email?
If so, I will double check next time to make sure it goes to the list.

Your explanation makes sense, with the limited knowledge of filtering that
I have.

I changed the filter length on my RX side for the rrc_taps and nothing
seemed to change. But I think what the overarching problem is, is my metric
for success. The way I am determining if the communication has been
successful is the amplitude of the correlation value coming out of the
Correlation Estimator block. Through all of my testing over the air, the
correlation value hasn't seemed to have changed. I can register an
extremely small value, of .5-1.5 if I set the QT GUI TIME SINK to
autoscale, but the non-over the air version outputs a value of roughly 75,
which has been causing me to call the communication a failure.

Do you have any advice?

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Oct 7, 2015 at 10:47 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Previous email sent without me telling it to. Picking up from "Fuction
> coped below:"
>
> firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), eb, 5*sps*nfilts)
>
> The first nfilts is just gain of your filter. The next two paraters should
> work out to be the number of samples per symbol of the upsampled RRC.
> 1/float(sps) gives you 1/4 if sps = 4. Then to get samp/symb you have
> nfilts/(1/4) = 4*nfilts samp_symb, which is in fact the upsampled version
> you want. The point I'm trying to make, is you could have filled out the
> function this way and got the same result:
>
> firdes.root_raised_cosine(nfilts, nfilts*sps, 1, eb, 5*sps*nfilts)
>
> which feels more natural to me.
>
> The last paramter is the length of the filter in samples. The default does
> not match the built in length of the Constellation Modulator filter, which
> is hardcoded to 11 if I remember right. So I use, 11*sps*nfilts+1 for this
> parameter. The plus 1 is actually handled for you in the constructor of the
> RRC (I think it's the constructor, but if not somewhere). If you feed an
> even number in, it will get 1 added to it. I like to be explicit with the
> +1, but you don't need it.
>
> Rich
>
> On Wed, Oct 7, 2015 at 8:41 AM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Logan,
>>
>> I recommend you keep this conversation on the mailing list. You are more
>> likely to get answers that way.
>>
>> The Constellation Modulator has an RRC filter built into it. That is what
>> the Samples/Symbol and Excess BW paramters of that block are for. Your job
>> now is to make the upsampled by nfilt version of that blocks RRC filter and
>> feed it into the pfb clock sync block. That's what the example shows you
>> how to do.
>>
>> The way the default values of the pfb clock sync block are entered can be
>> a little confusing. Function copied below:
>>
>>
>> On Wed, Oct 7, 2015 at 8:34 AM, Washbourne, Logan <
>> lwas...@ostatemail.okstate.edu> wrote:
>>
>>> Rich,
>>>
>>> If you could send me that paper, I would really appreciate it. So I'm
>>> looking at the test_corr_est.grc file and the only place I see the rrc_taps
>>> being used is within the polyphase clock sync, which is on the RX side.
>>> Should there be a rrc filter on the TX side as well?
>>>
>>> Logan Washbourne
>>> Electrical Engineering Graduate Student
>>> (Electromagnetics)
>>>
>>>
>>> On Sat, Oct 3, 2015 at 5:28 AM, Richard Bell <richard.be...@gmail.com>
>>> wrote:
>>>
>>>> The taps you use should be the upsampled by nfilt version of your
>>>> shaping filter at the tx, scaled appropriately to produce the desired
>>>> output amplitude. If you're new to this, then you might need to find a good
>>>> resource for polyphase filters and how they are used for timing recovery. I
>>>> can reference a paper for you later on if needed. But, from grc if you used
>>>> an rrc filter on the tx, it's a matter of making a call to the rrc filter
>>>> in the taps parameter of the block. I think there is an example of this in
>>>> the gr-digital/examples folder. I'm not in front of a computer so I can't
>>>> check for you now.
>>>>
>>>> Rich
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Oct 2, 2015, at 3:06 PM, lwas...@ostatemail.okstate.edu wrote:
>>>>
>>>> Sent from my Cyanogen phone
>>>> On Oct 2, 2015 3:12 AM, Richard Bell <richard.be...@gmail.com> wrote:
>>>> >
>>

[Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Hello,

This is somewhat of an update to a previous post I made from last week.
After talking to Julian and Martin, it was made clear to me that I needed
to use a correlation system to insure my receiver would be synced up to my
transmitter when trying to communicate over the air.

I am trying to utilize the Correlation Estimator block to help me achieve
those means. In order to ease myself into it, I am trying to turn the
test_corr_est.grc example into an over the air program. I am getting
communication between the transmitter and receiver(essentially I just split
the grc program in two and took out the throttle block and the channel
model and replaced them with UHD blocks). Now, I don't get any O's or L's
or an abundance of U's, and I can clearly see data coming in on the RX
side, but it seems to be a lot of noise, but noise generated by the TX
side, because it goes away when I stop transmitting. The center frequency
is 2.48GHz and the sample rate is 250k samples/sec.

My testing method is plotting the constellation symbols right before they
get sent out on the TX side and then plotting them right after the UHD
block on the RX side. It is only bpsk and the symbols are covering all four
quadrants.

I haven't changed any settings on the polyphase clock sync or the
modulation scheme.

This is a little rambly but I appreciate your time,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Rich,

The test_corr_est block has the flow graph as follows: vector source->
constellation modulator -> stream mux(with null source) -> throttle ->
channel model -> correlation estimator -> polyphase clock sync -> costas
loop -> constellation and time gui sinks.

For my modified TX grc file I used the following flowgraph: vector source
-> constellation modulator -> stream mux(with null source) -> constellation
and time gui sinks as well as the UHD: USRP sink

For the RX grc: UHD: USRP Source -> correlation estimator -> polyphase
clock sync -> costas loop-> constellation and time gui sinks.

The grc files can be found at: https://github.com/loganwashbourne/Logan.git

The files are called test_corr_est_TX and test_corr_est_RX.

Thanks for your time,


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Thu, Oct 1, 2015 at 3:44 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Hi Logan,
>
> Can you give more detail on your synchronization choices for BPSK so we
> can tell you what more you may need to do?
>
> Rich
>
> Sent from my iPhone
>
> > On Sep 30, 2015, at 7:14 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
> >
> > Hello,
> >
> > This is somewhat of an update to a previous post I made from last week.
> After talking to Julian and Martin, it was made clear to me that I needed
> to use a correlation system to insure my receiver would be synced up to my
> transmitter when trying to communicate over the air.
> >
> > I am trying to utilize the Correlation Estimator block to help me
> achieve those means. In order to ease myself into it, I am trying to turn
> the test_corr_est.grc example into an over the air program. I am getting
> communication between the transmitter and receiver(essentially I just split
> the grc program in two and took out the throttle block and the channel
> model and replaced them with UHD blocks). Now, I don't get any O's or L's
> or an abundance of U's, and I can clearly see data coming in on the RX
> side, but it seems to be a lot of noise, but noise generated by the TX
> side, because it goes away when I stop transmitting. The center frequency
> is 2.48GHz and the sample rate is 250k samples/sec.
> >
> > My testing method is plotting the constellation symbols right before
> they get sent out on the TX side and then plotting them right after the UHD
> block on the RX side. It is only bpsk and the symbols are covering all four
> quadrants.
> >
> > I haven't changed any settings on the polyphase clock sync or the
> modulation scheme.
> >
> > This is a little rambly but I appreciate your time,
> >
> > Logan Washbourne
> > Electrical Engineering Graduate Student
> > (Electromagnetics)
> >
> > ___
> > 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

Re: [Discuss-gnuradio] Questions about burst communication

[Washbourne, Logan]

My guess is no, the receiver doesn't have its own thread, because I'm not
sure how to tell.


On Fri, Sep 25, 2015 at 11:21 AM, Martin Braun 
wrote:

> On 24.09.2015 16:31, lwas...@ostatemail.okstate.edu wrote:
> > Julian and Martin,
> >
> > Typically 2 U's appear then a stream of O's. Ya, I don't have any sort
> > of correlation block on the receiver side so that is definitely a
> > problem. Next week I'll work on implementing a correlation block with a
> > barker code preamble.
> >
> > Do you have any suggestions for quick testing and validation? What I've
> > been doing to check the bytes, if my acknowledgment fails, is to save
> > the bytes to a file and use MATLAB to inspect them. Is there an easier
> > way to quickly look at individual bytes?
>
> If you have lots of O's, looking at bytes won't help -- the O's are
> because your receive part is somehow too slow or stalling. You'll need
> to fix that first.
>
> Does your receiver have it's own dedicated thread?
>
> M
>
>
> ___
> 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] Questions about burst communication

[Washbourne, Logan]

Hello all,

I've been trying to modify the chat app tutorial into a system that can
utilize USRPs and an acknowledgement system. The acknowledgement system
works so far, the RX just sends a pdu back to the TX side saying that it
received the message. I am now trying to implement the USRPs to have an
over the air system, instead of just using one computer and simulating the
channel.

My grc files are on github, https://github.com/loganwashbourne/Logan.git.
The modified Chat Receiver and Chat Sanitizer blocks are on the github as
well.

My question is, do I need to treat a burst communication system different
than a continuous system? My problem is that on each side I am getting O's
whenever I start the program, I have tried increasing and decreasing the
sampling rate, and I didn't see any change to the output.

I am using the USRP1's, with the RFX2400 daughter boards.

If anyone has any ideas or avenues for me to look into it would be much
appreciated.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process

[Logan]

Hi Martin,

Thank you. Now I see how the interaction between the host PC and USRP works.
Actually, i am mostly interested in the transmission/sensing to/from the
radio space (i.e. a radio application on PC sends command to the hardware
for transmission/sensing). To my understanding, the application has put the
radio parameters into the property tree and messages into the queue. But how
does the hardware (motherboard) know when to perform the
transmission/sensing? I know the command is also delivered through the
Ethernet as you've introduced. I am wondering where does the USRP somehow
"decode" the command, and realize the intention of the application?

Best Regards,
Logan



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/USRP-tracking-the-transmission-receiving-process-tp55900p55975.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process

[Logan Wu]

Hi Jeff,

Thank you for the suggestions. I'll look into the codes under "cores" 
directory.

Logan

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP Structure

[Logan Wu]

Hello,

Recently I read a paper on cognitive radio security (Secure
reconfiguration of software-defined radio). It highlights that the
operating system of cognitive radio node may be compromised as the
malware can exploit software vulnerabilities. I am wondering if the FPGA
and firmware are part of the OS? And can they be compromised during
runtime by malware?

Thank you,
Logan

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [USRP] tracking the transmission/receiving process

[Logan Wu]

Hello,

I've been tracking the source code to figure out the procedure of
transmission/receiving. All I've found out is that the parameters (e.g.
freq, gain, etc.) are stored in a property tree, and messages are
inserted to the tail of queue. But how does the transmitter/receiver
(daughter board) know when to transmit/receive? Specifically, which file
in UHD host code does the job of notifying the hardware to
transmit/receive?

Thank you,
Logan

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] General_Work Not Executing

[Washbourne, Logan]

Tom,

Thanks for pointing me in a new direction. I've spent this morning reading
about the scheduler and I came across your Scheduler Details slide show
from 2013. I saw the message passing protocol on slide 15, which makes
sense, but I am not reaching the first bullet point, my messages are not
being published. So then I continued reading and came across slide 29 and I
see that if a block is not a streaming block then BLKD_IN gets set, which I
then found the gr_block_executor.h file and saw the comment next to the
BLKD_IN state, which reads that the block is now blocked and waiting for
input data. I must be not fully understanding that flowchart because I
can't see how those steps apply to a source block that doesn't rely on
input data.

The next step in my mind is either to figure out how to get the scheduler
to recognize a block that only outputs messages or to figure out how to
call the function within my block that publishes the message without
relying on the scheduler.

Do you have any other sources that detail the scheduler? Or any advice in
helping to understand the presentation about the scheduler?

I appreciate your time,



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 31, 2015 at 12:28 PM, Tom Rondeau <t...@trondeau.com> wrote:

> On Mon, Aug 31, 2015 at 11:28 AM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> Tom,
>>
>> Thanks for the reply!
>>
>> So unfortunately I started using git after I found out that the code
>> wasn't entering general_work. It was actually the reason I started using
>> git, so this wouldn't happen again haha. Thanks for the temp files tip,
>> I'll try to fix that today.
>>
>> For the blocks, I think I just want them to pass messages. I'm trying to
>> model it directly after the ChatApp tutorial, and I'm pretty sure that's
>> what the send and receive blocks in that project were doing.
>>
>> Is this not a good practice or infeasible?
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>
>
> Hi Logan,
>
> Have another look at the Python code you were copying from. The
> chat_sanitizer just creates a message output port and we call it's
> post_message from the main app when a user is ready to post. There's
> nothing automatic about it, so no work function to be called. The
> chat_receiver code just waits until a message is posted to it, at which
> point it wakes up and fires off its handle_msg function to process the
> message.
>
> What you're trying to do is feasible, but I think you'll need to
> understand the message passing system in the scheduler instead of the data
> streaming model to get a better handle on it.
>
> Tom
>
>
>
>
>> On Mon, Aug 31, 2015 at 8:44 AM, Tom Rondeau <t...@trondeau.com> wrote:
>>
>>> On Fri, Aug 28, 2015 at 12:49 PM, Washbourne, Logan <
>>> lwas...@ostatemail.okstate.edu> wrote:
>>>
>>>> Hello All,
>>>>
>>>> I recently rewrote the Chat Sanitize and Chat Receiver blocks from the
>>>> Tutorial module(Example 5) in C++. I did this because I wanted to add an
>>>> acknowledgment feature into the blocks in order to add some robustness to
>>>> it(I'm not sure yet if the chat example will lend itself to being robust
>>>> but it was the starting point I chose). The problem arose when I added an
>>>> input port to the Text Sanitize block and added an output to the Chat
>>>> Receiver block and connected them together. Instead of a linear program I
>>>> now had a loop of a program. I did something wrong because now the Text
>>>> Sanitize block wasn't outputting anything, so I commented out the input
>>>> code for Text Sanitize and the output code for Chat Receiver. I went to
>>>> retest the program to see if it behaved just like Example 5(which it was
>>>> before I started adding on the acknowledgment bits) but now Text Sanitize
>>>> wasn't outputting anything still.
>>>>
>>>> I tried putting some cout's in the general _work function where the
>>>> message publishing code is and I have determined that it's not even
>>>> entering the general_work function.
>>>>
>>>> Does anyone have any thoughts on the matter? I must have changed
>>>> something when I commented out the input portion of the Text_Sanitize code
>>>> but for the life of me I can't figure out what it is. I have even since
>>>> made two new blocks to try and redo the functionality of Text Sanitize but
>>>> the same problem still persists.

Re: [Discuss-gnuradio] General_Work Not Executing

[Washbourne, Logan]

Tom,

Thanks for the reply!

So unfortunately I started using git after I found out that the code wasn't
entering general_work. It was actually the reason I started using git, so
this wouldn't happen again haha. Thanks for the temp files tip, I'll try to
fix that today.

For the blocks, I think I just want them to pass messages. I'm trying to
model it directly after the ChatApp tutorial, and I'm pretty sure that's
what the send and receive blocks in that project were doing.

Is this not a good practice or infeasible?

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 31, 2015 at 8:44 AM, Tom Rondeau <t...@trondeau.com> wrote:

> On Fri, Aug 28, 2015 at 12:49 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> Hello All,
>>
>> I recently rewrote the Chat Sanitize and Chat Receiver blocks from the
>> Tutorial module(Example 5) in C++. I did this because I wanted to add an
>> acknowledgment feature into the blocks in order to add some robustness to
>> it(I'm not sure yet if the chat example will lend itself to being robust
>> but it was the starting point I chose). The problem arose when I added an
>> input port to the Text Sanitize block and added an output to the Chat
>> Receiver block and connected them together. Instead of a linear program I
>> now had a loop of a program. I did something wrong because now the Text
>> Sanitize block wasn't outputting anything, so I commented out the input
>> code for Text Sanitize and the output code for Chat Receiver. I went to
>> retest the program to see if it behaved just like Example 5(which it was
>> before I started adding on the acknowledgment bits) but now Text Sanitize
>> wasn't outputting anything still.
>>
>> I tried putting some cout's in the general _work function where the
>> message publishing code is and I have determined that it's not even
>> entering the general_work function.
>>
>> Does anyone have any thoughts on the matter? I must have changed
>> something when I commented out the input portion of the Text_Sanitize code
>> but for the life of me I can't figure out what it is. I have even since
>> made two new blocks to try and redo the functionality of Text Sanitize but
>> the same problem still persists.
>>
>
>
> So this will be a good lesson in using git! It's good to keep small,
> quantified changes in git so that you know where you are versus where you
> started when making a change. "git diff" is your friend here. Lots of ways
> to use this tool to help in your development cycle.
>
> (Also, looking at your git repo, you've checked in the '~' temp files from
> your editor [emacs I assume]. You don't want any temp or auto-generated
> files in a git repository; just stuff that you've created that needs to be
> tracked.)
>
> The problem is that this block is designed only to output messages, not a
> data stream. You can see in the constructor that the io_signature is using
> (0, 0, 0) for both inputs and outputs. The scheduler doesn't recognize this
> block in the stream and so never things to call the general_work. The
> original blocks you are referring to only have message interfaces.
>
> Hope this helps get you in the right direction.
>
>
> Tom
>
>
>
>
>> My code can be found at: https://github.com/loganwashbourne/Thesis.git
>>
>> The juicy files are in the Thesis/OOT/gr-ACK/lib folder.
>>
>> There might be some profanity in the commit messages, it was a stressful
>> day.
>>
>> I appreciate your time,
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> ___
>> 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] General_Work Not Executing

[Washbourne, Logan]

Hello All,

I recently rewrote the Chat Sanitize and Chat Receiver blocks from the
Tutorial module(Example 5) in C++. I did this because I wanted to add an
acknowledgment feature into the blocks in order to add some robustness to
it(I'm not sure yet if the chat example will lend itself to being robust
but it was the starting point I chose). The problem arose when I added an
input port to the Text Sanitize block and added an output to the Chat
Receiver block and connected them together. Instead of a linear program I
now had a loop of a program. I did something wrong because now the Text
Sanitize block wasn't outputting anything, so I commented out the input
code for Text Sanitize and the output code for Chat Receiver. I went to
retest the program to see if it behaved just like Example 5(which it was
before I started adding on the acknowledgment bits) but now Text Sanitize
wasn't outputting anything still.

I tried putting some cout's in the general _work function where the message
publishing code is and I have determined that it's not even entering the
general_work function.

Does anyone have any thoughts on the matter? I must have changed something
when I commented out the input portion of the Text_Sanitize code but for
the life of me I can't figure out what it is. I have even since made two
new blocks to try and redo the functionality of Text Sanitize but the same
problem still persists.

My code can be found at: https://github.com/loganwashbourne/Thesis.git

The juicy files are in the Thesis/OOT/gr-ACK/lib folder.

There might be some profanity in the commit messages, it was a stressful
day.

I appreciate your time,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Washbourne, Logan]

Patrick and All,

I figured out my original error. In my XML file I was trying to use a
variable without including it in the line:

makeACK.Text_Sanitize($msg)/make

the $msg is what I added and that error no longer occurs.

This error: RuntimeError: attempt to set_msg_handler() on bad input message
port!

still occurs, but that's just going to take some time for me to learn about
PMTs and PDUs.

Thanks for everyone's help!


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Sat, Aug 22, 2015 at 1:57 PM, Washbourne, Logan 
lwas...@ostatemail.okstate.edu wrote:

 Patrick,

 Thanks for the advice! So I added that string parameter(or char array) to
 the Top_Block.py file

 the new line looks like this:self.ACK_Text_Sanitize_0 =
 ACK.Text_Sanitize(String).

 When I run python top_block.py this error occurs:

 comm1@comm1:~/Logan/Thesis$ python top_block.py
 Traceback (most recent call last):
   File top_block.py, line 92, in module
 tb = top_block()
   File top_block.py, line 65, in __init__
 self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(String)
   File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399,
 in make
 return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
 RuntimeError: attempt to set_msg_handler() on bad input message port!


 My XML file can be found here:
 https://gist.github.com/loganwashbourne/68367a93b7fe9bf28bce

 So the RuntimeError seems to be the problem, I'm leaning towards the idea
 that I am not handling the PMT's correctly. Thoughts?

 Richard,

 I appreciate the advice, I've been pretty diligent about using sudo
 ldconfig after I read that not using it could create problems. All advice
 helps!



 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Fri, Aug 21, 2015 at 4:37 PM, Patrick Sathyanathan wp...@hotmail.com
 wrote:

 I see the following in the output of nm -C -u:

  U gr::ACK::Text_Sanitize_impl::forecast(int, std::vectorint,
 std::allocatorint )

 This was the undefined symbol that was causing the module import to
 fail... as you have discovered yourself. Now that the module import has
 succeeded you are seeing a different error.

 This error is because of the following in the generated python file:

self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()

 Note that this will invoke Text_Sanitize::make which expects a char *
 message argument. That causes the error message below. For some reason GRC
 is not adding that parameter in the above statement. Did you add a
 declaration for that parameter in the XML file ?

 To verify that the XML file is the issue just try editing the generated
 python file and changing the above to:

self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(some string)

 and running it from the command line (run python top_block.py in a
 terminal window).

 --Patrick

 --
 Date: Thu, 20 Aug 2015 11:08:56 -0500
 From: lwas...@ostatemail.okstate.edu
 To: discuss-gnuradio@gnu.org

 Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object
 has no attribute 'blockname'

 Nathan and Patrick,

 Thanks for the tips!

 I started with running: nm -C -u libgnuradio-modulename.so

 and the results of that can be found here:
 https://gist.github.com/loganwashbourne under the *nm -C -u
 libgnuradio-modulename.so*
 https://gist.github.com/loganwashbourne/3bb90d787308b45211d0 file. (I
 think github thinks I'm a robot so I can't link to the direct page yet).

 I'll be honest, I'm not really sure what I'm looking at in this return, I
 do see some error statements but I'm not sure if they are just stating how
 it would handle an error or if it is an actual error.

 I really don't think I have any callbacks in my XML code, I just
 reference certain input variables in the XML code.

 Next, the ACK_swig.i file can be found here :
 https://gist.github.com/loganwashbourne under the same file name. I
 checked it against the gr-tutorial swig file and the only difference was
 that the ACK_swig.i file included a magic2 function call for each of my OOT
 blocks(check and Text_Sanitize), while the gr-tutorial didn't.

 Last thing, I realized that I am creating the forecast function in the
 Text_Sanitize_impl.h file but not referencing it it the .cc file (I
 commented it out). I tried commenting out the void deceleration of the
 forecast function in the .h file but then I get a new error when I try to
 run the grc file(which is just a constant int source connected to my
 Text_Sanitize block, which is connected the the message debug print port).

 The new error is :

 Traceback (most recent call last):
   File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
 tb = top_block()
   File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
 self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
   File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line
 399, in make
 return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
 TypeError

Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Washbourne, Logan]

Patrick,

Thanks for the advice! So I added that string parameter(or char array) to
the Top_Block.py file

the new line looks like this:self.ACK_Text_Sanitize_0 =
ACK.Text_Sanitize(String).

When I run python top_block.py this error occurs:

comm1@comm1:~/Logan/Thesis$ python top_block.py
Traceback (most recent call last):
  File top_block.py, line 92, in module
tb = top_block()
  File top_block.py, line 65, in __init__
self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(String)
  File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399,
in make
return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
RuntimeError: attempt to set_msg_handler() on bad input message port!


My XML file can be found here:
https://gist.github.com/loganwashbourne/68367a93b7fe9bf28bce

So the RuntimeError seems to be the problem, I'm leaning towards the idea
that I am not handling the PMT's correctly. Thoughts?

Richard,

I appreciate the advice, I've been pretty diligent about using sudo
ldconfig after I read that not using it could create problems. All advice
helps!



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Fri, Aug 21, 2015 at 4:37 PM, Patrick Sathyanathan wp...@hotmail.com
wrote:

 I see the following in the output of nm -C -u:

  U gr::ACK::Text_Sanitize_impl::forecast(int, std::vectorint,
 std::allocatorint )

 This was the undefined symbol that was causing the module import to
 fail... as you have discovered yourself. Now that the module import has
 succeeded you are seeing a different error.

 This error is because of the following in the generated python file:

self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()

 Note that this will invoke Text_Sanitize::make which expects a char *
 message argument. That causes the error message below. For some reason GRC
 is not adding that parameter in the above statement. Did you add a
 declaration for that parameter in the XML file ?

 To verify that the XML file is the issue just try editing the generated
 python file and changing the above to:

self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(some string)

 and running it from the command line (run python top_block.py in a
 terminal window).

 --Patrick

 --
 Date: Thu, 20 Aug 2015 11:08:56 -0500
 From: lwas...@ostatemail.okstate.edu
 To: discuss-gnuradio@gnu.org

 Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object
 has no attribute 'blockname'

 Nathan and Patrick,

 Thanks for the tips!

 I started with running: nm -C -u libgnuradio-modulename.so

 and the results of that can be found here:
 https://gist.github.com/loganwashbourne under the *nm -C -u
 libgnuradio-modulename.so*
 https://gist.github.com/loganwashbourne/3bb90d787308b45211d0 file. (I
 think github thinks I'm a robot so I can't link to the direct page yet).

 I'll be honest, I'm not really sure what I'm looking at in this return, I
 do see some error statements but I'm not sure if they are just stating how
 it would handle an error or if it is an actual error.

 I really don't think I have any callbacks in my XML code, I just reference
 certain input variables in the XML code.

 Next, the ACK_swig.i file can be found here :
 https://gist.github.com/loganwashbourne under the same file name. I
 checked it against the gr-tutorial swig file and the only difference was
 that the ACK_swig.i file included a magic2 function call for each of my OOT
 blocks(check and Text_Sanitize), while the gr-tutorial didn't.

 Last thing, I realized that I am creating the forecast function in the
 Text_Sanitize_impl.h file but not referencing it it the .cc file (I
 commented it out). I tried commenting out the void deceleration of the
 forecast function in the .h file but then I get a new error when I try to
 run the grc file(which is just a constant int source connected to my
 Text_Sanitize block, which is connected the the message debug print port).

 The new error is :

 Traceback (most recent call last):
   File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
 tb = top_block()
   File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
 self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
   File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399,
 in make
 return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
 TypeError: Required argument 'message' (pos 1) not found

 I do apologize for the long questions, if any of you feel like I need to
 spend more time looking into this myself before asking the mailing list,
 please don't hesitate to mention it.



 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Wed, Aug 19, 2015 at 5:06 PM, Patrick Sathyanathan wp...@hotmail.com
 wrote:

 Hi Logan,

 I have faced the same error twice recently in my OOT module and finally
 tracked it down to two causes. The basic reason for the 'object has no
 attribute' error is that Python's import of your module failed. In the two

Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Washbourne, Logan]

Nathan and Patrick,

Thanks for the tips!

I started with running: nm -C -u libgnuradio-modulename.so

and the results of that can be found here:
https://gist.github.com/loganwashbourne under the *nm -C -u
libgnuradio-modulename.so*
https://gist.github.com/loganwashbourne/3bb90d787308b45211d0 file. (I
think github thinks I'm a robot so I can't link to the direct page yet).

I'll be honest, I'm not really sure what I'm looking at in this return, I
do see some error statements but I'm not sure if they are just stating how
it would handle an error or if it is an actual error.

I really don't think I have any callbacks in my XML code, I just reference
certain input variables in the XML code.

Next, the ACK_swig.i file can be found here :
https://gist.github.com/loganwashbourne under the same file name. I checked
it against the gr-tutorial swig file and the only difference was that the
ACK_swig.i file included a magic2 function call for each of my OOT
blocks(check and Text_Sanitize), while the gr-tutorial didn't.

Last thing, I realized that I am creating the forecast function in the
Text_Sanitize_impl.h file but not referencing it it the .cc file (I
commented it out). I tried commenting out the void deceleration of the
forecast function in the .h file but then I get a new error when I try to
run the grc file(which is just a constant int source connected to my
Text_Sanitize block, which is connected the the message debug print port).

The new error is :

Traceback (most recent call last):
  File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
tb = top_block()
  File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
  File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399,
in make
return _ACK_swig.Text_Sanitize_make(*args, **kwargs)
TypeError: Required argument 'message' (pos 1) not found

I do apologize for the long questions, if any of you feel like I need to
spend more time looking into this myself before asking the mailing list,
please don't hesitate to mention it.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Aug 19, 2015 at 5:06 PM, Patrick Sathyanathan wp...@hotmail.com
wrote:

 Hi Logan,

 I have faced the same error twice recently in my OOT module and finally
 tracked it down to two causes. The basic reason for the 'object has no
 attribute' error is that Python's import of your module failed. In the two
 cases that I saw it was due to undefined symbols in the shared library for
 my module. My module was called 'tutorial' so the corresponding library is
 libgnuradio-tutorial.so and you can find it in the .../build/lib directory.
 To find out the undefined symbols do the following:

 nm -C -u libgnuradio-modulename.so

 and search for method names in your class. So if your class is 'MyClass'
 you could do:

 nm -C -u libgnuradio-modulename.so | grep MyClass

 The two cases that I ran into were:

 1. A non-virtual method in my implementation class was undefined because I
 had forgotten to prefix the method definition with the class name. So the
 .cc file had void foo(...) instead of void MyClass_impl::foo(...) and
 foo was compiled as a ordinary function. Then the command above will report
 MyClass_impl::foo as undefined.

 2. The second case I ran into was with defining callbacks in the XML file.
 If you do then you will need to add matching virtual function declarations
 in the header file. This is needed for SWIG to work correctly. For my case
 the callback foo needed a virtual function declaration virtual
 sometype foo(...) = 0; in the actual class declaration (not the ..._impl
 version) in the header file.

 Do you have callbacks ? If this is the issue then you should do a make
 clean before running make again to force SWIG to run.

 Hope this helps.

 --Patrick

 --
 Date: Wed, 19 Aug 2015 14:51:27 -0400
 From: n...@ostatemail.okstate.edu
 To: lwas...@ostatemail.okstate.edu
 CC: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object
 has no attribute 'blockname'


 My gut is telling me this is a swig problem. I don't know that it's
 frowned upon, but it's not easy to read without some kind of highlighting
 that we'd get from github or a gist with files. If I'm correct we'd also
 need to see swig/ACK.i (probably missing an include and/or gr swig block
 magic. compare to tutorial swig for sanity check)

 On Wed, Aug 19, 2015 at 10:38 AM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Hello all,

 I know this question has been asked before, several times, but I didn't
 find a solution that allowed me to use my OOT blocks without running into
 the error stated in the subject of this email.

 I scoured through this webpage(
 http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig)
 and tried adding:
 set(GR_REQUIRED_COMPONENTS RUNTIME PMT)

 to my top level

Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Washbourne, Logan]

Marcus,

Thanks for the reply! So I made the make function parameterless and removed
the instances of that parameter throughout my code, tried to run the GRC
again and got the same error as before.

I then changed the: self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
to: self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(Rubber Ducky)

reran the GRC and got the same error.

Any other hints? I'm just not sure what it's throwing an error about.

I appreciate your help,


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Aug 19, 2015 at 10:10 AM, Marcus Müller marcus.muel...@ettus.com
wrote:

 Hi!
 You only seem to define a version of make with a char*parameter, but try
 to call it without parameters. Can you try doing something like
 ACK.Text_Sanitize(rubber ducky) ?

 Best regards,
 Marcus

 Am 19. August 2015 16:38:30 MESZ, schrieb Washbourne, Logan 
 lwas...@ostatemail.okstate.edu:

 Hello all,

 I know this question has been asked before, several times, but I didn't
 find a solution that allowed me to use my OOT blocks without running into
 the error stated in the subject of this email.

 I scoured through this webpage(
 http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig)
 and tried adding:
 set(GR_REQUIRED_COMPONENTS RUNTIME PMT)

 to my top level CMakeLists.txt file, because I am using PMT objects in my
 block, but that didn't get rid of the error.

 The full error thrown is this:

 Executing: /home/comm1/Logan/Thesis/top_block.py

 Traceback (most recent call last):
   File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
 tb = top_block()
   File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
 self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
 AttributeError: 'module' object has no attribute 'Text_Sanitize'


 I looked on the mailing list for that last line error and it pointed me
 to doing what I mentioned above with the CMakeLists.txt file, but could it
 be an actual problem with the top_block.py file?

 In the addendum is all of the files I could think would be necessary for
 someone to look at if they chose to, if including this much text is frowned
 upon, please let me know.


 Addendum:

 Text_Sanitize_impl.cc

 *
 #ifdef HAVE_CONFIG_H
 #include config.h
 #endif

 #include gnuradio/io_signature.h
 #include Text_Sanitize_impl.h
 #include pmt/pmt.h
 #include stdio.h
 #include string
 #include iostream
 #include cstdio

 namespace gr {
   namespace ACK {

 Text_Sanitize::sptr
 Text_Sanitize::make(char* message)
 {
   return gnuradio::get_initial_sptr
 (new Text_Sanitize_impl(message));
 }

 void
 Text_Sanitize_impl::print_message(pmt::pmt_t d_message)
 {
 pmt::print(d_message);
 }




 /*
 void
 Text_Sanitize_impl::forecast (int noutput_items, gr_vector_int
 ninput_items_required)
 {
  +forecast+ e.g. ninput_items_required[0] = noutput_items
 }
 */
 int
 Text_Sanitize_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
 {
 const int *in = (int *) input_items[0];
 pmt::pmt_t *out = (pmt::pmt_t *) output_items[0];


 d_out_msg = pmt::string_to_symbol(d_message);
 //for(int i = 0; istrlen(d_message); i++)
 //{
 //pmt::vector_set(d_out_msg,i,d_message[i]);
 //}

 // Do +signal processing+
 // Tell runtime system how many input items we consumed on
 // each input stream.
 consume_each (noutput_items);

 // Tell runtime system how many output items we produced.
 return noutput_items;
 }

 /*
  * The private constructor
  */
 Text_Sanitize_impl::Text_Sanitize_impl(char* message)
   : gr::block(Text_Sanitize,
   gr::io_signature::make(1, 1, sizeof(int)),
   gr::io_signature::make(1, 1, sizeof(pmt::pmt_t))),
 d_out_msg(pmt::string_to_symbol(std::string())),
 d_message(message)
 {

 message_port_register_out(pmt::mp(print_message));
 set_msg_handler(pmt::mp(print),
 boost::bind(Text_Sanitize_impl::print_message, this, _1));
 }

 /*
  * Our virtual destructor.
  */
 Text_Sanitize_impl::~Text_Sanitize_impl()
 {
 }


   } /* namespace ACK */
 } /* namespace gr */


 *

 Text_Sanitize_impl.h

 **
 #ifndef INCLUDED_ACK_TEXT_SANITIZE_IMPL_H
 #define INCLUDED_ACK_TEXT_SANITIZE_IMPL_H

 #include ACK/Text_Sanitize.h
 #include gnuradio/block.h
 #include gnuradio/thread/thread.h
 #include pmt/pmt.h

 namespace gr {
   namespace ACK {

 class Text_Sanitize_impl : public

[Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'

[Washbourne, Logan]

Hello all,

I know this question has been asked before, several times, but I didn't
find a solution that allowed me to use my OOT blocks without running into
the error stated in the subject of this email.

I scoured through this webpage(
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig)
and tried adding:
set(GR_REQUIRED_COMPONENTS RUNTIME PMT)

to my top level CMakeLists.txt file, because I am using PMT objects in my
block, but that didn't get rid of the error.

The full error thrown is this:

Executing: /home/comm1/Logan/Thesis/top_block.py

Traceback (most recent call last):
  File /home/comm1/Logan/Thesis/top_block.py, line 92, in module
tb = top_block()
  File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__
self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize()
AttributeError: 'module' object has no attribute 'Text_Sanitize'


I looked on the mailing list for that last line error and it pointed me to
doing what I mentioned above with the CMakeLists.txt file, but could it be
an actual problem with the top_block.py file?

In the addendum is all of the files I could think would be necessary for
someone to look at if they chose to, if including this much text is frowned
upon, please let me know.


Addendum:

Text_Sanitize_impl.cc
*
#ifdef HAVE_CONFIG_H
#include config.h
#endif

#include gnuradio/io_signature.h
#include Text_Sanitize_impl.h
#include pmt/pmt.h
#include stdio.h
#include string
#include iostream
#include cstdio

namespace gr {
  namespace ACK {

Text_Sanitize::sptr
Text_Sanitize::make(char* message)
{
  return gnuradio::get_initial_sptr
(new Text_Sanitize_impl(message));
}

void
Text_Sanitize_impl::print_message(pmt::pmt_t d_message)
{
pmt::print(d_message);
}




/*
void
Text_Sanitize_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
 +forecast+ e.g. ninput_items_required[0] = noutput_items
}
*/
int
Text_Sanitize_impl::general_work (int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items)
{
const int *in = (int *) input_items[0];
pmt::pmt_t *out = (pmt::pmt_t *) output_items[0];


d_out_msg = pmt::string_to_symbol(d_message);
//for(int i = 0; istrlen(d_message); i++)
//{
//pmt::vector_set(d_out_msg,i,d_message[i]);
//}

// Do +signal processing+
// Tell runtime system how many input items we consumed on
// each input stream.
consume_each (noutput_items);

// Tell runtime system how many output items we produced.
return noutput_items;
}

/*
 * The private constructor
 */
Text_Sanitize_impl::Text_Sanitize_impl(char* message)
  : gr::block(Text_Sanitize,
  gr::io_signature::make(1, 1, sizeof(int)),
  gr::io_signature::make(1, 1, sizeof(pmt::pmt_t))),
d_out_msg(pmt::string_to_symbol(std::string())),
d_message(message)
{

message_port_register_out(pmt::mp(print_message));
set_msg_handler(pmt::mp(print),
boost::bind(Text_Sanitize_impl::print_message, this, _1));
}

/*
 * Our virtual destructor.
 */
Text_Sanitize_impl::~Text_Sanitize_impl()
{
}


  } /* namespace ACK */
} /* namespace gr */

*

Text_Sanitize_impl.h
**
#ifndef INCLUDED_ACK_TEXT_SANITIZE_IMPL_H
#define INCLUDED_ACK_TEXT_SANITIZE_IMPL_H

#include ACK/Text_Sanitize.h
#include gnuradio/block.h
#include gnuradio/thread/thread.h
#include pmt/pmt.h

namespace gr {
  namespace ACK {

class Text_Sanitize_impl : public Text_Sanitize
{
 private:
  // Nothing to declare in this block.
pmt::pmt_t d_out_msg;
char* d_message;
void print_message(pmt::pmt_t d_message);


 public:
  Text_Sanitize_impl(char* message);
  ~Text_Sanitize_impl();

  // Where all the action really happens
  void forecast (int noutput_items, gr_vector_int
ninput_items_required);

  int general_work(int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items);
};

  } // namespace ACK
} // namespace gr

#endif /* INCLUDED_ACK_TEXT_SANITIZE_IMPL_H */

*

Text_Sanitize.h

#ifndef INCLUDED_ACK_TEXT_SANITIZE_H
#define INCLUDED_ACK_TEXT_SANITIZE_H

#include ACK/api.h
#include gnuradio/block.h

namespace gr {
  namespace ACK {

/*!
 * \brief +description of block

[Discuss-gnuradio] OOT block not showing in GRC

[Washbourne, Logan]

Hello all,

I am trying to create a simple OOT block. Eventually I would like to create
a block that lets a transmitting agent know if their message was received
or not, but for now I am just trying to create a block that multiplies the
input values by 2 (very similar to the guided tutorial example of the
square_ff block).

So the problem is that when I follow all of the instructions no errors
appear but when I open up the GRC, my module and blocks are not there.

So hopefully no one minds if I explain how I have installed Gnuradio on my
machine and the process of creating the OOT module, in hopes someone might
find where I made an error.

I have already gotten previous help and responses on here that really did
help me out so I'd like to say again, thank you to the community.

Ok, so I used Pybombs to install Gnuradio.

/home/username/Thesis/pybombs is where I installed pybombs.

Before installing gnuradio I changed the permissions to the path of
/opt/gnuradio/pybombs by using: sudo chown username:mygroupname
/opt/gnuradio/pybombs (thanks to Nathan West)

I then used ./pybombs install gnuradio.

I changed the install prefix to /opt/gnuradio/pybombs

Then I used ./pybobms env
source /opt/gnuradio/pybombs/setup_env.sh (sometimes I have to rerun this
to get the GRC to open, not sure what I'm doing to undo this command)

Then I created the folder, /home/username/Thesis/OOT

I then used gr_modtool newmod ACK

Then /home/username/Thesis/OOT/gr-ACK gr_modtool add -t general check

altered the QA file
rewrote the check_impl.cc file

Created the build folder(/home/username/Thesis/OOT/gr-ACK/build

ran cmake ../
ran make
ran make test

Everything passed(after some debugging, array indices start at 0 btw)

I then ran gr_modtool makexml check in the gr-ACK folder

Then cd build

sudo make install
sudo ldconfig

gnuradio-companion

And I can't find my module or block.

I have a feeling that I'm still installing gnuradio or my OOT blocks in the
wrong places, but I'm not sure how to remedy it.

*check_impl.cc***

#ifdef HAVE_CONFIG_H
#include config.h
#endif

#include gnuradio/io_signature.h
#include check_impl.h

namespace gr {
  namespace ACK {

check::sptr
check::make()
{
  return gnuradio::get_initial_sptr
(new check_impl());
}

/*
 * The private constructor
 */
check_impl::check_impl()
  : gr::block(check,
  gr::io_signature::make(1,1, sizeof (float)),
  gr::io_signature::make(1,1, sizeof (float)))
{}

/*
 * Our virtual destructor.
 */
check_impl::~check_impl()
{
}

void
check_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}

int
check_impl::general_work (int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];

// Do +signal processing+
// Tell runtime system how many input items we consumed on
// each input stream.

for(int i = 0; i  noutput_items ;i++)
{
out[i] = in[i] * 2;
}


consume_each (noutput_items);

// Tell runtime system how many output items we produced.
return noutput_items;
}

  } /* namespace ACK */
} /* namespace gr */


***qa_check.py**

#!/usr/bin/env python


from gnuradio import gr, gr_unittest
from gnuradio import blocks
import ACK_swig as ACK

class qa_check (gr_unittest.TestCase):

def setUp (self):
self.tb = gr.top_block ()

def tearDown (self):
self.tb = None

def test_001_check (self):

src_data = (3, 4, 5.5, 2, 3)
expected_result = (6, 8, 11, 4, 6)
src = blocks.vector_source_f(src_data)
sqr = ACK.check()
dst = blocks.vector_sink_f()
self.tb.connect(src,sqr)
self.tb.connect(sqr,dst)
self.tb.run()
result_data = dst.data()
self.assertFloatTuplesAlmostEqual(expected_result,result_data,6)






if __name__ == '__main__':
gr_unittest.run(qa_check, qa_check.xml)




I really appreciate all of your time,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT block not showing in GRC

[Washbourne, Logan]

Kevin,

It worked! I really appreciate your help!!

Ron,

So that install prefix should be pointing to where I installed gnuradio?

(Never can know too many ways to skin a cat-metaphorically)



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Sat, Aug 8, 2015 at 5:43 PM, Kevin McQuiggin mcqui...@sfu.ca wrote:

 Hi Logan:

 I just went through the same process!  My new OOT block wasn't being
 found.  The solution is to add a [grc] segment to the config.conf file in
 ~/.gnuradio:

 I had to create the .gnuradio directory, then add the simple two-line
 [grc] stanza to a new config.conf file:

 [grc]
 local_blocks_path=/usr/local/share/gnuradio/grc/blocks

 This tells grc to look for additional blocks in the stated directory.  So
 you would do something like:

 cd
 mkdir .gnuradio
 cd .gnuradio
 vi config.conf

 Then add the two lines above, your OOT block install path may be different
 so I'd check it first.

 Hope this helps,

 Kevin

  On Aug 8, 2015, at 3:33 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:
 
  Hello all,
 
  I am trying to create a simple OOT block. Eventually I would like to
 create a block that lets a transmitting agent know if their message was
 received or not, but for now I am just trying to create a block that
 multiplies the input values by 2 (very similar to the guided tutorial
 example of the square_ff block).
 
  So the problem is that when I follow all of the instructions no errors
 appear but when I open up the GRC, my module and blocks are not there.
 
  So hopefully no one minds if I explain how I have installed Gnuradio on
 my machine and the process of creating the OOT module, in hopes someone
 might find where I made an error.
 
  I have already gotten previous help and responses on here that really
 did help me out so I'd like to say again, thank you to the community.
 
  Ok, so I used Pybombs to install Gnuradio.
 
  /home/username/Thesis/pybombs is where I installed pybombs.
 
  Before installing gnuradio I changed the permissions to the path of
 /opt/gnuradio/pybombs by using: sudo chown username:mygroupname
 /opt/gnuradio/pybombs (thanks to Nathan West)
 
  I then used ./pybombs install gnuradio.
 
  I changed the install prefix to /opt/gnuradio/pybombs
 
  Then I used ./pybobms env
  source /opt/gnuradio/pybombs/setup_env.sh (sometimes I have to rerun
 this to get the GRC to open, not sure what I'm doing to undo this command)
 
  Then I created the folder, /home/username/Thesis/OOT
 
  I then used gr_modtool newmod ACK
 
  Then /home/username/Thesis/OOT/gr-ACK gr_modtool add -t general check
 
  altered the QA file
  rewrote the check_impl.cc file
 
  Created the build folder(/home/username/Thesis/OOT/gr-ACK/build
 
  ran cmake ../
  ran make
  ran make test
 
  Everything passed(after some debugging, array indices start at 0 btw)
 
  I then ran gr_modtool makexml check in the gr-ACK folder
 
  Then cd build
 
  sudo make install
  sudo ldconfig
 
  gnuradio-companion
 
  And I can't find my module or block.
 
  I have a feeling that I'm still installing gnuradio or my OOT blocks in
 the wrong places, but I'm not sure how to remedy it.
 
  *check_impl.cc***
 
  #ifdef HAVE_CONFIG_H
  #include config.h
  #endif
 
  #include gnuradio/io_signature.h
  #include check_impl.h
 
  namespace gr {
namespace ACK {
 
  check::sptr
  check::make()
  {
return gnuradio::get_initial_sptr
  (new check_impl());
  }
 
  /*
   * The private constructor
   */
  check_impl::check_impl()
: gr::block(check,
gr::io_signature::make(1,1, sizeof (float)),
gr::io_signature::make(1,1, sizeof (float)))
  {}
 
  /*
   * Our virtual destructor.
   */
  check_impl::~check_impl()
  {
  }
 
  void
  check_impl::forecast (int noutput_items, gr_vector_int
 ninput_items_required)
  {
  ninput_items_required[0] = noutput_items;
  }
 
  int
  check_impl::general_work (int noutput_items,
 gr_vector_int ninput_items,
 gr_vector_const_void_star input_items,
 gr_vector_void_star output_items)
  {
  const float *in = (const float *) input_items[0];
  float *out = (float *) output_items[0];
 
  // Do +signal processing+
  // Tell runtime system how many input items we consumed on
  // each input stream.
 
  for(int i = 0; i  noutput_items ;i++)
  {
  out[i] = in[i] * 2;
  }
 
 
  consume_each (noutput_items);
 
  // Tell runtime system how many output items we produced.
  return noutput_items;
  }
 
} /* namespace ACK */
  } /* namespace gr */
 
 
  ***qa_check.py**
 
  #!/usr/bin/env python
 
 
  from gnuradio import gr, gr_unittest
  from gnuradio import blocks
  import ACK_swig as ACK
 
  class qa_check

Re: [Discuss-gnuradio] pybombs difficulty

[Washbourne, Logan]

Thanks Iluta and Nathan,

My problem was not being able to use the gr-tutorials examples if I didn't
have Gnuradio installed in /usr/local, but then I realized that the
gr-tutorials was also a pybombs recipe so I used pybombs to install it and
everything worked out great! Thank you both for helping me learn how to
move my install prefix around and about proper folder locations.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Aug 4, 2015 at 11:13 AM, Iluta V iluta2...@gmail.com wrote:

 Hi Logan,

 Here is a full set of commands for installing in your own home directory
 via pybombs:

 git clone https://github.com/gnuradio/pybombs
 cd pybombs
 ./pybombs config

 sudo rm -rf /home/gnuradio
 sudo mkdir /home/gnuradio
 sudo chown -R linux /home/gnuradio /home/linux/pybombs
 rm -rf inventory.dat src
 linux@Linux:~/pybombs$ ./pybombs install -v -v gnuradio

 add gnuradio and all apps you want, then change path to:

 source /home/gnuradio/setup_env.sh
 linux@Linux:~$ sudo gedit .bashrc
 linux@Linux:~$ source ~/.bashrc

 Good luck! :)

 BR,

 Iluta


 On Tue, Aug 4, 2015 at 5:25 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 So I changed the install prefix to /home/username/thesis/target and then
 deleted the inventory.dat file and removed the previous install prefix
 folder(this was usr/local, but it actually ended up in usr/local/share, I'm
 thinking this was a problem because I think there are lingering files). I'm
 having problems now, I can't remove or update any packages, it states that
 there is not an inventory file so it creates an empty one and then states
 there is nothing to do. Is there a way to have it generate a new inventory
 file? I can't install any packages because they seem to still be in the
 pybombs folder. Do you have any advice Nathan?

 My initial reasoning for changing the install prefix to usr/local/ was to
 enable me to create my own OOT modules and build the tutorial examples.
 When pybomb's install prefix was in my home directory it kept throwing an
 error about the CMake files. I tried to change the install prefix locations
 within those CMake files but that didn't seem to fix my problems.

 I'm really starting to learn that a little knowledge can be a pretty
 dangerous thing haha.

 I appreciate your time and help,

 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Mon, Aug 3, 2015 at 10:06 PM, West, Nathan 
 n...@ostatemail.okstate.edu wrote:

 Password Alert! This message may contain a request for your password.
 NEVER SEND OR RESPOND TO E-MAIL REQUESTS FOR YOUR PASSWORD. For questions
 about this alert, please contact the IT HelpDesk at 405-744-4357 or
 email helpd...@okstate.edu.
 --
 You only have to use sudo with pybombs if you don't have write
 permission to your prefix. In general it's best to avoid using sudo and
 pybombs together if possible (with the exception of when pybombs asks you
 for sudo password when using apt-get install).  You can either set the
 prefix to somewhere your user normally has write access to (typically your
 home directory), or alter permissions of your prefix. As an example, if you
 were setting your prefix to /opt/gnuradio/pybombs-v3.7.8  the least
 obtrusive way to do this is
 sudo mkdir -p /opt/gnuradio/pybombs-v3.7.8 # assuming your user
 doesn't have write access to /opt/gnuradio you need sudo to mkdir
 sudo chown myusername:mygroupname /opt/gnuradio/pybombs-v3.7.8
 ./pybombs install gnuradio

 In practice I usually make a group on my machines called 'developer' and
 add my user to it, then give the developer group ownership or write access
 (depends on what I feel like when I set up a new machine) to /opt. That
 lets me write whatever to /opt without sudo (don't forget you need to login
 after adding your user to group for it to take effect). The same principle
 can be used with /usr/local or any other directory, but IMHO you should at
 least make your work an extra layer deep so you can just rm -rf the whole
 prefix (without root!) and not have much to worry about damaging.

 Cheers,
 Nathan

 On Mon, Aug 3, 2015 at 9:15 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Thanks Nathan. Should I have to use sudo when using pybomb commands,
 now that the installation prefix is outside of my home directory(because I
 now I have to use sudo when using pybomb commands)?


 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan 
 n...@ostatemail.okstate.edu wrote:

 Logan,

 For your case deleting inventory.dat would do the trick of effectively
 resetting pybombs state (and if your done with an install rm the prefix)

 Mike,

 Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
 Radio. Try running pybombs again with -v -v


 On Monday, August 3, 2015, lwas...@ostatemail.okstate.edu wrote:

 Mike,

 When I ran

Re: [Discuss-gnuradio] pybombs difficulty

[Washbourne, Logan]

So I changed the install prefix to /home/username/thesis/target and then
deleted the inventory.dat file and removed the previous install prefix
folder(this was usr/local, but it actually ended up in usr/local/share, I'm
thinking this was a problem because I think there are lingering files). I'm
having problems now, I can't remove or update any packages, it states that
there is not an inventory file so it creates an empty one and then states
there is nothing to do. Is there a way to have it generate a new inventory
file? I can't install any packages because they seem to still be in the
pybombs folder. Do you have any advice Nathan?

My initial reasoning for changing the install prefix to usr/local/ was to
enable me to create my own OOT modules and build the tutorial examples.
When pybomb's install prefix was in my home directory it kept throwing an
error about the CMake files. I tried to change the install prefix locations
within those CMake files but that didn't seem to fix my problems.

I'm really starting to learn that a little knowledge can be a pretty
dangerous thing haha.

I appreciate your time and help,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 3, 2015 at 10:06 PM, West, Nathan n...@ostatemail.okstate.edu
wrote:

 Password Alert! This message may contain a request for your password.
 NEVER SEND OR RESPOND TO E-MAIL REQUESTS FOR YOUR PASSWORD. For questions
 about this alert, please contact the IT HelpDesk at 405-744-4357 or email
 helpd...@okstate.edu.
 --
 You only have to use sudo with pybombs if you don't have write permission
 to your prefix. In general it's best to avoid using sudo and pybombs
 together if possible (with the exception of when pybombs asks you for sudo
 password when using apt-get install).  You can either set the prefix to
 somewhere your user normally has write access to (typically your home
 directory), or alter permissions of your prefix. As an example, if you were
 setting your prefix to /opt/gnuradio/pybombs-v3.7.8  the least obtrusive
 way to do this is
 sudo mkdir -p /opt/gnuradio/pybombs-v3.7.8 # assuming your user
 doesn't have write access to /opt/gnuradio you need sudo to mkdir
 sudo chown myusername:mygroupname /opt/gnuradio/pybombs-v3.7.8
 ./pybombs install gnuradio

 In practice I usually make a group on my machines called 'developer' and
 add my user to it, then give the developer group ownership or write access
 (depends on what I feel like when I set up a new machine) to /opt. That
 lets me write whatever to /opt without sudo (don't forget you need to login
 after adding your user to group for it to take effect). The same principle
 can be used with /usr/local or any other directory, but IMHO you should at
 least make your work an extra layer deep so you can just rm -rf the whole
 prefix (without root!) and not have much to worry about damaging.

 Cheers,
 Nathan

 On Mon, Aug 3, 2015 at 9:15 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Thanks Nathan. Should I have to use sudo when using pybomb commands, now
 that the installation prefix is outside of my home directory(because I now
 I have to use sudo when using pybomb commands)?


 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan n...@ostatemail.okstate.edu
  wrote:

 Logan,

 For your case deleting inventory.dat would do the trick of effectively
 resetting pybombs state (and if your done with an install rm the prefix)

 Mike,

 Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
 Radio. Try running pybombs again with -v -v


 On Monday, August 3, 2015, lwas...@ostatemail.okstate.edu wrote:

 Mike,

 When I ran into this problem, I had to reinstall pybombs. I think the
 problem lies in changing the installation prefix after installing pybombs.

 I'm sure there is another way to fix this, I just don't know what it is.

 When I reinstalled pybombs, I defined the installation prefix when the
 several prompts are asked at the beginning.

 Sent from my Cyanogen phone

 On Aug 3, 2015 4:39 PM, Mike Markowski mike.ab...@gmail.com wrote:
 
  I use gentoo at home and have no difficulty keeping gnuradio up to
 date.
 
  At work we're on a standalone network (no internet) so occasionally
 bring computers home to update them.  Lately, I've been having trouble with
 pybombs.  Using a freshly installed ubuntu 15.04, then doing an
 
apt-get update
apt-get upgrade [not sure the update was necessary]
 
  I first used
 
apt-get install gnuradio
 
  Thinking better of it, I ran
 
apt-get remove gnuradio
apt-get autoremove
 
  Then went with pybombs
 
git clone git://github.com/pybombs/pybombs
cd pybombs
./pybombs config [use install path /usr/local/gnuradio]
./pybombs install gnuradio
 
  And after several tries continue to receive this error:
 
  [...many lines of install...]
  Unpacking

Re: [Discuss-gnuradio] pybombs difficulty

[Washbourne, Logan]

Thanks Nathan. Should I have to use sudo when using pybomb commands, now
that the installation prefix is outside of my home directory(because I now
I have to use sudo when using pybomb commands)?


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan n...@ostatemail.okstate.edu
wrote:

 Logan,

 For your case deleting inventory.dat would do the trick of effectively
 resetting pybombs state (and if your done with an install rm the prefix)

 Mike,

 Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
 Radio. Try running pybombs again with -v -v


 On Monday, August 3, 2015, lwas...@ostatemail.okstate.edu wrote:

 Mike,

 When I ran into this problem, I had to reinstall pybombs. I think the
 problem lies in changing the installation prefix after installing pybombs.

 I'm sure there is another way to fix this, I just don't know what it is.

 When I reinstalled pybombs, I defined the installation prefix when the
 several prompts are asked at the beginning.

 Sent from my Cyanogen phone

 On Aug 3, 2015 4:39 PM, Mike Markowski mike.ab...@gmail.com wrote:
 
  I use gentoo at home and have no difficulty keeping gnuradio up to date.
 
  At work we're on a standalone network (no internet) so occasionally
 bring computers home to update them.  Lately, I've been having trouble with
 pybombs.  Using a freshly installed ubuntu 15.04, then doing an
 
apt-get update
apt-get upgrade [not sure the update was necessary]
 
  I first used
 
apt-get install gnuradio
 
  Thinking better of it, I ran
 
apt-get remove gnuradio
apt-get autoremove
 
  Then went with pybombs
 
git clone git://github.com/pybombs/pybombs
cd pybombs
./pybombs config [use install path /usr/local/gnuradio]
./pybombs install gnuradio
 
  And after several tries continue to receive this error:
 
  [...many lines of install...]
  Unpacking liblog4cpp5-dev (1.0-4) ...
  Setting up liblog4cpp5-dev (1.0-4) ...
  installation ok via: deb
  Installing from source: gnuradio
  Cloning into 'gnuradio'...
  Checking connectivity... done.
  Cloning into 'volk'...
  remote: Counting objects: 5450, done.
  remote: Compressing objects: 100% (10/10), done.
  remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
  Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
  Resolving deltas: 100% (3918/3918), done.
  Checking connectivity... done.
 
  CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
 -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
 
  Configuring: (100%)
 [==]
  Configuration failed. Re-trying with higher verbosity.
  make: *** No targets specified and no makefile found.  Stop.
  Build failed. See output above for error messages.
 
  Any hints as to what is going wrong?
 
  Thanks,
  Mike
 ___
 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

Re: [Discuss-gnuradio] Firs byte always missing on TCP BPSK encoder

[Washbourne, Logan]

It's been my experience that the packet decoder block always loses 1
payload length.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Jul 22, 2015 at 12:23 PM, Marcus Müller marcus.muel...@ettus.com
wrote:

  It seems your per-packet payload is but 1; and it's quite probable the
 first packet gets lost in trying to synchronize, which would explain your
 loss.

 Best regards,
 Marcus


 On 22.07.2015 19:20, Jason Matusiak wrote:

 I have a BPSK modulator/demodulator simulator script (attached) that has
 me a little perplexed.  I have a TCP source on the input and a TCP sink
 on the output.  The Encoder is setup for a payload length of 1.

 Everything works except that I seems to always lose the first byte.

 What I do is run the script and then run:
 nc localhost 6 in one terminal
 and nc localhost 60001 in another

 If I type, this is a test in the first terminal (minus the quotes) and
 hit enter, I see his is a test in the second terminal.  So it looks
 like things are working, but why would I be losing that first byte?  It
 seems to happen every time I start the script fresh.



 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Adding OOT Modules from Github

[Washbourne, Logan]

Chris,

Thanks for the advice. I ended up reinstalling Ubuntu 14.04, because I had
not installed gnuradio through pybombs originally and I prematurely deleted
the build folder for gnuradio before I could cleanly remove it. Now
everything works great though, since I stuck to installing everything
through pybombs.

Again, I really appreciate your help,


Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Jun 23, 2015 at 5:33 PM, Chris Kuethe chris.kue...@gmail.com
wrote:

 inventory.dat contains the state of all the installed packages; you
 could edit it or just remove it and restart your builds.

 On Tue, Jun 23, 2015 at 2:06 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Chris,

 I took your advice and uninstalled Gnuradio (to the best of my knowledge,
 I prematurely deleted the build folder before I could do a clean uninstall,
 so I searched around and deleted every instance of Gnuradio I could find,
 which I'm sure is the worst way to do it). When I try to install Gnuradio
 from Pybombs, I get an error stating:

 comm1@Comm1:~/Logan/source/pybombs$ ./pybombs install gnuradio -v
 Settled on prefix: /home/comm1/Logan/source/target
 Loading recipes ...
 Checking if gnuradio is installed: No
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of make (4.0) is = than 3.75
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-date-time-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-filesystem-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-program-options-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-regex-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-thread-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libboost-test-dev (1.55.0) is = than 1.53
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libgsl0-dev (1.16) is = than 1.13
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of libgsl0ldbl (1.16) is = than 1.13
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-cheetah (2.4.4) is = than 2.0
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-numpy (1.8.2) is = than 1.5
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-lxml (3.3.6) is = than 2.3.2
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-gtk2 (2.24.0) is = than 2.17
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-cairo-dev (1.8.8) is = than 1.8
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of cmake (2.8.12) is = than 2.8.3
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of cmake-data (2.8.12) is = than 2.8.3
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-qt4 (4.11.2) is = than 4.6.2
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-qwt5-qt4 (5.2.1) is = than 5.2
 PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
 version of python-zeroc-ice (3.5.1) is = than 3.5
 Installing packages:
 * gnuradio
 Installing from source: gnuradio
 -- Build type set to RelWithDebInfo.
 -- Extracting version information from git describe...
 -- Compiler Version: gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1
 Copyright (C) 2014 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
 PURPOSE.
 -- Compiler Flags: /usr/bin/gcc:::-O2 -g -DNDEBUG  -fvisibility=hidden
 -Wsign-compare -Wall -Wno-uninitialized
 /usr/bin/g++:::-O2 -g -DNDEBUG -fpermissive -fvisibility=hidden
 -Wsign-compare -Wall -Wno-uninitialized
 -- ADDING PERF COUNTERS
 -- Building Static Libraries: OFF
 -- Boost version: 1.55.0
 -- Found the following Boost libraries:
 --   date_time
 --   program_options
 --   filesystem
 --   system
 --   thread
 --
 -- Checking for module SWIG
 -- Found SWIG version 2.0.12.
 --
 -- The build system will automatically enable all components.
 -- Use -DENABLE_DEFAULT=OFF to disable components by default.
 --
 -- Configuring python-support support...
 --   Dependency PYTHONLIBS_FOUND = TRUE
 --   Dependency SWIG_FOUND = TRUE
 --   Dependency SWIG_VERSION_CHECK = TRUE
 --   Enabling python-support support.
 --   Override with -DENABLE_PYTHON=ON/OFF

Re: [Discuss-gnuradio] Adding OOT Modules from Github

[Washbourne, Logan]

Chris,

I appreciate the quick reply. I should have mentioned more in my first
email. Pybombs was my initial route I was going to take but when I run
./pybombs list gr-psk-burst is not listed. Although it is listed on the
CGRAN website.

Tim,

I am running GRC 3.7.3, and I am 95% sure I used Pybombs a couple of months
ago to install gnuradio.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Jun 23, 2015 at 3:24 PM, Chris Kuethe chris.kue...@gmail.com
wrote:

 PyBOMBS is your friend. https://github.com/gnuradio/pybombs

 On Tue, Jun 23, 2015 at 1:21 PM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Hello,

 I am trying to use the Burst PSK project that Tim O'Shea and Kiran Karra
 developed and I am having trouble figuring out how to add the projects'
 blocks into my version of Gnuradaio. Is there an easy way to add multiple
 blocks at a time or is it necessary to add them one at a time (using the
 method described in the OOT tutorial)?

 I haven't tried much in the way of solving this problem because I would
 consider myself a novice when it comes to Linux but a hint in the right
 direction would definitely be welcomed.

 I appreciate your time,

 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 GDB has a 'break' feature; why doesn't it have 'fix' too?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Adding OOT Modules from Github

[Washbourne, Logan]

Hello,

I am trying to use the Burst PSK project that Tim O'Shea and Kiran Karra
developed and I am having trouble figuring out how to add the projects'
blocks into my version of Gnuradaio. Is there an easy way to add multiple
blocks at a time or is it necessary to add them one at a time (using the
method described in the OOT tutorial)?

I haven't tried much in the way of solving this problem because I would
consider myself a novice when it comes to Linux but a hint in the right
direction would definitely be welcomed.

I appreciate your time,

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Adding OOT Modules from Github

[Washbourne, Logan]

Chris,

I took your advice and uninstalled Gnuradio (to the best of my knowledge, I
prematurely deleted the build folder before I could do a clean uninstall,
so I searched around and deleted every instance of Gnuradio I could find,
which I'm sure is the worst way to do it). When I try to install Gnuradio
from Pybombs, I get an error stating:

comm1@Comm1:~/Logan/source/pybombs$ ./pybombs install gnuradio -v
Settled on prefix: /home/comm1/Logan/source/target
Loading recipes ...
Checking if gnuradio is installed: No
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of make (4.0) is = than 3.75
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-date-time-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-filesystem-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-program-options-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-regex-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-thread-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libboost-test-dev (1.55.0) is = than 1.53
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libgsl0-dev (1.16) is = than 1.13
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of libgsl0ldbl (1.16) is = than 1.13
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-cheetah (2.4.4) is = than 2.0
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-numpy (1.8.2) is = than 1.5
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-lxml (3.3.6) is = than 2.3.2
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-gtk2 (2.24.0) is = than 2.17
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-cairo-dev (1.8.8) is = than 1.8
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of cmake (2.8.12) is = than 2.8.3
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of cmake-data (2.8.12) is = than 2.8.3
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-qt4 (4.11.2) is = than 4.6.2
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-qwt5-qt4 (5.2.1) is = than 5.2
PyBombs.sysutils - INFO - have_deb: Satisfies requirement...installed
version of python-zeroc-ice (3.5.1) is = than 3.5
Installing packages:
* gnuradio
Installing from source: gnuradio
-- Build type set to RelWithDebInfo.
-- Extracting version information from git describe...
-- Compiler Version: gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/gcc:::-O2 -g -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/g++:::-O2 -g -DNDEBUG -fpermissive -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized
-- ADDING PERF COUNTERS
-- Building Static Libraries: OFF
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   thread
-- 
-- Checking for module SWIG
-- Found SWIG version 2.0.12.
-- 
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
-- 
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
-- 
-- Configuring testing-support support...
--   Dependency CPPUNIT_FOUND = TRUE
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
-- 
-- Configuring VOLK support...
--   VOLK submodule is not checked out.
--   To check out the VOLK submodule, use:
-- git pull --recurse-submodules=on
-- git submodule update
--   External VOLK disabled.
--   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
-- 
CMake Error at CMakeLists.txt:310 (message):
  VOLK required but not found.


-- Configuring incomplete, errors occurred!
See also
/home/comm1/Logan/source/pybombs/src/gnuradio/build/CMakeFiles/CMakeOutput.log.
Configuration failed. Re-trying with higher verbosity.
make: *** No targets specified and no makefile found.  Stop.
Build failed. See output above for error messages.


I can run

Re: [Discuss-gnuradio] PSK Modulation-Demodulation

[Washbourne, Logan]

So would a good solution to this be the packet encoder and packet decoder
blocks? Since they utilize a preamble and access code? I tried to use the
simple framer block in conjunction with the unpacked to packed byte block
but was unsuccessful in getting a matching output, I will continue to play
around with that configuration but for now do you think the packet encoder
route would be a good solution?

Again, I really appreciate everyone's willingness to help.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Jun 16, 2015 at 10:14 AM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Jun 16, 2015 at 11:01 AM, Washbourne, Logan 
 lwas...@ostatemail.okstate.edu wrote:

 Hello,

 I know a similar question has been asked before on this mailing list but
 I didn't quite get a solution out of it. I am generating a random byte
 source, either ones or zeroes, modulating them with DBPSK and immediately
 demodulating them. The problem I am running into is that I get roughly 8
 times the number of bytes out of the demodulation block than I am inputting
 into the modulation block. I believe its a packed vs. unpacked byte problem
 but every attempt at packing the output bytes yields an output that doesn't
 match the input.

 Attached are the GRC file, and the output file streams.

 Does anyone have any suggestions? I appreciate all of your time,



 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)



 The problem is that you don't know which bit to put where in the byte. So
 just packing the output bits into 8 bits per byte doesn't necessarily give
 you the right information. Say you transmit a byte with bits [a b c d e f g
 h]. After the delays introduced by the transmit and receiver filter and the
 channel, when you pack the results, you could get something like [x x x a b
 c d e] [f g h 0 0 0 0 0], for some unknown number of x's.

 You need some logic that knows how to discover the start of your
 information and get rid of those x's. The framer blocks do this with some
 assumed formatting and expectations. Johnathan and I have been working on a
 better version of this, but we haven't had a chance to finish it off.

 Tom


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio