Re: [Discuss-gnuradio] compressing I/Q files
FLAC ? Le dim. 10 mars 2019 à 12:56, Benny Alexandar a écrit : > Yes, converting float 32bit to short16 is an option, compressing using > 7zip or gzip won't give good compression . > -- > *From:* Discuss-gnuradio outlook@gnu.org> on behalf of Kristoff > *Sent:* Sunday, March 10, 2019 3:57 PM > *To:* discuss-gnuradio@gnu.org > *Subject:* [Discuss-gnuradio] compressing I/Q files > > Hi all, > > > > Simple and short question: > What is the best way to compress a raw I/Q file? A generic > compression-tool like gzip, zip? Or are there better and specialised tools? > > > Is converting the data in the I/Q file from float to short an option? > > > Kristoff > > > ___ > 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 > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bit stuffing DVB-S TX example ?
hi thanks for your answers
my symbol rate is 300 ksps
using this calculator
http://www.satbroadcasts.com/DVB-S_Bitrate_and_Bandwidth_Calculator.html
and these settings : QPSK rate 1/2 FEC frame 64800
i get 276.5 kbps of TS bitrate
here are my settings for ffmpeg :
*ffmpeg -re -f lavfi -i testsrc=s=640x480:r=25:n=1 -vf
"drawtext=text=%{localtime}:x=(w-tw)/2:y=h-th-37:fontsize=20:fontcolor=yellow:borderw=2:bordercolor=black"
-pix_fmt yuv420p -an -g 25 -b:v 228k -c:v libx264 -tune zerolatency
-maxrate 228k -bufsize 230k -nal-hrd cbr -f mpegts
udp://127.0.0.1:1234?pkt_size=188 <http://127.0.0.1:1234?pkt_size=188>*
this generates a test pattern very close to 275 kbps
as i'm very close to the DVB-S net bitrate i get a near constant output
power (with some small gaps) and SDRAngel is quite happy
i will play with the -muxrate option to see if this keeps tightly the
bitrate at maximum limit
best regards
Bob
Le ven. 8 févr. 2019 à 13:22, Raydel Abreu (CM2ESP) a
écrit :
> Hi Ron
>
> That formula it's very useful! Thanks. I have a silly question (sorry for
> it). If I understand correctly 800 is the symbol rate and 12901961 is
> the TS rate? Correct?
>
> The multiply by 2 is because Tx signal is QPSK? If that's so then it will
> be 1 for BPSK, 3 for 8PSK and so on Am I right?
>
> Thanks!
>
> Raydel
>
>
>
>
> El jue., 7 de feb. de 2019 7:26 PM, Ron Economos
> escribió:
>
>> First, you have to match the TS rate to the symbol rate. The equation is:
>>
>> Symbol rate * 2 * 188/204 * code rate
>>
>> For the example flow graph:
>>
>> 800 * 2 * 188/204 * 7/8 = 12.901961 Mbps
>>
>> Second, you need to constrain the video bitrate to fit into the selected
>> TS bitrate. With ffmpeg, something like this:
>>
>> ffmpeg -i test.mp4 -c:v libx264 -b:v 10M -minrate 11M -maxrate 11M
>> -bufsize 8M -c:a copy -muxrate 12901961 test.ts
>>
>> For SD video, a smaller bufsize like 2M should be used.
>>
>> Ron
>> On 2/7/19 15:15, Alban Meffre wrote:
>>
>> Hi All
>> did some transmission test in DVB-S tonight
>> TX : ffmpeg + gnuradio + pluto SDR
>> RX : RTLSDR + sdrangel
>> it works but there are some gaps in the received signal because the TS
>> stream bitrate is slightly less to the maximum usable bitrate
>>
>> is it possible to add some bit stuffing at DVB-S modulator side to make
>> to output power constant ?
>>
>> Bob
>>
>> --
>> Alban MEFFRE F4GSW
>>
>>
>>
>> ___
>> 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
>
--
Alban MEFFRE F4GSW
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bit stuffing DVB-S TX example ?
Hi All did some transmission test in DVB-S tonight TX : ffmpeg + gnuradio + pluto SDR RX : RTLSDR + sdrangel it works but there are some gaps in the received signal because the TS stream bitrate is slightly less to the maximum usable bitrate is it possible to add some bit stuffing at DVB-S modulator side to make to output power constant ? Bob -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bit or symbol padding for continuous power
Hi all is there a way to add bit or symbols to an asynchronous PDU source in order to have a interrupted output power ? i mean with stock gnuradio blocks and not OOT i think that it would be better to stuff random symbols after FEC and modulation, in order to keep the output power spectrum as flat as possible and make the corr_est block work flawlessly in automated threshold mode thanks -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] correlation estimator reliability problem
Hi All did someone make the test_corr_est.grc example work properly recently ? i tried the 3.7.13 gnuradio version on linux, macos and windows in all versions the output of the correlation estimator block is really a mess this block put tag even if there is no signal at all, with corr_est = 0 yesterday i managed to transmit a realtime MPEGTS videosignal using the gnuradio example packet_tx -> packet_rx. i used an analog devices ADALM PLUTO as an emitter and a RTLSDR as a receiver. both antenna where put side by side at a few centimeter distance so the received baseband signal had an amplitude near 0.5 the problem was that the transmission did not work for more than few tens of second because the correlation block added misplaced tags every now and then and put the header/payload demux in a locked state so i got #f and no more packet output ! another problem is that if i set the thershold to 0., 0.9 or more 9's, the result is not satisfying. is someone able to explain me how to use correlation estimation block in a reliable way ? do i need to set the thershold to ABSOLUTE mode ? thanks bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help with OOT module header_format_base child
hi all
i created a "noblock" OOT module
child class of header_format_base
no XML installed (edited the Cmakelists file in grc folder)
compilation OK
installation OK
nm -C -u lib-*** OK
python import OK
in top_block.py i have these lines :
self.hdr_format = hdr_format =
f4gsw.header_format_cc1101('1101001110010001', 0,1)
...
self.digital_protocol_formatter_async_0 =
digital.protocol_formatter_async(hdr_format)
but i still get this error at runtime :
Traceback (most recent call last):
File "top_block.py", line 124, in
main()
File "top_block.py", line 112, in main
tb = top_block_cls()
File "top_block.py", line 74, in __init__
self.digital_protocol_formatter_async_0 =
digital.protocol_formatter_async(hdr_format)
File "/usr/lib/python2.7/dist-packages/gnuradio/digital/digital_swig2.py",
line 1242, in make
return _digital_swig2.protocol_formatter_async_make(format)
TypeError: in method 'protocol_formatter_async_make', argument 1 of
type 'gr::digital::header_format_base::sptr const &'
and if i write:
self.digital_protocol_formatter_async_0 =
digital.protocol_formatter_async(hdr_format.base())
i get the error :
Traceback (most recent call last):
File "top_block.py", line 124, in
main()
File "top_block.py", line 112, in main
tb = top_block_cls()
File "top_block.py", line 74, in __init__
self.digital_protocol_formatter_async_0 =
digital.protocol_formatter_async(hdr_format.base())
AttributeError: 'header_format_cc1101' object has no attribute 'base'
i you look at my c++ code below
i did neither redefine the "sptr" member nor the base() method in the
child class
because i read nothing about that in the comments in the
header_format_base.h file
head of header_format_base.h :
class DIGITAL_API header_format_base
: public boost::enable_shared_from_this
{
public:
typedef boost::shared_ptr sptr;
header_format_base();
virtual ~header_format_base();
sptr base() { return shared_from_this(); };
sptr formatter() { return shared_from_this(); };
...
head of header_format_cc1101.h:
#include
#include
namespace gr {
namespace f4gsw {
/*!
* \brief <+description+>
*
*/
class F4GSW_API header_format_cc1101
: public digital::header_format_base
{
public:
header_format_cc1101(const std::string _code, int
threshold,int bps);
~header_format_cc1101();
...
head of header_format_cc1101.cc:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include
#include
#include
#include
#include
namespace gr {
namespace f4gsw {
header_format_cc1101::header_format_cc1101(const std::string
_code, int threshold, int bps)
: header_format_base(),
d_bps(bps), d_data_reg(0), d_mask(0), d_threshold(0),
d_pkt_len(0), d_pkt_count(0), d_nbits(0)
{
if(!set_access_code(access_code)) {
throw std::runtime_error("header_format_cc1101: Setting access
code failed");
}
set_threshold(threshold);
}
header_format_cc1101::~header_format_cc1101()
{
}
...
anyone has an idea ?
thanks
bob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOT how to write my own custom header format
hi
i solved the previous error i forgot to overload a method
the nm -C -u gave my an unknown symbol so i could see the problem
now i have another error
grc is happy with my header_format instance but when i launch i get a
runtime error
Traceback (most recent call last):
File "/home/alban/gnuradio/top_block.py", line 124, in
main()
File "/home/alban/gnuradio/top_block.py", line 112, in main
tb = top_block_cls()
File "/home/alban/gnuradio/top_block.py", line 74, in __init__
self.digital_protocol_formatter_async_0 =
digital.protocol_formatter_async(hdr_format)
File "/usr/lib/python2.7/dist-packages/gnuradio/digital/digital_swig2.py",
line 1242, in make
return _digital_swig2.protocol_formatter_async_make(format)
TypeError: in method 'protocol_formatter_async_make', argument 1 of
type 'gr::digital::header_format_base::sptr const &'
i don't understand
i my class déclaration i expect a std::string as a parameter of the constructor
class F4GSW_API header_format_cc1101
: public digital::header_format_base
{
public:
header_format_cc1101(const std::string _code, int
threshold,int bps);
~header_format_cc1101();
why python throws me this error ?
Le dim. 20 janv. 2019 à 10:59, Alban Meffre a écrit :
>
>
> Hi all
> i placed an import block into grc but i still get this error
>
> Param - Value(value):
> Value
> "f4gsw.header_format_cc1101(digital.packet_utils.default_access_code, 1)"
> cannot be evaluated:
> 'module' object has no attribute 'header_format_cc1101'
>
> i created the module f4gsw and i added the header_format_cc1101 derived from
> header_format_base, with the "noblock" profile. i removed the xml file
> installation in the cmakelist file of the grc folder
>
> i can import f4gsw in python but there is no header_format_cc1101 member in
> the module
>
> thanks for your support
> bob
--
Alban MEFFRE F4GSW
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OOT how to write my own custom header format
Hi all i placed an import block into grc but i still get this error Param - Value(value): Value "f4gsw.header_format_cc1101(digital.packet_utils.default_access_code, 1)" cannot be evaluated: 'module' object has no attribute 'header_format_cc1101' i created the module f4gsw and i added the header_format_cc1101 derived from header_format_base, with the "noblock" profile. i removed the xml file installation in the cmakelist file of the grc folder i can import f4gsw in python but there is no header_format_cc1101 member in the module thanks for your support bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: OOT how to write my own custom header format
Hi i wrote a child class by hand i managed to compile successfully using the commands below : cmake .. make gr_modtool makexml header_format_cc1101 (no suitable file found because there is no _impl.cc file) sudo make install sudo ldconfig but my module is not detected in grc Param - Value(value): Value "f4gsw.header_format_cc1101(digital.packet_utils.default_access_code, 3, Const_PLD.bits_per_symbol())" cannot be evaluated: name 'f4gsw' is not defined thanks bob -- Forwarded message ----- From: Alban Meffre Date: sam. 19 janv. 2019 à 22:04 Subject: OOT how to write my own custom header format To: GNURadio Discussion List hi all i'm trying to derive the header_format_base with no success i created a new module with modtool and the "no block" profile i copied and modified the "header_format_default" sources but i get swig error telling me that sptr is not defined did someone ever managed to write its own header format with modtool ? is modtool the way to go ? which modtool profile do i need to use ? do you have some hints for doing so ? i can read and write (kind of) some C++ code but i do not know anything about SWIG. that is black magic for me, so please i would be glad if someone explain me step by step ;) thank you all bob -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OOT how to write my own custom header format
hi all i'm trying to derive the header_format_base with no success i created a new module with modtool and the "no block" profile i copied and modified the "header_format_default" sources but i get swig error telling me that sptr is not defined did someone ever managed to write its own header format with modtool ? is modtool the way to go ? which modtool profile do i need to use ? do you have some hints for doing so ? i can read and write (kind of) some C++ code but i do not know anything about SWIG. that is black magic for me, so please i would be glad if someone explain me step by step ;) thank you all bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length
Hi i spent the past few weeks studying the gnuradio blocks c++ source codes, the doxygen documentation, and the provided examples (specially packet_tx and packet_rx ones) and eventually i managed to understand how packetized transmission, tags and messages work it was easer than i thought initially even if the learning curve is very steep many thanks for your support now i plan to learn how to write my own blocks based on the existing, using gr_modtool i need to write my own custom header formats bob Le lun. 31 déc. 2018 à 01:28, Julian Arnold a écrit : > Hey Bob, > > there is plenty of documentation on this topic you can check out under > [1,2]. > Especially, the Header Payload Demuxer (HPD) [3] should be worth a look > if you are dealing with packetized variable length data. > > Hope those pointer can get you started. If you have further questions > after going through those pages, let me know. > > Cheers, > Julian > > [1] https://www.gnuradio.org/doc/doxygen/page_packet_data.html > [2] https://www.gnuradio.org/doc/doxygen/page_packet_comms.html > [3] > > https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__payload__demux.html > > On 31.12.18 01:00, Alban Meffre wrote: > > Hi > > I would like to decode a simple GFSK packet > > > > here is the packet structure : > > preamble : AAh x 4 > > sync word : D391h > > length byte : 1 byte > > payload : 1 to 64 bytes > > CRC : 2 bytes > > > > TX : arduino + CC1101 module, 2GFSK, 100kbps, excursion 50kHz, carrier > > 433 MHz > > RX : RTLSDR > > > > until now i was able to demodulate the signal and add a "sync" tag using > > the correlate access code. > > > > my goal is to extract the payload and send it to a file or a socket. > > is there a simple way to do that without writing my own block ? > > > > i can't go further, because i do not manage to find the info i need > > i do not know where to start : stream, tagged stream, PDU, messages, > etc.. > > i do not figure out how to use these tag for variable length. nothing > > clear in the doc > > > > i'd be glad if someone helps me > > best regards > > bob > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Encrypted RF Noise, Guerrilla Private and Pirate Comms, UWB Ultra Wide Band, SS Spread Spectrum, SDR
hi all undetected : high rate spread spectrum, low power unjammable : frequency hoping, long codes with FEC, narrow bandwidth modulation, low bitrate, long range unreadable : robust encryption with anti replay protection, pseudo random generated FH and SS with strong key do you know LORA ? maybe this could suit your needs https://www.google.fr/search?q=lora+esp32+arduino=lnms=X=0ahUKEwjZkZy-3-rfAhVJThoKHZSbAt4Q_AUICSgA=1440=741=2 bob Le dim. 13 janv. 2019 à 10:10, grarpamp a écrit : > This was mentioned in a whitepaper of sorts, > maybe in a few papers around that time, > noting that the tech might perhaps be ideal for > Anti-Censorship / Anti-Surveillance / Guerrilla > Comms that need to be robust against generally > all forms of traditional radio adversaries. > > Can anyone post links to such papers? > > And what links are there to software and hardware > modules that can be plugged in for experimentation, > and or joined for further development? > > Recollection provides only concept hints, > pasted in below from various. Thanks. > > > > Probably also coming soon, very high PGs wherein the codes, bandwidth and > > frequencies quickly hop according to a shared secret. > > This combination is being explored for possible Next > > Generation military comms. > > It is said that this is already in public knowledge and operation > within SDR community. > > Though instead of the conventional "bandwidth and frequencies", > all the observer sees on their spectrum is random noise, let's say > across entire spectral ranges... from start freq to end freq of entire > frequency range of ATSC / WiFi / Cellular / FM / Etc allocation > space... more generally, across entire start to end of whatever > capability range of the tx / rx hardware in use. And where a > pre shared or negotiated key is used to impart or mask > data into, and out of, the noise. It's not even that these may > have, or be, waveform carriers, as the noise may be spark > gaps driven, impulse / transform function generators, etc. > One might not even have to generate their own noise, > perhaps the RF key could simply be used as filter > to existing noise. > > And the difficulty in triangulating such noise if so, > ie: how exactly does one lock onto random energy, > the galactic radiation problem, from everywhere > and nowhere. > > The concept is that the RF as roughly described in > whatever paper cannot be jammed or DOS'd... your RF > would appear as noise to all but those holding the RF > spectrum noise key, so the only way to jam it, if you > even knew it was in use in the first place (say by noting > an overall spectrum power bump) would be to raise the > noise floor by emitting... you guessed it, random noise... > which would wipe out the S/N dB's you need for your > own comms be they traditional AM / FM / etc, or this > keyed noise tech. So you'd end up in a mutually > assured destruction, essentially who can throw > more power in the air. You'd probably be able to get > more local power up, hop by hop, than a wide area > adversary tying to blanket you, so you'd win. > Assuming you needed to tx anything instead > of just filtering. > > You need the RF noise key to cipher the RF, > so the underlying data packets are always > secure and unaffected by the above. Data would > be affected by nodes that are involved in the > data layer, before it gets pushed up to or down > from RF. That's a trusted evil maid problem and > thus out of scope. > > > https://lists.cpunks.org/pipermail/cypherpunks/2016-February/027605.html > > previous discussions have suggested MIMO for beam forming / phased array > signal emission that lets you do fancy things, like emulate a moving > transmitter. if the transmitter appears to be constantly moving, it's a > much harder target > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP with "packet header parser"
hi
i does not work because the packet header parser expect an
"packet_header_default" object instead of a "header_format_base" object
bob
Le dim. 6 janv. 2019 à 02:50, Cinaed Simson a
écrit :
> On 1/5/19 2:26 PM, Alban Meffre wrote:
> > ok sorry my mistake i got "packet_header_default" and
> > "header_format_default" mixed up
> > bob
>
> The error message at the bottom indicates the wrong number arguments.
>
> digital.header_format_default('1101001110010001', 0)
>
> Try
>
> digital.header_format_default('1101001110010001', 0, bps)
>
> where bps is the number of bits per symbol for your problem.
>
> See
>
>Default Header Format Obj.
>
> in the grc.
>
> -- Cinaed
>
>
>
>
> >
> > Le sam. 5 janv. 2019 à 22:13, Alban Meffre > <mailto:fox4...@gmail.com>> a écrit :
> >
> > hi all
> >
> > i try to figure out how to use the "packet header parser" block
> > as a formatter i use
> > "digital.header_format_default('1101001110010001', 0)"
> >
> > when i launch i get the error
> > "
> > Traceback (most recent call last):
> > File "/Users/alban/gnuradio/top_block.py", line 146, in
> > main()
> > File "/Users/alban/gnuradio/top_block.py", line 134, in main
> > tb = top_block_cls()
> > File "/Users/alban/gnuradio/top_block.py", line 71, in __init__
> > self.digital_packet_headerparser_b_0 =
> > digital.packet_headerparser_b(hdr_format_dec_0)
> > File
> >
>
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/digital/digital_swig2.py",
> > line 2651, in make
> > return _digital_swig2.packet_headerparser_b_make(*args)
> > NotImplementedError: Wrong number or type of arguments for
> > overloaded function 'packet_headerparser_b_make'.
> > Possible C/C++ prototypes are:
> >
> >
>
> gr::digital::packet_headerparser_b::make(gr::digital::packet_header_default::sptr
> > const &)
> > gr::digital::packet_headerparser_b::make(long,std::string const
> &)
> > "
> >
> >
> > in the "rx_ofdm" example supplied with gnuradio, the "packet header
> > parser" use the formatter "header_formatter.base()"
> >
> > i do not find any documentation about the base() method
> > as you can see the doxygen is empty
> >
> https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__format__base.html#a5a7b2939707146f2b28d7e91e04103c2
> >
> > if i add ".base()" to the formatter in my top_block i get an error
> too
> >
> > please someone can explain me hox to use this block ?
> > thank you all
> > --
> > Alban MEFFRE F4GSW
> >
> >
> >
> >
> > --
> > Alban MEFFRE F4GSW
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
--
Alban MEFFRE F4GSW
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP with "packet header parser"
ok sorry my mistake i got "packet_header_default" and
"header_format_default" mixed up
bob
Le sam. 5 janv. 2019 à 22:13, Alban Meffre a écrit :
> hi all
>
> i try to figure out how to use the "packet header parser" block
> as a formatter i use
> "digital.header_format_default('1101001110010001', 0)"
>
> when i launch i get the error
> "
> Traceback (most recent call last):
> File "/Users/alban/gnuradio/top_block.py", line 146, in
> main()
> File "/Users/alban/gnuradio/top_block.py", line 134, in main
> tb = top_block_cls()
> File "/Users/alban/gnuradio/top_block.py", line 71, in __init__
> self.digital_packet_headerparser_b_0 =
> digital.packet_headerparser_b(hdr_format_dec_0)
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/digital/digital_swig2.py",
> line 2651, in make
> return _digital_swig2.packet_headerparser_b_make(*args)
> NotImplementedError: Wrong number or type of arguments for overloaded
> function 'packet_headerparser_b_make'.
> Possible C/C++ prototypes are:
>
> gr::digital::packet_headerparser_b::make(gr::digital::packet_header_default::sptr
> const &)
> gr::digital::packet_headerparser_b::make(long,std::string const &)
> "
>
>
> in the "rx_ofdm" example supplied with gnuradio, the "packet header
> parser" use the formatter "header_formatter.base()"
>
> i do not find any documentation about the base() method
> as you can see the doxygen is empty
>
> https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__format__base.html#a5a7b2939707146f2b28d7e91e04103c2
>
> if i add ".base()" to the formatter in my top_block i get an error too
>
> please someone can explain me hox to use this block ?
> thank you all
> --
> Alban MEFFRE F4GSW
>
>
>
--
Alban MEFFRE F4GSW
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HELP with "packet header parser"
hi all
i try to figure out how to use the "packet header parser" block
as a formatter i use
"digital.header_format_default('1101001110010001', 0)"
when i launch i get the error
"
Traceback (most recent call last):
File "/Users/alban/gnuradio/top_block.py", line 146, in
main()
File "/Users/alban/gnuradio/top_block.py", line 134, in main
tb = top_block_cls()
File "/Users/alban/gnuradio/top_block.py", line 71, in __init__
self.digital_packet_headerparser_b_0 =
digital.packet_headerparser_b(hdr_format_dec_0)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/digital/digital_swig2.py",
line 2651, in make
return _digital_swig2.packet_headerparser_b_make(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function 'packet_headerparser_b_make'.
Possible C/C++ prototypes are:
gr::digital::packet_headerparser_b::make(gr::digital::packet_header_default::sptr
const &)
gr::digital::packet_headerparser_b::make(long,std::string const &)
"
in the "rx_ofdm" example supplied with gnuradio, the "packet header
parser" use the formatter "header_formatter.base()"
i do not find any documentation about the base() method
as you can see the doxygen is empty
https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__format__base.html#a5a7b2939707146f2b28d7e91e04103c2
if i add ".base()" to the formatter in my top_block i get an error too
please someone can explain me hox to use this block ?
thank you all
--
Alban MEFFRE F4GSW
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] formatter object creation for CC1101 decoding
hi all i would like to define my own format for decoding CC1101 packets sync word : d391h packet length : 1 byte can i easily derive the header_format_base in python and add it in my top block or do i need to write C++ code and recompile gnuradio ? thanks -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length
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 [image: image.png] Bob Le mar. 1 janv. 2019 à 19:01, Kevin McQuiggin 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, > > Kevin > > > > > On Jan 1, 2019, at 9:53 AM, Alban Meffre 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 decoding > i will try do decode the documentation > > very best regards, > Bob > > > Le mar. 1 janv. 2019 à 11:21, Daniel Estévez 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > -- > Alban MEFFRE F4GSW > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length
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 decoding i will try do decode the documentation [image: image.png] very best regards, Bob Le mar. 1 janv. 2019 à 11:21, Daniel Estévez 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alban MEFFRE F4GSW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CC1101 GFSK packet decode with variable length
Hi I would like to decode a simple GFSK packet here is the packet structure : preamble : AAh x 4 sync word : D391h length byte : 1 byte payload : 1 to 64 bytes CRC : 2 bytes TX : arduino + CC1101 module, 2GFSK, 100kbps, excursion 50kHz, carrier 433 MHz RX : RTLSDR until now i was able to demodulate the signal and add a "sync" tag using the correlate access code. my goal is to extract the payload and send it to a file or a socket. is there a simple way to do that without writing my own block ? i can't go further, because i do not manage to find the info i need i do not know where to start : stream, tagged stream, PDU, messages, etc.. i do not figure out how to use these tag for variable length. nothing clear in the doc i'd be glad if someone helps me best regards bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
