Re: [Discuss-gnuradio] CRC32 discrepancy

[Marcus Müller]

Hi Eric!

Thanks for the bug report! Tracking that as an issue on github [1] now.

You don't happen to have a fix that you've tested already?

Best regards,

Marcus


[1] https://github.com/gnuradio/gnuradio/issues/1407


On 08/03/2017 04:54 PM, ERIC BANWART wrote:


I am using the Stream CRC32 block and was having trouble getting the 
CRCs to pass. After some debugging I discovered that the 
calculated CRC is different depending on whether or not the source 
data is packed. This can be observed using the attached flow graph. 
The result of the packed stream appears to be correct. I looked at the 
code for the block (crc32_impl_bb.cc) and that see that regardless of 
the Packed setting in the block the CRC calculated with: 
d_crc_impl.process_bytes(in, packet_length);



I believe that for the unpacked case, either the bits need be repacked 
before the calculation or repeated calls to process_bits should be 
used in place of the the call to process_bytes.



My version of gnuradio is:  3.7.12git-126-g37d373ac


Thanks!

Eric



___
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] [GSoC 17] DAB: Updates of the week

[Luca Schmid]

Hi all,
you can read on my blog about my latest progress. I included the
transmitter in the app.

https://dabtransceiver.wordpress.com/2017/08/04/week-12-a-basic-transceiver-app/

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

[Discuss-gnuradio] A newcomer needs help with SDR Projects list

[Ash SDR]

Hello everyone ,

I have limited background with RF Systems because of my graduate level
courses in wireless and digital communications and NOT any industr
experience in PHY Layer .

 Now , I am working on vehicle-to-vehicle communications in an Automotive
OEM industry mostly at application layer level using V2V Radios

I am planning to move to PHY layer . So, I brought my own software defined
radio (hackRF one) and learning GNU Radio to use with it after office
hours.  I did go through these books which pretty much focus on  using SDR
and GNU Radio for simple wireless communications... (doesn't go much in
technical detail though)  http://www.fieldxp.com/buy/


I would like to do some real-time projects like sending and receiving data
using WiFi / or any other real time wireless communications.  . But I do
need a baseline for that as I am not a full time practitioner of wireless
communications and its been 2 years I worked with those devices at my
school.
Are there any links/location (or) anyone have some documentation of any
project which is publicly available which i can go through , understand and
implement it ...

Please any comments/suggestions to improve my usage on software defined
radios will be helpful ..
 I know this a a great forum for GNU Radio discussion , but please help out
a newbie who want to get into the world of software defined radios.

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

Re: [Discuss-gnuradio] A newcomer needs help with SDR Projects list

[Derek Kozel]

Hello Ash,

A project, which would be a challenge, would be to implement a set of GNU
Radio blocks for NRSC-5. This blog post does a great job of breaking down
the different layers and there is a GPLv3 licensed code base for reception
included.
http://theori.io/research/nrsc-5-c

This definitely isn't a complete beginner project, but is simpler than WiFi
or any other protocol which is bi-directional. It's also the type of
project which would be useful to the GNU Radio community and you could
likely get helpful responses. Given that you have a graduate background in
some digital communications the fundamental ideas are probably familiar to
you. The actual implementation details are in the receive source code and
GNU Radio has many of the basic components already such as Viterbi decoders
and blocks for working with OFDM.

Simpler would be something like the JT digital modes.
http://www.physics.princeton.edu/pulsar/k1jt/doc/wsjt/#PROTOCOLS

Regards,
Derek

On Fri, Aug 4, 2017 at 4:44 PM, Ash SDR  wrote:

> Hello everyone ,
>
> I have limited background with RF Systems because of my graduate level
> courses in wireless and digital communications and NOT any industr
> experience in PHY Layer .
>
>  Now , I am working on vehicle-to-vehicle communications in an Automotive
> OEM industry mostly at application layer level using V2V Radios
>
> I am planning to move to PHY layer . So, I brought my own software defined
> radio (hackRF one) and learning GNU Radio to use with it after office
> hours.  I did go through these books which pretty much focus on  using SDR
> and GNU Radio for simple wireless communications... (doesn't go much in
> technical detail though)  http://www.fieldxp.com/buy/
> 
>
> I would like to do some real-time projects like sending and receiving data
> using WiFi / or any other real time wireless communications.  . But I do
> need a baseline for that as I am not a full time practitioner of wireless
> communications and its been 2 years I worked with those devices at my
> school.
> Are there any links/location (or) anyone have some documentation of any
> project which is publicly available which i can go through , understand and
> implement it ...
>
> Please any comments/suggestions to improve my usage on software defined
> radios will be helpful ..
>  I know this a a great forum for GNU Radio discussion , but please help
> out a newbie who want to get into the world of software defined radios.
>
> Best Regards
> Ash
>
>
> ___
> 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] [GSoC 2017] gr-bokehgui: Updates for the week 12

