OP25 -- ZeroDvisionError

[PiccoIntegra]

Hi Scott,

Tried google. Everything points to the Op25 page

Using just the 'UHD' causes a divide by zero error, so it's looking for more args there.

Getting late tonight but I will try the OP25 forum tomorrow, maybe someone else can chime in. Shame that I am this close and the page with the docs are all gone

thanks!

try this:
./scope.py --args 'uhd,type=b200,nchan=1'

The gr-osmosdr wiki provides valid parameter info. It also links to documentation on the Ettus site, but the links are broken, Here are those links:
specifying the subdevice
common device identifiers

 

[mtindor]

On jcardini's system (Linux Mint 17.1 32-bit plus OP25 -- and of course the prerequisites), we can't seem to figure out how to get the B200 to work with it.

When running OP25, I don't remember what the command line looked like. Joe is going to have to obtain a command line that produces a similar error so that one can see what OP25 is actually being told to do.

Some info first, and then the error at the bottom.

If you think you can help figure this out, please chime in.

Tnx

Mike

uhd_find_devices

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524

-- Loading firmware image: /home/jcardani/target/share/uhd/images/usrp_b200_fw.hex... done
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    type: b200
    name:
    serial: 3070E49
    product: B200

uhd_usrp_probe

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524

-- Loading FPGA image: /home/jcardani/target/share/uhd/images/usrp_b200_fpga.bin... done
-- Operating over USB 2.
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz...
-- Actually got clock rate 32.000000 MHz.
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
  _____________________________________________________
 /
|       Device: B-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: B200
|   |   revision: 4
|   |   product: 1
|   |   serial: 3070E49
|   |   FW Version: 7.0
|   |   FPGA Version: 4.0
|   |
|   |   Time sources: none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 0
|   |   |   Freq range: -16.000 to 16.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: A
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Frontend: A
|   |   |   |   Name: FE-RX2
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors:
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 73.0 step 1.0 dB
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: B200 RX dual ADC
|   |   |   |   Gain Elements: None
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 0
|   |   |   Freq range: -16.000 to 16.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: A
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: A
|   |   |   |   Name: FE-TX2
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors:
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: B200 TX dual DAC
|   |   |   |   Gain Elements: None

CLI may have been one of these:
./scope.py --args 'uhd,nchan=1,subdev=B:0' -g 65 -f 774193750 -o 50e3 -V -v 0 -T trunk.tsv
or
./scope.py --args 'uhd' -f 774193750 -V -T trunktsv

I'm thinking the commandline looked more like the latter, and I think the former produced a different result, like a segfault or something.

We really did not know what to try for nchan / subdev if we were even to include them in the args.   Even with the documentation I've seen describing the args, its greek to me.

We tested without -g, -o and -V.   We also tested various combinations of nchan1|2 and subdev A:0|B:0.

gr-osmosdr v0.1.4-8-g46bb1ad1 (0.1.5git) gnuradio 3.7.6git-255-gd0d286d3
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace
-- Operating over USB 2.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz...
-- Actually got clock rate 32.000000 MHz.
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Using subdev spec 'A:A'.
gain: name: PGA range: start 0 stop 73 step 1
supported sample rates 62500-32000000 step 492
Using Volk machine: ssse3_32
-- Asking for clock rate 40.960000 MHz...
-- Actually got clock rate 40.960000 MHz.
-- Performing timer loopback test... pass
set_center_freq: 773431250
Traceback (most recent call last):
  File "./scope.py", line 2817, in <module>
    app = stdgui2.stdapp(p25_rx_block, "APCO P25 Receiver", 3)
  File "/home/jcardani/target/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 46, in __init__
    wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__
    self._BootstrapApp()
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/home/jcardani/target/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 49, in OnInit
    frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File "/home/jcardani/target/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 76, in __init__
    self.panel = stdpanel (self, self, top_block_maker)
  File "/home/jcardani/target/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 98, in __init__
    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "./scope.py", line 213, in __init__
    self.open_usrp()
  File "./scope.py", line 1158, in open_usrp
    self.__set_rx_from_osmosdr()
  File "./scope.py", line 907, in __set_rx_from_osmosdr
    self.__build_graph(self.src, capture_rate)
  File "./scope.py", line 238, in __build_graph
    channel_rate = capture_rate // channel_decim
ZeroDivisionError: float divmod()

 

[PiccoIntegra]

The channel rate(96k) isn't evenly divisible by the default sample rate of 320000, so it's throwing that error. I have no clue as to what that device will take as a valid sample rate. I know it can be very small, and very large based on the output you pasted here. Try passing a value of 2400000 or 4800000 and see what it does.

