ODR-DabMod and USRP B100

498 views
Skip to first unread message

Fabien Cuny

unread,
Feb 18, 2019, 8:07:31 AM2/18/19
to mmbtools
Hi,

I recently got an USRP B100 to do DAB trials.
I followed this link to install UHD drivers : https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux

I have done the trials with a local ODR-DabMux instance and a hosted one on our server.
The tests have been done on 2 PC with Ubuntu 18.04.2 LTS :
- Intel Atom x5-z8300 (4 x 1.6 Ghz)
- Intel Pentium 4 HT (3.2 Hhz)
The results are the same on both. I got some underruns and the ZMQ input buffer become overfull.
Here is the result of the execution of one instance of ODR-DabMod with the USRP B100 :

lexoradio@LR-DAB:~$ odr-dabmod dab/modUHD.ini
ODR-DabMod version v2.3.0, compiled at Feb 18 2019, 07:02:15
Compiled with features: zeromq output_uhd output_soapysdr fast-math SSE
Warning:setting type in [uhd] device is deprecated !
Input
Type: zeromq
Source: tcp://lexoradio.fr:8085
Output
UHD
Device: type=b100
Subdevice:
master_clock_rate: 32768000
refclk: internal
pps source: none
Sampling rate: 2.0480 MHz
Configuration parsed. Starting up version v2.3.0
OutputUHD:Creating the usrp device with: type=b100,master_clock_rate=32768000...
UHD Message (2) UHD: linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.11.0.HEAD-0-ga06eaad1
UHD Message (2) B100: USRP-B100 clock control: 2 r_counter: 25
a_counter: 0
b_counter: 256
prescaler: 8
vco_divider: 2
chan_divider: 25
vco_rate: 1638.400000MHz
chan_rate: 819.200000MHz
out_rate: 32.768000MHz
UHD Message (3) CORES: The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 33 = (32.768000 MHz)/(1.000000 MHz)
UHD Message (3) CORES: The requested interpolation is odd; the user should expect CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 33 = (32.768000 MHz)/(1.000000 MHz)
OutputUHD:Using device: Single USRP:
Device: B-Series Device
Mboard 0: B100
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv2 RX+GDB
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv2 TX+GDB
...
OutputUHD:Checking master clock rate: 32768000.000000...
UHD clock source is internal
UHD time source is none
OutputUHD: Setting USRP time to 1550486802.481000
OutputUHD:Set rate to 2048000. Actual TX Rate: 2048000.000000 sps...
OutputUHD:Setting freq to 229072000.000...
OutputUHD:Actual TX frequency: 229071999.997
OutputUHD:Actual RX frequency: 229071999.997
OutputUHD:Actual TX Gain: 15.000000
OutputUHD:Mute on missing timestamps: disabled
OutputUHD:Actual RX Rate: 2048000.000000 sps.
OutputUHD:Actual RX Antenna: RX2
OutputUHD:Actual TX Antenna: TX/RX
OutputUHD:Actual RX Gain: 0.000000
Setting up timestamp decoder with 0 offset
Input ZeroMQ: Receiving from tcp://lexoradio.fr:8085
FIRFilter: Reading 45 taps...
UU OutputUHD status (usrp time: 1550486825.015031): 2 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550486836.629505): 1 underruns and 0 late packets since last status.
UU OutputUHD status (usrp time: 1550486853.856852): 2 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550486856.597194): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550486941.077801): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550486983.896219): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487020.738767): 1 underruns and 0 late packets since last status.
UUU OutputUHD status (usrp time: 1550487022.071092): 3 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487062.766433): 1 underruns and 0 late packets since last status.
UU OutputUHD status (usrp time: 1550487064.596521): 2 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487145.719287): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487149.392290): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487186.955055): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487188.700555): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550487394.060933): 1 underruns and 0 late packets since last status.
UU OutputUHD status (usrp time: 1550487399.080809): 2 underruns and 0 late packets since last status.
WARN ZeroMQ buffer overfull !
ERROR Exception during receive: 'ZMQ input full'
ZeroMQ input worker terminated
UUU OutputUHD status (usrp time: 1550487402.683549): 3 underruns and 0 late packets since last status.

