Re: GRC 3.9.4.0 - module porting problem

2022-03-04 Thread Ryan Volz

Hi David,

If it works somewhere with GR 3.9, then it's not a porting problem and you've 
done everything right there.

I've recently discovered for myself that an OOT's Python bindings will throw this error 
when even the compiler version is different between building GNU Radio and the OOT, in 
addition to needing the same pybind11 version. Is there a chance this is what you're 
seeing? Run "gnuradio-config-info --cxx" to see what compiler GNU Radio was 
built with, and compare with what you're using to build the OOT module.

(For me, this has happened in building OOT modules for conda-forge when the 
conda-forge project recently started using GCC 10 instead of GCC 9. Modules 
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It 
turns out that they actually would be compatible, and pybind11 is being too 
careful, but I would have had to know that ahead of time to avoid the problem. 
So for now I have to stick to the same compiler version for everything.)

Cheers,
Ryan

On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:

Hi All,
I am sorry to be covering what is old ground, but I am having a final loading 
issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another computer 
without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown base type 
"gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module 
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block imports 
correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting the 
changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block classes 
noted in the porting guide automatically inserted during bind in 
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
     using channel_signal_generator_cc    = 
::gr::oot::channel_signal_generator_cc;
     py::class_>(m, "channel_signal_generator_cc", 
D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
     )
Any comments would be welcome.
Many thanks,
David GD4FMB




GRC 3.9.4.0 - module porting problem

2022-03-04 Thread David Taylor (manx.net)
Hi All,

I am sorry to be covering what is old ground, but I am having a final loading 
issue with an otherwise working OOT block.

The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another computer 
without issue.

ImportError:generic_type "channel_signal_generator_cc" referenced unknown base 
type "gr::sync_block"

Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module 
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block imports 
correctly with no changes necessary to the .yml file.

The new block was created using 3.9 gr_modtool and code dropped in, noting the 
changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block classes 
noted in the porting guide automatically inserted during bind in 
/python/bindings/

void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc= 
::gr::oot::channel_signal_generator_cc;

py::class_>(m, 
"channel_signal_generator_cc", D(channel_signal_generator_cc))

.def(py::init(&channel_signal_generator_cc::make),
   py::arg("samp_rate"),
   py::arg("length_chips"),
   py::arg("duration_sec"),
   py::arg("filename"),
   py::arg("CN0_dB"),
   D(channel_signal_generator_cc,make)
)

Any comments would be welcome.

Many thanks,

David GD4FMB


Re: N210 DAC and ADC usage

2022-03-04 Thread Marcus D Leech
See here for the schematics which will help you find the full specs for the AUX 
ADC and DAC. 

https://files.ettus.com/schematics/n200/

Yes you can certainly modify the FPGA and UHD to support these. But you’ll 
mostly be on your own. 

Sent from my iPhone

