[Discuss-gnuradio] Flowgraph branching statements and transceiver
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
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 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
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
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, 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 > 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 >> 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
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 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 > 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 >>>
Re: [Discuss-gnuradio] DBPSK and USRPs
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 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 > 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
I am using 250k! Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller 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
[Discuss-gnuradio] DBPSK and USRPs
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] Correlation Estimator Over the Air
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
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
> on behalf
> of Washbourne, Logan
> *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
> 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. O
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 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 >> 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 >>> >>> >>> >&g
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
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 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 >> 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*s
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
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 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 > 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 >>> 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 wrote: >>>> > >>>> > I can't open and look at your flow now, but it
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
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 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 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 > 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 >
Re: [Discuss-gnuradio] Correlation Estimator Over the Air
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 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
[Discuss-gnuradio] Correlation Estimator Over the Air
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] Questions about burst communication
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
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
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&daughterboard) 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
[Discuss-gnuradio] USRP Structure
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
Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process
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] tracking the transmission/receiving process
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
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 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 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 >>>> th
Re: [Discuss-gnuradio] General_Work Not Executing
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 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
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'
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:
ACK.Text_Sanitize($msg)
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
> 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
> wrote:
>
>> I see the following in the output of "nm -C -u":
>>
>> U gr::ACK::Text_Sanitize_impl::forecast(int, std::vector> std::allocator >&)
>>
>> 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-.so
>>
>> and the results of that can be found here:
>> https://gist.github.com/loganwashbourne under the *nm -C -u
>> libgnuradio-.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.
>>
>&g
Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'
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
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
wrote:
> I see the following in the output of "nm -C -u":
>
> U gr::ACK::Text_Sanitize_impl::forecast(int, std::vector std::allocator >&)
>
> 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-.so
>
> and the results of that can be found here:
> https://gist.github.com/loganwashbourne under the *nm -C -u
> libgnuradio-.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
> 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
Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'
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
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
>> 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
>> #include "Text_Sanitize_impl.h"
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> 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; 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&
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-.so and the results of that can be found here: https://gist.github.com/loganwashbourne under the *nm -C -u libgnuradio-.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 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 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-.so > > and search for method names in your class. So if your class is 'MyClass' > you could do: > > nm -C -u libgnuradio-.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 > 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.ed
[Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'
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
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
#include "Text_Sanitize_impl.h"
#include
#include
#include
#include
#include
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; i
// 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
#include
#include
#include
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
#include
namespace gr {
namespace ACK {
/*!
* \brief <+description of block+>
* \ingroup ACK
*
*/
class ACK_API Text_Sanitize : virtual public gr::block
Re: [Discuss-gnuradio] OOT block not showing in GRC
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 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
> > #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;
> > }
> >
> >
[Discuss-gnuradio] OOT block not showing in GRC
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
#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] pybombs difficulty
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 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, Wa
Re: [Discuss-gnuradio] pybombs difficulty
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 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 > > 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, 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 wrote: >>>> > >>>> > I use gentoo at home and have no difficulty keeping gnuradio up to >>>> date. >>>> > >>>> > At work we're on a standalo
Re: [Discuss-gnuradio] pybombs difficulty
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 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, 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 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
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 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
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 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 PER
Re: [Discuss-gnuradio] Adding OOT Modules from Github
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 speci
Re: [Discuss-gnuradio] Adding OOT Modules from Github
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 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
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] PSK Modulation->Demodulation
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 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
