Re: N210 DAC and ADC usage
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. >> >
GRC 3.9.4.0 - module porting problem
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(_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: GRC 3.9.4.0 - module porting problem
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(_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: RX/TX switching
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: N210 DAC and ADC usage
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
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.
N210 DAC and ADC usage
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.
RX/TX switching
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
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
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
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: N210 DAC and ADC usage
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.