> On Mar 4, 2022, at 9:35 AM, Fabien PELLET  wrote:
> 
> Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are 
> replicated from the motherboard.
> 
> I already use IO which works very well. So there is no way to send samples 
> (or receive) at a specific sample rate using that AUX_DAC or ADC. It is just 
> some "analog IOs" for reading some external sensors for example if I 
> understand well what you wrote.
> 
> What are the specifications of that AUX ?
> 
> Using a specifique FPGA firmware and custom UHD library, would it be possible 
> to transform them as GR source or sink ?
> 
> Thanks,
> 
> Best regards,
> 
> Fabien, F4CTZ.
> 
>> Le 04/03/2022 à 14:35, Marcus Müller a écrit :
>> Sorry, hit "send" accidentally:
>> 
>> Dear Fabien,
>> 
>> there's no ADC on these daughterboards. Just an EEPROM for identification, 
>> opamps for amplification and signal conditioning, and on the LFTX a 
>> switch-mode power supply. You're right, they do exppose the AUX DACs and ADC 
>> lines from the motherboad.
>> 
>> However, these are without further ado not accessible from UHD, and thus 
>> also not from GNU Radio. Some daughterboard drivers use them.
>> 
>> I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` 
>> might show properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the 
>> idea). You can use get_device() on your USRP blocks and access theses 
>> properties from your GNU Radio program (from C++), but it's not really an 
>> API – more an exposing of intestines...
>> 
>> Best regards,
>> Marcus
>> 
>>> On 04.03.22 14:30, Marcus Müller wrote:
>>> Dear Fabien,
>>> 
>>> there's no ADC on these daughterboards. Just an EEPROM for identification, 
>>> opamps for amplification and signal conditioning, and on the LFTX a 
>>> switch-mode power supply.
>>> 
>>> Best regards,
>>> Marcus
>>> 
>>> On 04.03.22 10:30, Fabien PELLET wrote:
 Hello,
 
 As there are IOs available on LFTX and LFRX, there are also ADC and DAC 
 available.
 
 Is there a way to use them as SOURCE and SINK in gnuradio for low speed 
 conversion ?
 
 Thanks,
 
 Best regards,
 
 Fabien, F4CTZ.
 
 
>> 
> 


Re: N210 DAC and ADC usage

2022-03-04 Thread Fabien PELLET
Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are 
replicated from the motherboard.


I already use IO which works very well. So there is no way to send 
samples (or receive) at a specific sample rate using that AUX_DAC or 
ADC. It is just some "analog IOs" for reading some external sensors for 
example if I understand well what you wrote.


What are the specifications of that AUX ?

Using a specifique FPGA firmware and custom UHD library, would it be 
possible to transform them as GR source or sink ?


Thanks,

Best regards,

Fabien, F4CTZ.

Le 04/03/2022 à 14:35, Marcus Müller a écrit :

Sorry, hit "send" accidentally:

Dear Fabien,

there's no ADC on these daughterboards. Just an EEPROM for 
identification, opamps for amplification and signal conditioning, and 
on the LFTX a switch-mode power supply. You're right, they do exppose 
the AUX DACs and ADC lines from the motherboad.


However, these are without further ado not accessible from UHD, and 
thus also not from GNU Radio. Some daughterboard drivers use them.


I'm not sure UHD exposes them in all version, but `uhd_usrp_probe 
--tree` might show properties called "AUX_DAC_A" (or _B, or 
AUX_ADC_.., you get the idea). You can use get_device() on your USRP 
blocks and access theses properties from your GNU Radio program (from 
C++), but it's not really an API – more an exposing of intestines...


Best regards,
Marcus

On 04.03.22 14:30, Marcus Müller wrote:

Dear Fabien,

there's no ADC on these daughterboards. Just an EEPROM for 
identification, opamps for amplification and signal conditioning, and 
on the LFTX a switch-mode power supply.


Best regards,
Marcus

On 04.03.22 10:30, Fabien PELLET wrote:

Hello,

As there are IOs available on LFTX and LFRX, there are also ADC and 
DAC available.


Is there a way to use them as SOURCE and SINK in gnuradio for low 
speed conversion ?


Thanks,

Best regards,

Fabien, F4CTZ.








Re: N210 DAC and ADC usage

2022-03-04 Thread Marcus Müller

Sorry, hit "send" accidentally:

Dear Fabien,

there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for 
amplification and signal conditioning, and on the LFTX a switch-mode power supply. You're 
right, they do exppose the AUX DACs and ADC lines from the motherboad.


However, these are without further ado not accessible from UHD, and thus also not from GNU 
Radio. Some daughterboard drivers use them.


I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` might show 
properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the idea). You can use 
get_device() on your USRP blocks and access theses properties from your GNU Radio program 
(from C++), but it's not really an API – more an exposing of intestines...


Best regards,
Marcus

On 04.03.22 14:30, Marcus Müller wrote:

Dear Fabien,

there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for 
amplification and signal conditioning, and on the LFTX a switch-mode power supply.


Best regards,
Marcus

On 04.03.22 10:30, Fabien PELLET wrote:

Hello,

As there are IOs available on LFTX and LFRX, there are also ADC and DAC 
available.