I followed all the tutorials and mux examples, everything runs well with the HackRF One i've got.
I also noticed that when the ZMQ input full message appears, the ODR-DabMod process gets 100% of CPU.

Here is my mod.ini :

;Sample configuration file for ODR-DabMod

;[remotecontrol]
; The RC feature is described in detail in doc/README-RC.md

; enable the telnet remote control on localhost:2121
telnet=1
telnetport=2121

; Enable zmq remote control.
zmqctrl=1
zmqctrlendpoint=tcp://127.0.0.1:9400

[log]
syslog=0
filelog=0
filename=odr-dabmod.log

[input]
transport=zeromq
source=zmq+tcp://lexoradio.fr:8085
;zmq-buffer=2048
;zmq-prebuffer=64
;max_frames_queued=10

loop=0

[modulator]
gainmode=var
digital_gain=0.8
rate=2048000

[cfr]
enable=0
clip=50.0
error_clip=0.1

[firfilter]
enabled=1
filtertapsfile=/home/lexoradio/ODR-DabMod/doc/fir-filter/filtertaps.txt

[poly]
enabled=0
polycoeffile=polyCoefs

[output]
output=uhd

[uhdoutput]
device=
master_clock_rate=32768000
type=b100
txgain=15.0
channel=12D
lo_offset=2048000
refclk_source=internal

What i'm missing ?

Thank you for your help

Fabien

Rashid Mustapha

unread,
Feb 19, 2019, 7:03:58 AM2/19/19
to crc-mm...@googlegroups.com
Does it still under-run if you turn off the fir filter?

I presume you are using a wbx trx daughtercard? Beware that the MER is not great unless you modify the loop filter. 

Also, V2 of the wbx has an AGC problem which causes overshoots. This has been known to damage power amplifiers.

Nice little radios though. I still use some, especially for GSM.

R.

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fabien Cuny

unread,
Feb 19, 2019, 10:13:51 AM2/19/19
to mmbtools
Hello Rash,