Based on the line numbers from the error, he's using the master branch code base. In order for the trunking to chase the control channel, he'll need to update OP25 using the max branch. Doing this should also solve the ZeroDivisionError error too. That part of the code has been eliminated.

 

[mtindor]

The channel rate(96k) isn't evenly divisible by the default sample rate of 320000, so it's throwing that error. I have no clue as to what that device will take as a valid sample rate. I know it can be very small, and very large based on the output you pasted here. Try passing a value of 2400000 or 4800000 and see what it does.

Based on the line numbers from the error, he's using the master branch code base. In order for the trunking to chase the control channel, he'll need to update OP25 using the max branch. Doing this should also solve the ZeroDivisionError error too. That part of the code has been eliminated.

Rgr that. We'll get it working. Thanks for the info. We know the B200 works, as we did try out the FFT stuff.

The sample rate did very quickly cross my mind, and then disappeared in a haze -- too bad, because I suspect you hit the nail on the head. We'll try some other sample rates. I'm not even sure if he's got it plugged into a USB 3.0 port, so I'm guessing the sample rate is going to have to be decreased.

Mike

 

[PiccoIntegra]

I'll go out on a limb and say he doesn't have a USB 3.0 port on that machine. heh

BTW, he shouldn't need to specify the subdev parameter unless he's using more than one RX channel at a time. That command line I posted in the other thread should work as is. I also asked to have that post moved to this thread, we'll see.

 

[mtindor]

I'll go out on a limb and say he doesn't have a USB 3.0 port on that machine. heh

BTW, he shouldn't need to specify the subdev parameter unless he's using more than one RX channel at a time. That command line I posted in the other thread should work as is. I also asked to have that post moved to this thread, we'll see.

Yeah that was what I was thinking [about USB]. Gut feeling is probably correct. But, Joe told me that he didn't buy the B200 for the bandwidth.

Ok on the command line, we'll give it a try. I tried lookking around last night to try and find some real information about supported sample rates, but I couldn't find anything. He might just have to shoot an email off to Ettus and get that info from the horses' mouth.

And we'll get him updated to the max branch.

Thanks again for all of your help, Scott.

mike

 

[jcardani]

Hi Mike and Scott,

Thanks so much for helping! Lots of great suggestions!

Mike and I will continue this weekend, after the holiday.

Have a Happy New Year!

Joe

 

[PiccoIntegra]

Here you go Mike & Joe:

Signal Scope is the link you're interested in. Gotta love the WayBackMachine!

 

[mtindor]

Here you go Joe & Mike:

Signal Scope is the link you're interested in. Gotta love the WayBackMachine!

Thanks, Scott. Progress has been made. A few things to note:

Joe can receive the Philadelphia P25 system signals, although it is distant. Joe can also get a very good signal on his local county system, but it's Phase II so he isn't going to currently get audio traffic. He can monitor a conventional P25 signal.

We used the --args values that you gave. We used -N 'PGA:40'. Gain values can be between 0 and 80something I think.

We have used lower sample rates like -S 2400000 and -S 1200000, because we know we don't want to be trying to do something extreme over his USB 2.0.

Bottom line, thus far...

He sees the signals, they show up nice on the FFT. On the second screen [i dont have it up to remember what it is] the signal is pretty much centered on 0 with the peaks at about 5 and -5, which when I set my own up is pretty much dead on frequency.

If he goes to view the constellation (direct), it's circular but with a lot of trash inside. If he switches to differential, he doesn't see the distinct quadrants that one would expect.

No -q value was used. Gradually increasing / decreasing the -q value results in it going further off frequency, so it's probably pretty much dead on. And I'm guessing that being what the device is, there is probably no need for that kind of tuning either.

He hasn't been able to get anything in the traffic window when monitoring either of the trunked P25 control channels.

He does see errors noted in the terminal window while monitoring.

When he monitors a conventional P25 frequency [which is only transmitting intermittently], he can get bits and pieces of decoded audio.

So he is close.

When running with -S 2400000 or -S 1200000 his CPU cores are at about 85% and 10% I think.

We had to stop our testing for today, but that's where we have gotten so far.

Given that he hasn't been able to clearly copy a simple conventional P25 channel error free, OP25 obviously isn't to blame. But I'm unsure at this point where we should be going next as far as troubleshooting.

I think I've filled you in as much as I can, which I've attempted to do because you've been so helpful in this endeavor.

mike

 

[mtindor]

Oh yeah, dummy me. I've been around the block a few times, and I can't believe I didn't think to try the wayback machine. Thank you for that. Very useful to have and bookmark the OP25 information from there.