Is there a way to use them as SOURCE and SINK in gnuradio for low speed 
conversion ?

Thanks,

Best regards,

Fabien, F4CTZ.






Re: N210 DAC and ADC usage

2022-03-04 Thread Marcus Müller

Dear Fabien,

there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for 
amplification and signal conditioning, and on the LFTX a switch-mode power supply.


Best regards,
Marcus

On 04.03.22 10:30, Fabien PELLET wrote:

Hello,

As there are IOs available on LFTX and LFRX, there are also ADC and DAC 
available.

Is there a way to use them as SOURCE and SINK in gnuradio for low speed 
conversion ?

Thanks,

Best regards,

Fabien, F4CTZ.






Re: RX/TX switching

2022-03-04 Thread Fabien PELLET
I'm actually on 3.9.5 but I will investigate on the PDUs to know if it 
could help me.


RX and TX period are completly random  from hundreds of milliseconds to 
several seconds.


Thanks for your help,

Best regards,

Fabien, F4CTZ.

Le 04/03/2022 à 13:31, Johannes Demel a écrit :

Hi Fabien,

Personally, I use PDUs to control when TX starts. GR 3.10 integrated a 
lot more of these.

https://github.com/gnuradio/gnuradio/tree/main/gr-pdu
Besides, the gr-pdu_utils OOT might be a good reference.
https://github.com/sandialabs/gr-pdu_utils
It mentions SOB/EOB in their docs.
EOB is required to signal that a burst ends. I'm not sure if a SOB is 
really required or if a USRP would just "wake up" and start transmitting.


I suggested the SOB/EOB mechanism because it sounds like you transmit 
long bursts. Short bursts might be handled via tagged streams. The UHD 
sink would handle these cases. By short bursts I mean <=4k complex 
samples.


Generally, the idea is: trigger transmission with a PDU block, use a 
PDU to tagged stream block to fead you data into the GR streaming 
interface. Then make sure to signal to the UHD sink when a burst ends.


Cheers
Johannes

On 04.03.22 12:50, Fabien PELLET wrote:

Hi Johannes,

Yes this is exactly my problem : after unlocking the flowgraph, I get 
some underruns (only, no overrun).


Do you have an example of code using EOB/SOB ? Ok for sending EOB 
before locking but is it necessary to send a SOB also and when ?


Your suggestion of idling the TX flowgraph is something I looked for 
during several days but I never found how. Indeed, if I do not 
connect a source and a sink at each ends, gnuradio will fail to run. 
How to stop feeding one branch of a flowgraph ? Do you have examples 
of codes for doing that ?


Thanks for your help,

Fabien, F4CTZ.

Le 04/03/2022 à 12:03, Johannes Demel a écrit :

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to 
RX or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending 
an EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. 
You can just stop the TX flowgraph portion while you don't need it. 
By stop I mean, the flowgraph is not fed any new samples and just 
idles.
As an added bonus, you minimize LO leakage which might be an issue 
for your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm 
using a USRP N210. When I'm in RX, the TX chain is connected to a 
constant zero source and feed a null sink and the RX chain is 
connected to USRP source and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for 
switching speed purpose and do not have to stop the flowgraph and 
restart it. So for my switching, I just lock the top block and 
unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My 
problem is that when I lock and unlock the flowgraph, I get a lot 
of underruns.


As a test, I remove the TX part of my flowgraph and only keep the 
RX part and I try do some lock/unlock sometimes : same problem with 
underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.












Re: RX/TX switching

2022-03-04 Thread Johannes Demel

Hi Fabien,

Personally, I use PDUs to control when TX starts. GR 3.10 integrated a 
lot more of these.

https://github.com/gnuradio/gnuradio/tree/main/gr-pdu
Besides, the gr-pdu_utils OOT might be a good reference.
https://github.com/sandialabs/gr-pdu_utils
It mentions SOB/EOB in their docs.
EOB is required to signal that a burst ends. I'm not sure if a SOB is 
really required or if a USRP would just "wake up" and start transmitting.