Thanks for your message.
I edited my mod.ini file (I found here an optimised version of the mod.ini file here : https://github.com/mpbraendli/mmbtools-aux/blob/master/b100-2048.ini)
I have less underruns but the issue remains.
I have the WBX V2, i don't know if it's TRX. What do you mean about MER ? And how about the loop filter as the input is coming from ODR-DabMux via ZMQ ?
I also tried with SoapySDR but the problem is the same.

I have also synchronized both NTPs clients (from lexoradio.fr and my PC) as i read that it also could be an issue.

Any ideas ?

This is my new mod.ini :

; Sample configuration file for CRC-DABMOD
[remotecontrol]
telnet=1
telnetport=2121
[log]
syslog=0
filelog=0
filename=/dev/stderr
[input]
;transport=file
;source=/home/odr/0,0x0425.bin.eti
;loop=1
transport=zeromq
source=zmq+tcp://lexoradio.fr:8085
max_frames_queued=2500
;zmq-buffer=640
[modulator]
; Gain mode: 0=FIX, 1=MAX, 2=VAR
gainmode=2
; Transmission mode
; If not defined, take the mode from ETI
;mode=2
; Set to 0 to disable CicEqualiser
dac_clk_rate=0
digital_gain=0.8
; Output sample rate
rate=2048000
[firfilter]
enabled=0
filtertapsfile=/home/lexoradio/ODR-DabMod/doc/fir-filter/filtertaps.txt
[output]
; choose output: possible values: uhd, file
output=uhd

[fileoutput]
filename=/dev/null

[uhdoutput]
;txgain=2
device=
master_clock_rate=20480000
type=b100
txgain=20
num_send_frame=128
send_frame_size=1024
;frequency=234208000
channel=12D

;[soapyoutput] ; These options are given to the SoapySDR library:
;device=
;master_clock_rate=32768000
;txgain=20
;channel=12D

; possible values : internal, external, MIMO
refclk_source=internal

; possible values : none, external, MIMO
pps_source=none

; behaviour when external clock reference lock lost
; possible values: ignore, crash
behaviour_refclk_lock_lost=crash


; Used for SFN with the UHD output
[delaymanagement]
synchronous=0
offset=2.0

And here is the log from the last execution of ODR-DabMod :

TX DSP: 0
TX Dboard: A
TX Subdev: WBXv2 TX+GDB
...
OutputUHD:Checking master clock rate: 20480000.000000...

UHD clock source is internal
UHD time source is none
OutputUHD: Setting USRP time to 1550582635.078000

OutputUHD:Set rate to 2048000. Actual TX Rate: 2048000.000000 sps...
OutputUHD:Setting freq to 229072000.000...
OutputUHD:Actual TX frequency: 229072000.000
OutputUHD:Actual RX frequency: 229072000.000
OutputUHD:Actual TX Gain: 20.000000

OutputUHD:Mute on missing timestamps: disabled
OutputUHD:Actual RX Rate: 2048000.000000 sps.
OutputUHD:Actual RX Antenna: RX2
OutputUHD:Actual TX Antenna: TX/RX
OutputUHD:Actual RX Gain: 0.000000
Setting up timestamp decoder with 0 offset
Input ZeroMQ: Receiving from tcp://lexoradio.fr:8085
U OutputUHD status (usrp time: 1550582742.300413): 1 underruns and 0 late packets since last status.
U OutputUHD status (usrp time: 1550582799.174914): 1 underruns and 0 late packets since last status.

WARN ZeroMQ buffer overfull !
ERROR Exception during receive: 'ZMQ input full'
ZeroMQ input worker terminated
U OutputUHD status (usrp time: 1550583213.450505): 1 underruns and 0 late packets since last status.

Rashid Mustapha

unread,
Feb 19, 2019, 1:09:45 PM2/19/19
to crc-mm...@googlegroups.com
Hello again,

The other thing I should point out is a Pentum 4 is quite old. I never managed to get crc-dabmod to work in a stable way on one, and the Atoms I have tried were on the edge.

That said, my P4 experiments were in 2011 which is long before the fork and long before mpb did any optimisation, so they may just be ok at the native rate.

Did you configure odr-dabmod with:

 --enable-fast-math 

If not, make clean and reconfigure.

I don't have any WBX v2 cards. I just heard they are very bad for amplifiers. As you won't be using it with an amplifier (or not for any meaningful amount of time anyway) you don't need to worry about the MER! ;-)


R.

Fabien Cuny

unread,
Feb 19, 2019, 4:10:10 PM2/19/19
to mmbtools
Hello again Rash,

I already compiled on both of the PCs ODR-DabMod with the --enable-fast-math option.
With the P4 and the HackRF, ODR-DabMod with its resampling and FIRFilter had a CPU Usage about 60-70%, so fine.
With the Atom and USRP, the CPU usage is about 20% without FIRFilter and around 35-40% with a FIFilter of 45 taps.
So I don't think it's a CPU related problem (I also put a "performance" clock and no "powersave" or "conservative").

The only "solution" I got for now is to increase the zmq-buffer in the mod.ini file but that's not rally a solution, because I have before the buffer explode, 2 mins of difference with the time broadcasted.

No, I don't use any amplifier as it's a PoC for the moment, we are doing some trials at very small scale in order to know how it works because DAB+ is coming over us in France.

Any other ideas ? :-)

Thanks for your help

Rashid Mustapha

unread,
Feb 19, 2019, 5:26:39 PM2/19/19
to crc-mm...@googlegroups.com
Ok - yes I know. I often pick up French DAB on a portable radio indoors here. It puts the UK to shame as it sounds brilliant, looks brilliant.

