PDU - cdr format

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
Does the cdr part of the PDU has to be a PMT uniform vector? What if I want
to fill the cdr with string type of data?

Message Debug - printing in ASCII mode

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Community,
I am following tutorial about Packet Communications
 and I am
able to replicate all steps but one where the Message Debug block prints
the message in verbose mode. I don't see this mode in my configuration. I
see the output as numbers not letters. Has the verbose mode been disabled
in GNU Radio 3.9.3 ?
Thanks in advance
Marcin

Re: PDU - cdr format

[jacob]

A PDU is a special type of PMT pair object that consists of a PMT Dictionary 
(of metadata) and a PMT Uniform Vector (of data). This is defined as such to 
make operating on PDU type data somewhat standardized.

Depending on what you are actually trying to do you have a few options. If the 
string is metadata you can add it to the PMT metadata dictionary; if the string 
_is_ the data, you can save the encoded text values as a U8 uniform vector.

Jacob

‐‐‐ Original Message ‐‐‐
On Thursday, February 3rd, 2022 at 2:28 AM, Marcin Puchlik via "GNU Radio, the 
Free & Open-Source Toolkit for Software Radio"  wrote:

> Hi Community,
> Does the cdr part of the PDU has to be a PMT uniform vector? What if I want 
> to fill the cdr with string type of data?

Re: PDU - cdr format

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Hi Jacob,
Assuming that data are encoded text values how to print it as a test using
Message Debug block? My goal is to print the data in the console.

czw., 3 lut 2022 o 14:34 jacob  napisał(a):

> A PDU is a special type of PMT pair object that consists of a PMT
> Dictionary (of metadata) and a PMT Uniform Vector (of data). This is
> defined as such to make operating on PDU type data somewhat standardized.
>
> Depending on what you are actually trying to do you have a few options. If
> the string is metadata you can add it to the PMT metadata dictionary; if
> the string _is_ the data, you can save the encoded text values as a U8
> uniform vector.
>
> Jacob
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, February 3rd, 2022 at 2:28 AM, Marcin Puchlik via "GNU Radio,
> the Free & Open-Source Toolkit for Software Radio" <
> discuss-gnuradio@gnu.org> wrote:
>
> Hi Community,
> Does the cdr part of the PDU has to be a PMT uniform vector? What if I
> want to fill the cdr with string type of data?
>
>
>
>
>

Re: Here's how to get the N321's LO sharing to work in GNURadio 3.9 with UHD4.1.0.5

[Paul Atreides]

Hey Daniel. 
Glad you like it. The functionality is there for now, but I have some 
reservations about recommending this for upstream. 
TLDR: more work probly needs to be done for the changes to be stable. 

My suggestions/concerns on upstream changes are as follows:

1) If the file system naming convention changes in new versions of UHD my 
function will break in gr-uhd since the file system path is hardcoded. As 
you’ve probly noticed UHD abstracts the various fs paths into variables so 
changes to the fs are transparent to the API. 

2) my changes need to follow the naming convention and abstraction of gr-uhd. 
For example, any functions that exist for both TX and RX are put in the common 
block and then the same function is used for TX/RX in either sink or source 
blocks respectively. 

3) I think adding LO distribution as a parameter in the GRC block would also be 
necessary to follow have “GNURadio citizenship”. 

I honestly like the direction of your solution more because it follows the API 
interplay that’s already in place between UHD and gr-UHD. Unfortunately, as you 
pointed out it would require the modifications to be a upstreamed for both UHD 
and gr-uhd. 

I think I could handle the gr-uhd part if the UHD side gets done. 
Does anyone from Ettus think this would be a valuable addition? Could we get 
some help on adding a convenience function for LO distribution board enable to 
the UHD API?