Mike

 

[mtindor]

Additionally, the DivisionZero error or whatever that was went away, which you obviously knew would. But, if he tries to trunk, it comes up with an error about the NAC. I had him look through trunk.tsv [and in fact he emailed it to me] and everything looks fine in there.

But since we have yet to get it do decode any control channels or P25 conventional error free, I didnt feel the need to pursue the NAC issue at this time. But I'm sure it will creep up again once we get control channel decodes error free. And at that time I'll post the exact error about the NAC.

Mike

 

[mtindor]

Joe figured it out. He added the -o for the DC offset. I'll let him come on here and rave about how beautifully the LSM systems are decoded by OP25 zero errors heh.

Mike

 

[PiccoIntegra]

Awesome! The offset makes sense now... without actually seeing what the full command line being used, it didn't make all that much sense. I'm happy to see him get over that hump. Good job Mike.

I want to see some spectrum and constellation plots Joe!

 

[jcardani]

Hi Scott and Mike:

so far the optimal command line args for non trunked monitoring:

./scope.py --args "uhd, type=b200,nchan=1" -f 852837500 -V -N 'PGA:40' -S 120000 -o 25e3

started with PGA:50 and -o 50e3

It still needs tweaking though. I wonder what the optimal sample rate should be for the B200 since I am running USB2 and a dual core machine?

And the optimal -N and -o figures should be. The bands are very crowded with many signals at 12.5 KHz apart.

I'll check out the way back machine and see if any additional info is there.

thanks again to all!

Joe

 

[jcardani]

Settled on the following args for best reception of Philadelphia's LSM system, approx 20 miles from my location.

./scope.py --args "uhd, type=b200,nchan=1" -f 852837500 -V -N 'PGA:40' -o 50e3

Almost error free decode and the constellation/symbols look good. However I am getting a tuning error +/- 2400 anytime an adjacent channel (12.5 KHz) transmits. And it kills the decode of the desired signal.

Is there any way to improve on the selectivity because there are a number of channels on the system that are spaced 12.5 KHz?

PS: If I connect any scanner to the same antenna, the voice is a jumbled hot mess, virtually unintelligible! OP25 is simply amazing!

Next step is to get the trunk.tsv set up properly.


Will get the plots copied here ASAP!
thanks!

 

[PiccoIntegra]

Hi Joe,

I too have occasional 'tuning error +/- 2400' message with one of my dongles. It can get into a state and isn't easy to get back in phase, so I have to restart the app. This behavior was something that was changed recently due to RTL dongles having poor stability.

Open the scope.py file with a text editor and search for:

fmax = 2400	# Hz

change to:

fmax = 1200	# Hz

By changing this setting, the signal's phase will be much more sensitive to fine tuning. The trade off here is that it's easy to get it back if you tune too far.

 

[jcardani]

Hi Scott,

I can't find max = 2400 in the scope.py file. I used nano 's control W (where) command and it did not find that line for some reason. Manually going through the file I can't seem to find it either but it's a big file and getting tired.

In another issue, I am getting a KeyError: 'NAC' error when I try to run ./scope.py with the -T trunk.tsv argument

the File looks like this:

"Sysname" "Control Channel List" "Offset" "NAC" "Modulation" "TGID Tags File" "Whitelist" "Blacklist" "Center Frequency"

"Philly" "853.3375" "7000" "0x3b4" "CQPSK"

For some reason wayback did not cache the trunk.tv file format example.

 

[PiccoIntegra]

Are you running the max branch now? If so it'll be in a file named p25_demodulator.py.

Don't edit those tsv files in LibreOffice, use the gedit text editor. Each field needs a tab separator.. and no empty lines.

 

[jcardani]

Hi Scott,

Yes running max branch. I made the change to the p25_demodulator.py file. Now getting tuning error +/- 1200 when there is an adjacent channel active that is 12.5 KHz away. It totally kills OP25 - it can't decode. Without the adjacent channel trans it decodes perfectly.

Also after the adjacent channel interference goes away the tuning error stays and need to restart scope.py (like you said)

Are there any tweaks to improve selectivity?

 

[PiccoIntegra]

I only have one other suggestion, in that same file(p25_demodulator.py) find the line:

lpf_coeffs = filter.firdes.low_pass(1.0, input_rate, 15000, 1500, filter.firdes.WIN_HANN)

change it to:

lpf_coeffs = filter.firdes.low_pass(1.0, input_rate, 12500/2, 1500, filter.firdes.WIN_HANN)

The filter params are fairly wide, and this will tighten things up a bit. Let me know how this works.