I'm not sure what else to suggest other than you can remove a lot of variables by building on a platform with ample processing and fewer bottlenecks, then when it's going ok, try the weaker ones.

My hint is every single i3 I have ever tried has been fine. Loads of cheap dual cores around...

R.

Matthias Brändli

unread,
Feb 20, 2019, 2:45:35 AM2/20/19
to crc-mm...@googlegroups.com
Hello Fabien, Rash,

it doesn't look like a CPU performance issue to me, the underruns are in
very regular intervals, and you mention CPU usage is quite low.

A few random ideas:

Is NTP properly running on your mux? (Ensures proper mux rate)

Do you have a good (ideally GPS-disciplined) 10MHz reference you could
use for the B100? [1] Maybe the TCXO inside the B100 is a bit off...

USB controller: have you tried different ports on different USB root
hubs or controllers?

Do you use your atom head-less (no X11 running, control over ssh) or
with a GUI? head-less is usually better.

Just a couple of ideas... Let us know if anything improves your setup.

mpb

[1]
This is something that should anyway be put in place for 24/7 systems,
otherwise you're going to see some drift.

You can find used Trimble Thunderbolt units online, or maybe buy
http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=107&products_id=301

If you buy a Leo Bodnar GPSDO, please tell us about your experience, if
it works well it would be nice to mention in the ODR-DabMod documentation!
> lexoradio.fr <http://lexoradio.fr> and my PC) as i read that
> it also could be an issue.
>
> Any ideas ?
>
> This is my new mod.ini :
>
> ; Sample configuration file for CRC-DABMOD
> [remotecontrol]
> telnet=1
> telnetport=2121
> [log]
> syslog=0
> filelog=0
> filename=/dev/stderr
> [input]
> ;transport=file
> ;source=/home/odr/0,0x0425.bin.eti
> ;loop=1
> transport=zeromq
> source=zmq+tcp://lexoradio.fr:8085 <http://lexoradio.fr:8085>
> <http://lexoradio.fr:8085>
> <http://lexoradio.fr:8085>   
> <http://lexoradio.fr:8085>   
> <http://127.0.0.1:9400>
>
> [log]
> syslog=0
> filelog=0
> filename=odr-dabmod.log
>
> [input]
> transport=zeromq
> source=zmq+tcp://lexoradio.fr:8085
> <http://lexoradio.fr:8085>
> <mailto:crc-mmbtools...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.

Fabien Cuny

unread,
Feb 22, 2019, 4:03:44 AM2/22/19
to mmbtools
Hello Matthias,

Thanks for your reply.

Yes, the mux is located on an online webserver with NTP sync.
I also put here on the Atom the same NTP servers.As i'm in ADSL here, i can have a more important response time.

I haven't got an external 10Mhz source, i use the internal TXCO for the moment, but as I would like to do some SFN trials in the future, i can afford the Leo Bodnar module you mentioned.

I also have to try at our studios (where we got Optical Fiber network), maybe it could be a latence issue. But it works well with an HackRF.

Both of them server (for the mux) and the Atom are on Ubuntu. The server is completely headless, and the Atom gots Ubuntu Mate, but boots with no X11.
>     For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com

Matthias Brändli

unread,
Feb 24, 2019, 5:06:53 AM2/24/19
to crc-mm...@googlegroups.com
Hi,

> Yes, the mux is located on an online webserver with NTP sync.
> I also put here on the Atom the same NTP servers.As i'm in ADSL here, i
> can have a more important response time.

That shouldn't be an issue.


> I haven't got an external 10Mhz source, i use the internal TXCO for the
> moment, but as I would like to do some SFN trials in the future, i can
> afford the Leo Bodnar module you mentioned.

Not sure the Leo Bodnar is good enough for SFN, because it's missing a
1PPS output for time sync. Maybe you could write him to ask if it's
possible to get the 1PPS somehow.

Maybe using a second GPS receiver's 1PPS output would be workable, but
it's a bit ridiculous :-)

