i just typed "RTFM" in google images :)
concerning the documentation :
IMHO
i can't blame anyone to have written the documentation in C++ or Python. in my early days of a C code dev i used to write the doc in raw C code if no doc at all
do you know why ARDUINO or RASPBERRY PI have become essential tools for discovering electronics ?
it is because it was not intended for electronics engineer
it was intended to be used by artists, musicians, hobbyists, kids, scholars, etc...
as a consequence, you don't have to write (at first) any line of code to make you LED blink
there is PLENTY of examples of code and SCHEMATICS all over the internet
i'm a hamradio op and an EE engineer, i love to talk about antennas, modulations, bit error correcting/detection, linear algebra, filters, signal and so on, but i don't like C++
that is why MY ideal documentation would have been AN EXAMPLE FOR EACH BLOCK with graphics
and simple diagrams explaining tags, messages for each block
i don't think that the diagram below is self explanatory for packet decoding
Bob
Le mar. 1 janv. 2019 à 19:01, Kevin McQuiggin <address@hidden> a écrit :
Hi Alban et al:Great RTFM graphic!gnuradio’s documentation could indeed be much better: this is a discussion topic at conferences and meetings. I had the same issues a couple of years ago when I was brand new.Unfortunately, for undocumented blocks, or those ones where the docs are not complete, the best way to figure out what the block or component does is to read the source code. This is not ideal if you don’t have (for example) C++ experience, but if you have any coding experience at all then with a bit of effort (and support from the excellent helpers on this list) you can likely figure it out.The online docs do give enough information on gnuradio’s methodology that you can then figure out what a block does, what its parameters mean etc. If it isn’t, then you can simply ask “what does parameter k do in block so-and-so” on the list, and (likely) the author will get back to you to explain it.This is not a perfect answer to your question but it’s a start. gnuradio is complex, and especially complex behind the curtain, so expect that it will take some digging (and consequent learning, which is good!) to get to where you want to be,Happy 2019,KevinOn Jan 1, 2019, at 9:53 AM, Alban Meffre <address@hidden> wrote:Happy new year everyone !i would be glad if someone explain me how to use the HPD block, how do i setup messages with PMT blabla, and what is to packet_len tag and how to pass the packet length etc.the packet_rx exmple work with OFDM and has nothing to do with simple FSK frame decodingi will try do decode the documentation 😀<image.png>very best regards,BobLe mar. 1 janv. 2019 à 11:21, Daniel Estévez <address@hidden> a écrit :El 31/12/18 a las 21:27, Ed Criscuolo escribió:
> But this would only work well if there is enough gap time and/or preamble bits and/or fill bytes between the packets. Otherwise, you will consume and discard the beginning of the next packet.
Hi Ed,
My solution makes a PDU of the maximum size whenever a syncword is
detected, even if different detections overlap.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--_______________________________________________Alban MEFFRE F4GSW
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Alban MEFFRE F4GSW