> On Jan 29, 2022, at 04:46, Daniel Estévez  wrote:
> 
> Hi,
> 
> Thanks! That seems very nice. Could we try upstreaming this? I don't see any 
> obvious drawbacks to having this in-tree, particularly since your approach 
> doesn't require modifying UHD.
> 
> Best,
> Daniel.
> 
>> El 28/1/22 a las 23:55, Paul Atreides escribió:
>> Currently there's no way to use LO sharing with the N321 in gr-uhd.
>> The N321 uses an RF Distribution board which has port terminations that need 
>> to be switched to active outputs when the LO is exported. This isn't 
>> accessible in gr-uhd.
>> In order to access the LO distribution enable commands shown here:
>> https://kb.ettus.com/USRP_N320/N321_LO_Distribution#UHD_LO_Distribution_Commands
>>  
>> 
>> a function needs to be added to gr-uhd
>> All this code below is taken from here:
>> https://github.com/daniestevez/uhd/commit/0a6da1a3fd5839b862cac740ed702923ed21b096
>>  
>> 
>> https://github.com/daniestevez/gnuradio/commit/f9909bade86045f379f83001de27317cc261807f
>>  
>> 
>> with the rx switched for tx and source switched for sink
>> i also did not modify any UHD code making this a fix that requires ONLY 
>> modifying gr-uhd
>> usrp_sink_impl.cc
>> voidusrp_sink_impl::set_tx_lo_dist(boolenabled,
>> conststd::string&name,
>> size_tchan)
>> {
>> #ifdefUHD_USRP_MULTI_USRP_TX_LO_CONFIG_API
>> _dev->get_tree()->access("/blocks/0/Radio#0/dboard/tx_frontends/0/los/lo1/lo_distribution"/::uhd::fs_path(name)
>>  /"export").set(enabled);
>> #else
>> throwstd::runtime_error("not implemented in this version");
>> #endif
>> }
>> usrp_sink_impl.h
>> voidset_tx_lo_dist(boolenabled,
>> conststd::string&name, size_tchan= 0) override;
>> usrp_sink.h
>> virtualvoidset_tx_lo_dist(boolenabled, conststd::string&name, size_tchan=0) 
>> = 0;
>> usrp_sink_python.cc
>> .def("set_tx_lo_dist",
>> &usrp_sink::set_tx_lo_dist,
>> py::arg("enabled"),
>> py::arg("name"),
>> py::arg("chan") =0,
>> D(usrp_sink, set_tx_lo_dist))
>> usrp_sink_pydoc_template.h
>> staticconstchar* __doc_gr_uhd_usrp_sink_set_tx_lo_dist= R"doc()doc";
>> Assuming the sink block is "usrp_sink_0"
>> snippet_0 code
>> 'Main-After Init'
>> # Turn on the ports
>> self.usrp_sink_0.set_tx_lo_dist(True,"LO_OUT_0",0)
>> # repeat the above for all ports needed "LO_OUT_"
>> snippet_1
>> 'Main-After Stop'
>> # Turn off the ports
>> self.usrp_sink_0.set_tx_lo_dist(False,"LO_OUT_0",0)
>> # repeat for all ports you enabled "LO_OUT_"
>> The other settings i found were needed in the gr-uhd block included:
>> Setting the start time to 1
>> Setting the Master Clock rate to 200MHz
>> CH0:
>>   LO Source = external
>>   LO Export = True
>> CH1:
>>   LO Source = external
>>   LO Export = False
>> I'd like to thank the community of users for doing all of this work, 
>> especially Marcus Leech, Rob Kossler and Daniel Estevez
> 

reading rfm69 packet transmission

[Chris Gorman]

Hello All,

I have two rfm69 boards [1] connected to two avrs and they are sending
messages to each other over the airway.  Once I got this working I
thought it would be fun to inspect the messages being sent with my
rtl_sdr.  I can confirm the message is being sent over serial on the
receiver.

I went searching on the internet for a way to decode the transmission
and found some scripts to use gnuradio to do packetdemod on rfm69
boards [2].  The problem with this setup is it requires me to modify
the code to the rfm69 [3] to prevent whitening.  My software to run
the avrs isn't the same as the author of the packetdemod's and I can't
apply his patch.  I have looked at the code to see if I am using
whitening, but as far as I can tell I am not.  Regardless when I run
the packetdemod script, I get 'Invalid packets" instead of my message.

In my inbox this morning I found an email with a reference to packet
communications with gnuradio [4] and am wondering if I should be using
this method to decode the transmission between the two rfm69's?  I
will try it out anyway as it seems interesting, but is this the
correct direction to analyze the transmission between two boards like
the rfm69s?

Thanks in advance,

Chris

[1] https://www.sparkfun.com/products/12775
[2] https://github.com/fermitron2048/packetdemod
[3] https://github.com/nayem-cosmic/RFM69-Library-AVR
[4] https://wiki.gnuradio.org/index.php?title=Packet_Communications