I don't remember if you can modify the B100 to accept a 30.72 MHz
REFCLK, if so you could assemble a LEA-M8F GPSDO:
http://www.opendigitalradio.org/lea-m8f-gpsdo

> I also have to try at our studios (where we got Optical Fiber network),
> maybe it could be a latence issue. But it works well with an HackRF.

Latency itself cannot cause regular underruns. Latency jitter can, or a
rate difference. But in any case, an additional test with another
network is interesting.


> Both of them server (for the mux) and the Atom are on Ubuntu. The server
> is completely headless, and the Atom gots Ubuntu Mate, but boots with no
> X11.

Sounds good!

mpb

Matthias Brändli

unread,
Feb 25, 2019, 8:15:39 AM2/25/19
to crc-mm...@googlegroups.com
Hello again

On 24/02/2019 11:06, 'Matthias Brändli' via mmbtools wrote:
>> I haven't got an external 10Mhz source, i use the internal TXCO for the
>> moment, but as I would like to do some SFN trials in the future, i can
>> afford the Leo Bodnar module you mentioned.
> Not sure the Leo Bodnar is good enough for SFN, because it's missing a
> 1PPS output for time sync. Maybe you could write him to ask if it's
> possible to get the 1PPS somehow.

I got the following information from Leo Bodnar support:

"""
1PPS comes out of the 2nd output, when it is switched off from frequency
output.
"""

So using the the GPSDO with two outputs should work for a SFN with your
B100!

mpb

Fabien Cuny

unread,
Jan 11, 2020, 7:36:26 PM1/11/20
to mmbtools
Hello,

After quite a long time, I'm back with my B100 to continue the trials, as I have now an EasyDab, so I will try to do an SFN with it and the B100.
I received the Leo Bodnar GPS. I had set the 1st output to 10MHz and disabled the second output (led corresponding to the 2nd output blinks 1 time per second as Leo Bodnar's support said, so it's 1PPS).
I connected the two outputs of the Leo Bodnar GPSDO to the B100 and i changed the following values in the dabmod config file :

; possible values : internal, external, MIMO
refclk_source=external

; possible values : none, external, MIMO
pps_source=external

[delaymanagement]
synchronous=1

But when I execute ODR-DabMod, i got the following error :
      OutputUHD:Using device: Single USRP:
  Device: B-Series Device
  Mboard 0: B100
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: WBXv2 RX+GDB
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: WBXv2 TX+GDB
...
      OutputUHD:Checking master clock rate: 32768000.000000...

      UHD clock source is external
      UHD time source is external
Modulator runtime error: USRPTime not implemented yet: external

I recompiled the newest version of UHD drivers (3.15) but does the same. It's when a change pps_source from none to external that causes the trouble.
What I don't understand is when I type the command uhd_usrp_probe, "external" or "_external_" should be recognized, but i tried both in dabmod : same issue.

whatthemux@odr-wtm-debian:~/dab$ sudo uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_3.15.0.0-0-unknown
  _____________________________________________________
 /
|       Device: B-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: B100
|   |   revision: 8192
|   |   serial: E6R10Z0B1
|   |   FW Version: 4.0
|   |   FPGA Version: 11.4
|   |   
|   |   Time sources:  none, external, _external_
|   |   Clock sources: internal, external, auto
|   |   Sensors: ref_locked

Have you got an idea ?

Thanks,

Fabien

Matthias Brändli

unread,
Jan 14, 2020, 4:19:11 AM1/14/20
to crc-mm...@googlegroups.com
Hello Fabien,

It's been a while I used external PPS on a USRP, maybe I got confused at
some point and thought it was "pps" and not "external".

But uhd_usrp_probe says "external" for my B200, and you confirm it's the
same for the B100, so I've added "external" to the list of supported
options in USRPTime.cpp

Please try again with the latest "next" and let me know.

mpb