[Kartik Patel]

Hello all,

This week I tried to create the simplest waterfall sink with Bokeh. The
details are available in my latest blog post here
.

Regards,
Kartik Patel

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

[Discuss-gnuradio] [Wiki] Editing enabled again, registration is not

[Martin Braun]

Hi all,

you may or may not have witnessed the spam infestation on our wiki.
We're not quite sure what happened, but it looks like ReCAPTCHA stopped
working and then spambots had nothing to stop them.

We've cleaned up the spam, and disabled the bot accounts, and re-enabled
editing. However, creating new accounts is disabled for a while until
we're more confident this won't happen again.

Logging in with your github credentials should be enabled, but not
tested yet. Maybe someone can report if it does.

Cheers,
Martin

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

Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 1

[Martin Braun]

Python-only blocks aren't available in C++ anyway, so GRC can't generate
code to include them. Most of our blocks are swigged though, so it's not
really a problem.

-- M

On 08/01/2017 04:11 AM, Håkon Vågsether wrote:
> Hi Kartik, 
> 
> Thanks for asking! 
> 
> What I've envisioned is that the user chooses whether he/she wants GRC
> to generate C++ or Python code. Currently the blocks' YAML files only
> contain data and snippets that work in Python, ("from x import y"
> doesn't work in C++, of course :)) so I'll have to add the corresponding
> C++ data to the blocks. 
> 
> This way, GRC will know whether to use the Python or C++ "parts" of the
> block when generating. Hope this cleared things up! :) 
> 
> Best regards, 
> Håkon Vågsether 
> 
> 
> 31. jul. 2017 1.47 p.m. skrev "Kartik Patel"  >:
> 
> Hello Håkon,
> 
> Your project is pretty interesting. Finally, we are trying to give a
> platform to "C++ only" programmers, too. :P
> 
> I have one query. Are you going to connect the Python blocks in the
> generated C++ script? I am not sure if it is even possible, but may
> be SWIG can help. If not, then will you be looking for some
> parameters in the blocks XML whether the block is Python? In other
> words, how are you going to detect if it's Python block?
> 
> Thanks!
> 
> Regards,
> Kartik Patel
> 
> 
> On Mon, Jul 31, 2017 at 2:27 PM, Håkon Vågsether  > wrote:
> 
> Not yet, I'll do it today :)
> 
> Best regards,
> Håkon Vågsether
> 
> On Mon, Jul 31, 2017 at 9:32 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
> 
> Hi Håkon,
> 
> thanks for the update :) And of course, thank for the
> python3 bugfix! Did you do a pull-request against the
> "mainline" gnuradio/python3 branch yet?
> 
> Very much looking forward to the moment where we can get the
> first compiling C++ flow graph out of GRC :)
> 
> Best regards,
> 
> Marcus
> 
> 
> On 07/31/2017 12:19 AM, Håkon Vågsether wrote:
>> Hi all, 
>>
>> The focus for this week has been the header file template.
>> I've just updated my blog with some more details, you can
>> check it out at:
>>
>> http://grccpp.wordpress.com
>>
>> If you have any questions or suggestions, please don't
>> hesitate to ask :) 
>>
>> Best regards, 
>> Håkon Vågsether 
>>
>>
>> ___
>> 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 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Depricated selector and valve.

[Imre Biacsics]

Dear pro's

I am trying to organize my experiments and prevent overcrowded flowgraphs.
Let's consider an multimode receiver with AM and FM demodulation as  
example.


The GUI in the top_block, a 'hier' block with the baseband signal as input  
and

demodulated audio as output.

Two seperate Hier block for AM and FM demodulation. Hence it is depricated,
i tried to use the selector block to route the signals to and from the  
demods.
Wich is working in a single block, but residing in a Hier it crashes after  
switching.


It seems the existing flow is not paused before switching to another. (Am  
i right?)


Another concept: the 'Multiply const by vector' as signal switch.

The selectors where recplaced by this block, de vector is choosen in such  
a way that

always one in/output is not muted. (Got it working)

The next thing happened: after listening for about 30sec's to FM it  
crashes and gave the OO

indication. Found the problem in de AM demod. (Misaligned sample rates)

Ahh, the multiply const was NOT stopping any signal to the AM demod, just  
multiplying by zero.

So both blocks kept processing, the AM demod with a stream of zero's.

This is also not the proper solution, i want to experiment with an  
unlimited amount of

modulation types. This way every block is eating performance.

Am i thing the wrong pad? Or is there another solution for the same  
principle?


Imre Biacsics

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