I suggested the SOB/EOB mechanism because it sounds like you transmit 
long bursts. Short bursts might be handled via tagged streams. The UHD 
sink would handle these cases. By short bursts I mean <=4k complex samples.


Generally, the idea is: trigger transmission with a PDU block, use a PDU 
to tagged stream block to fead you data into the GR streaming interface. 
Then make sure to signal to the UHD sink when a burst ends.


Cheers
Johannes

On 04.03.22 12:50, Fabien PELLET wrote:

Hi Johannes,

Yes this is exactly my problem : after unlocking the flowgraph, I get 
some underruns (only, no overrun).


Do you have an example of code using EOB/SOB ? Ok for sending EOB before 
locking but is it necessary to send a SOB also and when ?


Your suggestion of idling the TX flowgraph is something I looked for 
during several days but I never found how. Indeed, if I do not connect a 
source and a sink at each ends, gnuradio will fail to run. How to stop 
feeding one branch of a flowgraph ? Do you have examples of codes for 
doing that ?


Thanks for your help,

Fabien, F4CTZ.

Le 04/03/2022 à 12:03, Johannes Demel a écrit :

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to 
RX or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending 
an EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. 
You can just stop the TX flowgraph portion while you don't need it. By 
stop I mean, the flowgraph is not fed any new samples and just idles.
As an added bonus, you minimize LO leakage which might be an issue for 
your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using 
a USRP N210. When I'm in RX, the TX chain is connected to a constant 
zero source and feed a null sink and the RX chain is connected to 
USRP source and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. 
So for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My 
problem is that when I lock and unlock the flowgraph, I get a lot of 
underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with 
underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.










Re: RX/TX switching

2022-03-04 Thread Fabien PELLET

Hi Johannes,

Yes this is exactly my problem : after unlocking the flowgraph, I get 
some underruns (only, no overrun).


Do you have an example of code using EOB/SOB ? Ok for sending EOB before 
locking but is it necessary to send a SOB also and when ?


Your suggestion of idling the TX flowgraph is something I looked for 
during several days but I never found how. Indeed, if I do not connect a 
source and a sink at each ends, gnuradio will fail to run. How to stop 
feeding one branch of a flowgraph ? Do you have examples of codes for 
doing that ?


Thanks for your help,

Fabien, F4CTZ.

Le 04/03/2022 à 12:03, Johannes Demel a écrit :

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to 
RX or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending 
an EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. 
You can just stop the TX flowgraph portion while you don't need it. By 
stop I mean, the flowgraph is not fed any new samples and just idles.
As an added bonus, you minimize LO leakage which might be an issue for 
your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using 
a USRP N210. When I'm in RX, the TX chain is connected to a constant 
zero source and feed a null sink and the RX chain is connected to 
USRP source and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. 
So for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My 
problem is that when I lock and unlock the flowgraph, I get a lot of 
underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with 
underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.








Re: RX/TX switching

2022-03-04 Thread Johannes Demel

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to RX 
or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending an 
EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. You 
can just stop the TX flowgraph portion while you don't need it. By stop 
I mean, the flowgraph is not fed any new samples and just idles.
As an added bonus, you minimize LO leakage which might be an issue for 
your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using a 
USRP N210. When I'm in RX, the TX chain is connected to a constant zero 
source and feed a null sink and the RX chain is connected to USRP source 
and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. So 
for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My problem 
is that when I lock and unlock the flowgraph, I get a lot of underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.






RX/TX switching

2022-03-04 Thread Fabien PELLET

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using a 
USRP N210. When I'm in RX, the TX chain is connected to a constant zero 
source and feed a null sink and the RX chain is connected to USRP source 
and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. So 
for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My problem 
is that when I lock and unlock the flowgraph, I get a lot of underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.




N210 DAC and ADC usage

2022-03-04 Thread Fabien PELLET

Hello,

As there are IOs available on LFTX and LFRX, there are also ADC and DAC 
available.


Is there a way to use them as SOURCE and SINK in gnuradio for low speed 
conversion ?


Thanks,

Best regards,

Fabien, F4CTZ.