On 12/01/2020 01:36, Fabien Cuny wrote:
> Hello,
>
> After quite a long time, I'm back with my B100 to continue the trials,
> as I have now an EasyDab, so I will try to do an SFN with it and the B100.
> I received the Leo Bodnar GPS. I had set the 1st output to 10MHz and
> disabled the second output (led corresponding to the 2nd output blinks 1
> time per second as Leo Bodnar's support said, so it's 1PPS).
> I connected the two outputs of the Leo Bodnar GPSDO to the B100 and i
> changed the following values in the dabmod config file :
>
> ; possible values : internal, external, MIMO refclk_source=external ;
> possible values : none, external, MIMO pps_source=external
> [delaymanagement] synchronous=1
>
>
> But when I execute ODR-DabMod, i got the following error :
>
> OutputUHD:Using device: Single USRP: Device: B-Series Device Mboard 0:
> B100 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: WBXv2 RX+GDB TX
> Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: WBXv2 TX+GDB ...
> OutputUHD:Checking master clock rate: 32768000.000000... *UHD clock
> source is external UHD time source is external Modulator runtime error:
> USRPTime not implemented yet: external*
>
>
> I recompiled the newest version of UHD drivers (3.15) but does the same.
> It's when a change pps_source from none to external that causes the trouble.
> What I don't understand is when I type the command uhd_usrp_probe,
> "external" or "_external_" should be recognized, but i tried both in
> dabmod : same issue.
>
> whatthemux@odr-wtm-debian:~/dab$ sudo uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700;
> UHD_3.15.0.0-0-unknown
>   _____________________________________________________
>  /
> |       Device: B-Series Device
> |     _____________________________________________________
> |    /
> |   |       Mboard: B100
> |   |   revision: 8192
> |   |   serial: E6R10Z0B1
> |   |   FW Version: 4.0
> |   |   FPGA Version: 11.4
> |   |   
> |   |   Time sources:  none, *external*, _external_
> |   |   Clock sources: internal, external, auto
> |   |   Sensors: ref_locked
>
>
> Have you got an idea ?
>
> Thanks,
>
> Fabien
>
> Le lundi 25 février 2019 14:15:39 UTC+1, Matthias Brändli a écrit :
>
> Hello again
>
> On 24/02/2019 11:06, 'Matthias Brändli' via mmbtools wrote:
> >> I haven't got an external 10Mhz source, i use the internal TXCO
> for the
> >> moment, but as I would like to do some SFN trials in the future,
> i can
> >> afford the Leo Bodnar module you mentioned.
> > Not sure the Leo Bodnar is good enough for SFN, because it's
> missing a
> > 1PPS output for time sync. Maybe you could write him to ask if it's
> > possible to get the 1PPS somehow.
>
> I got the following information from Leo Bodnar support:
>
> """
> 1PPS comes out of the 2nd output, when it is switched off from
> frequency
> output.
> """
>
> So using the the GPSDO with two outputs should work for a SFN with your
> B100!
>
> mpb
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>.

Fabien Cuny

unread,
Jan 15, 2020, 6:03:57 PM1/15/20
to mmbtools
Hello Matthias,

Thanks for your super quick reply.
I recompiled next branch, this time I haven't got the USRPTime not implemented error.

But I've got the following error when I put the "synchronous" option to 1, for example :  Timestamp way too far in the future at FCT=100 offset: 1579130001.900974
I've configured my mux to with the "tist" to true, and put external to both 1PPS and 10MHz source.
And yes, the timestamp given by this error is approx 17min in the future ! The PC is well wynched with NTP servers too.

What could be this huge drift of timestamp ? I've tried several configurations, but always give this error.

I've joined my simple mux config, with the modulator config, the Leo Bodnar config (if it helps, Output 1 : 10Mhz, Output 2 disabled which gives 1PPS) and the modulator log.

For info, a bit of the log. ODR-DabMod is restarting itself at each startup :

      OutputUHD:Checking master clock rate: 32768000.000000...
      UHD clock source is external
      UHD time source is external
      OutputUHD:Set rate to 2048000. Actual TX Rate: 2048000.000000 sps...
      OutputUHD:Setting freq to 230784000.000...
      OutputUHD:Actual TX frequency: 230784000.000
      OutputUHD:Actual RX frequency: 230784000.000
      OutputUHD:Actual TX Gain: 20.000000
      OutputUHD:Mute on missing timestamps: disabled
      OutputUHD:Actual RX Rate: 2048000.000000 sps.
      OutputUHD:Actual RX Antenna: RX2
      OutputUHD:Actual TX Antenna: TX/RX
      OutputUHD:Actual RX Gain: 0.000000
      Setting up timestamp decoder with 1000 offset
      Input ZeroMQ: Receiving from tcp://127.0.0.1:19086
WARN  ZeroMQ buffer low: 4 elements !
      FIRFilter: Reading 45 taps...
ERROR OutputSDR: Timestamp way too far in the future at FCT=100 offset: 1579130001.900974
ERROR SDR output thread caught runtime error: Timestamp error. Aborted.
ERROR Exception caught: SDR thread failed
ERROR Modulator failure.
      44 DAB frames encoded
      1.056 seconds encoded

Thanks,

Fabien

conf_leobodnar.PNG
mod1.ini
mod1.log
mux1.mux

Jan de Vries

unread,
Jan 16, 2020, 5:05:04 AM1/16/20
to mmbtools
outputs {
    zmq "zmq+tcp://*:19086"
    throotle "simul://"
}

>>>>   throttle "simul://"   <<<<

small typo ;-)

Fabien Cuny

unread,
Jan 16, 2020, 5:10:11 AM1/16/20
to mmbtools
Hello Jan :)

My copy/paste just don't get this last line so I added it by writing, that's why for the typo :-)
Sorry for that.

Matthias Brändli

unread,
Jan 16, 2020, 5:33:03 AM1/16/20
to crc-mm...@googlegroups.com
Hello Fabien,

what versions of ODR-DabMux and ODR-DabMod are you using?

Also, can you try the following:

Configure ODR-DabMod to:
- output to file
- format doesn't matter
- filename=/dev/null (which discards the IQ data)
- show_metadata=1

and then look at the timestamps shown on the console, and see if the
offset also appears there?

1579130001 seconds is more than 17 minutes. How did you calculate that
number?

I suspect that the USRPTime constructor (USRPTime.cpp line 42) doesn't
do the right thing, and doesn't setup time inside the USRP. The comment
I wrote on line 61 suggests to me that the `verify_time` function is
supposed to do that, which is written for the scenario where you have an
internal GPSDO.

You can try calling `set_usrp_time_from_pps()` on line 61 as a first
step to see if that is necessary.

mpb

On 16/01/2020 00:03, Fabien Cuny wrote:
> Hello Matthias,
>
> Thanks for your super quick reply.
> I recompiled next branch, this time I haven't got the USRPTime not
> implemented error.
>
> But I've got the following error when I put the "synchronous" option to
> 1, for example : *Timestamp way too far in the future at FCT=100 offset:
> 1579130001.900974*
> *ERROR OutputSDR: Timestamp way too far in the future at FCT=100 offset:
> 1579130001.900974*
> > an email to crc-mm...@googlegroups.com <javascript:>
> > <mailto:crc-mmbtools...@googlegroups.com <javascript:>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com?utm_medium=email&utm_source=footer>.

Fabien Cuny

unread,
Jan 16, 2020, 4:56:36 PM1/16/20
to mmbtools
Hello Matthias,

Thanks for your help? :-)
For info, I'm using ODR-DabMux 2.3.1 (because of usage of SFN with EasyDab) and ODR-DabMod 2.3.1

Firstly, i set file output with the following parameters :
[fileoutput]
filename=/dev/null
format=u8
show_metadata=1

The output of ODR-DabMod with these parameters is in mod.log. There is a lot of "TS invalid" as you can see.

Secondly, i recompiled ODR-DabMod with the set_usrp_time_from_pps() function calling.
When i execute ODR-DabMod with uhd parameters and both externals (clock source and time source) :

      OutputUHD:Checking master clock rate: 32768000.000000...
      UHD clock source is external
      UHD time source is external
      OutputUHD: Setting USRP time next pps to 1579210977.000000
      UHD Message (2) MULTI_USRP:     1) catch time transition at pps edge
Modulator runtime error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.

It seems that we have got some troubles to get the 1PPS signal.

Thanks,

Fabien
>     > <mailto:crc-mmbtools+unsub...@googlegroups.com <javascript:>>.
mod.log

Matthias Brändli

unread,
Jan 17, 2020, 2:47:53 AM1/17/20
to crc-mm...@googlegroups.com
Hello Fabien,

thanks for testing this.

The log looks fine:
- The TS invalid occur at the beginning, before complete time could be
decoded. That's normal.
- The DELTA indicates difference between local system time and ETI
timestamp, which looks ok.


Regarding the 1PPS: Maybe we need to select from where the PPS is
supposed to come. After a quick search I found the following function in
UHD: set_time_source()

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361

But this function is called in UHD.cpp Line 174, so we should be fine...

Is the signal level ok?

mpb
> <http://127.0.0.1:19086>
> >     > <mailto:crc-mmbtools...@googlegroups.com
> <javascript:> <javascript:>>.
> >     > To view this discussion on the web visit
> >     >
> >    
> https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com>
>
> >    
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com>>
>
> >
> >     >
> >    
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>
>
> >    
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
>
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "mmbtools" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to crc-mm...@googlegroups.com <javascript:>
> > <mailto:crc-mmbtools...@googlegroups.com <javascript:>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/crc-mmbtools/99e5b8f8-2ed7-4ada-ad32-11417769484b%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crc-mmbtools/93dedc1d-5b75-48cb-929d-e961e8789f3b%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/93dedc1d-5b75-48cb-929d-e961e8789f3b%40googlegroups.com?utm_medium=email&utm_source=footer>.

Fabien Cuny

unread,
Jan 21, 2020, 10:06:16 AM1/21/20
to mmbtools
Hello Matthias,

The output signal level sounds good until the modulator restarts following these messages, resulting in a interruption on the transmission :
WARN  Timeout
WARN  Restart modulator.

Maybe, you are talking about the output level of the 1PPS output on the Leo Bonar GPS ?

What generates this timeout ? Because, as you said, the rest of the logfile shoud be good :-)

Fabien
>     >     > <mailto:crc-mmbtools+unsub...@googlegroups.com
>     <javascript:> <javascript:>>.
>     >     > To view this discussion on the web visit
>     >     >
>     >    
>     https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com>
>
>     >    
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com>>
>
>     >
>     >     >
>     >    
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>
>
>     >    
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer
>     <https://groups.google.com/d/msgid/crc-mmbtools/fc3e3bbd-efbf-48f1-8b64-7470506fd953%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
>
>     >
>     >
>     > --
>     > You received this message because you are subscribed to the Google
>     > Groups "mmbtools" group.
>     > To unsubscribe from this group and stop receiving emails from it,
>     send
>     > an email to crc-mm...@googlegroups.com <javascript:>
>     > <mailto:crc-mmbtools+unsub...@googlegroups.com <javascript:>>.

Matthias Brändli

unread,
Jan 21, 2020, 10:09:43 AM1/21/20
to crc-mm...@googlegroups.com
Hi Fabien

On 21/01/2020 16:06, Fabien Cuny wrote:
> Maybe, you are talking about the output level of the 1PPS output on the
> Leo Bonar GPS ?

Yes, I meant the 1PPS level. The modulator is not supposed to start
transmitting before it could set time.

So I guess your timeout scenario is different.


> What generates this timeout ? Because, as you said, the rest of the
> logfile shoud be good :-)

It comes from the ETI input, when there is no data.

mpb
Reply all
Reply to author
Forward
0 new messages