RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Software Defined Radio


Software Defined Radio - A forum for general discussion of software defined radio (SDR) receiver equipment.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #221 (permalink)  
Old 01-06-2018, 5:11 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,268
Default

Quote:
Originally Posted by fredva View Post
I'm pretty sure I'm experiencing frequency drift with my generic dongle. Even if I warm it up for 20-30 minutes before activating OP25, OP25 will work for awhile, then I start missing transmissions and get tuning errors. So I plan to get a NooElec NESDR Mini 2+ and hopefully it will perform better.
My three NooElec dongles have been pretty good. One went bad almost immediately, but they replaced it with no hassle whatsoever.

Be aware that these dongles do heat up considerably when actually operating (more so than just plugged in and idle). It's the temperature change which causes drift, so if you have a non-tcxo unit it will almost certainly drift a bit. In this regard smaller form factor (i.e. tiny case size) is not necessarily an advantage where stability is concerned.
Reply With Quote
Sponsored links
  #222 (permalink)  
Old 01-06-2018, 8:59 PM
dseven's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 304
Default

Quote:
Originally Posted by fredva View Post
I'm pretty sure I'm experiencing frequency drift with my generic dongle. Even if I warm it up for 20-30 minutes before activating OP25, OP25 will work for awhile, then I start missing transmissions and get tuning errors.
Make sure your power supply is sufficient. Maybe try running the dongle off a powered USB hub and see if that helps.....
Reply With Quote
  #223 (permalink)  
Old 01-06-2018, 10:12 PM
jonwienke's Avatar
Member
   
Join Date: Jul 2014
Location: PA
Posts: 8,884
Default

Quote:
Originally Posted by dseven View Post
Make sure your power supply is sufficient. Maybe try running the dongle off a powered USB hub and see if that helps.....
That's probably irrelevant. Unless you get a dongle with a TCXO, the accuracy of the tuner is unlikely to be closer than 30PPM.
__________________
Gone camping.
Reply With Quote
  #224 (permalink)  
Old 01-07-2018, 1:39 AM
dseven's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 304
Default

Quote:
Originally Posted by jonwienke View Post
That's probably irrelevant. Unless you get a dongle with a TCXO, the accuracy of the tuner is unlikely to be closer than 30PPM.
It seemed that frequency drift was *suspected* in the problem report, but but proven. I've had the symptom of the RTL2832U working for a few mins, then producing errors when trying to change frequency, and it turned out to be a power issue.
Reply With Quote
  #225 (permalink)  
Old 01-16-2018, 12:06 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2017
Posts: 9
Default

Can't speak for OP25, but I have done some basic FM receiving on the Pi with an RTL-SDR. However, I would consider getting a powered USB hub for the SDR. Tried it with and without and it does a little better with.
Reply With Quote
Sponsored links
  #226 (permalink)  
Old 01-28-2018, 8:06 AM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

Hello everyone, I have a few questions:

I've compiled op25 successfully on a RPi3 with Boatbod max repo, and am using it to monitor local DMR ham repeaters. Great job from all involved !

For some reason, it didn't work at first by using the ./install.sh script, but it when did when I used KB9MWR's instructions on his blog at Advancing Ham Radio.. different ideas: Listening to local 700 MHz Simulcast public safety cheaply.

I'm using a RTL-SDR V2 dongle. Also, for commodity, I'm using json files named with the callsign of the repeater I want to monitor, and the command line like this: python multi_rx.py -c VE2RIX.json -v 9

Here is the content of the VE2RIX.json file:
{
"channels": [
{
"demod_type": "fsk4",
"destination": "udp://127.0.0.1:56122",
"excess_bw": 0.2,
"filter_type": "rrc",
"frequency": 448625000,
"if_rate": 24000,
"name": "VE2RIX",
"symbol_rate": 4800
}
],
"devices": [
{
"args": "rtl:0",
"frequency": 448625000,
"gains": "lna:43",
"name": "rtl0",
"offset": 0,
"ppm": 2,
"rate": 1000000,
"tunable": false
}
]
}

It works, but for some reason, when I launch that command line, I get python errors and the command gets aborted. I have to launch this several times to get it to work finally. Examples of errors I get are:

*** Error in `python': corrupted double-linked list: 0x023ec948 ***
*** Error in `python': malloc(): smallbin double linked list corrupted: 0x01be3878 ***
*** Error in `python': corrupted double-linked list: 0x01908908 ***
After I receive these errors, I get "Aborted" messages, and go back to the command line prompt.

I sometimes get the following warning messages about jack server and SoapySSDEndpoint, but it doesn't prevent op25 to work:

linux; GNU C++ version 6.2.0 20161010; Boost_106100; UHD_003.009.005-0-unknown

device: {'gains': 'lna:43', 'args': 'rtl:0', 'tunable': False, 'rate': 1000000, 'frequency': 448625000, 'ppm': 2, 'offset': 0, 'name': 'rtl0'}
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock

RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (default), No such file or directory.

[ERROR] SoapySSDPEndpoint::sendTo(udp://[ff02::c]:1900) = -1
sendto(udp://[ff02::c]:1900) [99: Cannot assign requested address]
Found Rafael Micro R820T tuner
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
channel (dev rtl0): {'name': 'VE2RIX', 'demod_type': 'fsk4', 'symbol_rate': 4800, 'destination': 'udp://127.0.0.1:56122', 'excess_bw': 0.2, 'filter_type': 'rrc', 'frequency': 448625000, 'if_rate': 24000}
Using two-stage decimator for speed=1000000, decim=10/4 if1=100000 if2=25000
op25_audio:pen_socket(): enabled udp host(127.0.0.1), wireshark(56122), audio(56122)
___

Also, when using the json config file method, the only way I can hear the audio locally on the RPi's internal sound card, is by using the nc -kluvw 1 127.0.0.1 56122 | aplay -c1 -f S16_LE -r 8000 command. I could not hear any audio using both sockaudio.py and audio.py scripts. Are these supposed to work also locally on the Rpi when using a json config file ?

Final question: I understand that by using the nc and aplay method for listening to the audio, I can hear only what's happening on TS1. Does the sockaudio.py and audio.py allow to hear both timeslots at the same time ? If not, I guess I would have to plug in a USB sound card dongle, change the nc / aplay command for 56124, and send the resulting audio to the USB sound card dongle. Unless I missed something, and that the audio from both timeslots can be sent to the same sound card, with the audio from each TS on it's separate left and right channel ? I know this can be done with SDRangel, with can it be done with op25 ?

I'm sorry if this is a long post, and if there are some typos and grammatical errors in this post, since english is not my native language.

Thanks and 73s
Reply With Quote
  #227 (permalink)  
Old 01-28-2018, 11:04 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 458
Default

Quote:
Originally Posted by ve2vag View Post

I'm sorry if this is a long post, and if there are some typos and grammatical errors in this post, since english is not my native language.
Bah. Your command of the language is better than some native English speakers I know, who have no such excuse..

First, the errors you've mentioned in python (corruption, malloc failures, and so forth) are definitely not normal messages and indicate that something in the system is very much not quite right. This could be a hardware flakiness or a problem with the software installation. It's puzzling that things work OK sometimes. This fact could suggest that the software / libraries may be OK and that the problem may be due to hardware (overheating, etc). In any case the corruption messages (although they aren't necessarily the most helpful) are not pointing specifically to anything inside OP25. Without something specific we'd have no clue what to change to try to help the situation.

I haven't tested multi_rx with the sockaudio python stuff. It may be that Graham has more info about that particular combination, I don't know. As far as having the two timeslots feed into the same audio stream, this is something I'd planned to add but it's not yet done. Basically, you're saying you'd like to have the sound in stereo, with each dmr tdma timeslot going to a separate speaker (L and R).

Finally, could you please detail the problem you had with install.sh. It would be good if you could post the specific error(s) you've encountered, including the command(s) you ran and all replies...

73 de KA1RBI

Max
Reply With Quote
  #228 (permalink)  
Old 01-28-2018, 12:14 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 109
Default

Bill, WA8WG was running into similar python errors. All his Debian stretch based systems reported python errors. Ubuntu 14.04, DietPi, and Jessie worked without issues.
Reply With Quote
  #229 (permalink)  
Old 01-28-2018, 12:42 PM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

Thanks for the reply, Max. I used to be bilingual back in high school, but since I do not practice my english very often, I lost it quite a bit, but when I post in forums and such, it gives it the occasion of coming back a little.

The image I'm using right now on the Rpi3 is the latest K2DLS DV4mini image (dated november 2017), since I was using the Pi with a DV4mini AMBE dongle. With your reply, I'm starting to wonder if there is something in it that causes these problems. Before going any further, I found an empty microSD card in my things, and I'll try to start again with an entirely clean Raspbian image. I'll report back my the results later (maybe today).

As for the multi_rx.py/sockaudio.py stuff, you are absolutely right. It would be nice if each TS could be heard in their separate speaker (L and R).

Regarding the ./install.sh problems I had, I should have kept a log or something because I can't remember what they were. Too much things going on in my head right now, I guess... I'll try to recompile op25 on the fresh Raspbian Stretch image using that script, and will report back.

EDIT: I just saw Steve KB9MWR's reply regarding the python errors in Raspbian stretch. I was just downloading the latest Raspbian stretch clean image from the Raspberry Pi website... Hopefully, I still have somewhere a clean Raspbian Jessie image to test. Also, the K2DLS Raspbian image I was using is also based on Stretch. It could explain the python error messages I was getting.

Thanks and 73s

Last edited by ve2vag; 01-28-2018 at 12:45 PM.. Reason: Added sentence in last paragraph
Reply With Quote
  #230 (permalink)  
Old 01-28-2018, 5:03 PM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

OK, so I've found a clean Raspbian Jessie image, and have compiled op25 with the install.sh script.
Looks like I do not have the error messages anymore. However, I'm having problems with the audio. I do not have audio anymore with the nc / aplay command. ALSA is installed and running, and I've set the internal sound card of the PI to use the 3.5 inch jack instead of HDMI (using raspi-config). Tried also sockaudio.py and audio.py, and still no audio.

Can't say for sure if the problems I was having were related to the Raspbian image I was using (something interfering), or because it was based on Raspbian Stretch; but it seems related to stretch.

Thanks and 73s
Reply With Quote
  #231 (permalink)  
Old 01-28-2018, 5:25 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,268
Default

Quote:
Originally Posted by ve2vag View Post
OK, so I've found a clean Raspbian Jessie image, and have compiled op25 with the install.sh script.
Looks like I do not have the error messages anymore. However, I'm having problems with the audio. I do not have audio anymore with the nc / aplay command. ALSA is installed and running, and I've set the internal sound card of the PI to use the 3.5 inch jack instead of HDMI (using raspi-config). Tried also sockaudio.py and audio.py, and still no audio.

Can't say for sure if the problems I was having were related to the Raspbian image I was using (something interfering), or because it was based on Raspbian Stretch; but it seems related to stretch.

Thanks and 73s
Run the command "aplay -l" and see if it lists your audio card.

I've not experimented with multi_rx yet, but if there is something that needs doing to sockaudio let me know and I'll take a look.
Reply With Quote
  #232 (permalink)  
Old 01-28-2018, 7:00 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 109
Default

Quote:
Originally Posted by ve2vag View Post
EDIT: I just saw Steve KB9MWR's reply regarding the python errors in Raspbian stretch. I was just downloading the latest Raspbian stretch clean image from the Raspberry Pi website... Hopefully, I still have somewhere a clean Raspbian Jessie image to test. Also, the K2DLS Raspbian image I was using is also based on Stretch. It could explain the python error messages I was getting.

Thanks and 73s
I am not sure if that is still the case with Stretch, but I know Bill mentioned it to me a few weeks back.

From what you have posted above in your json file, you need to use the netcat method for audio.

pi@op25:~/op25/op25/gr-op25_repeater/apps $ python multi_rx.py -c cfg.json -v 5

Audio:
nc -kluvw 1 127.0.0.1 1 56122 | aplay -c1 -f S16_LE -r 8000

I used this to monitor DMR and it worked just dandy.

Last edited by kb9mwr; 01-28-2018 at 7:19 PM..
Reply With Quote
  #233 (permalink)  
Old 01-28-2018, 7:58 PM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

Quote:
Originally Posted by boatbod View Post
Run the command "aplay -l" and see if it lists your audio card.

I've not experimented with multi_rx yet, but if there is something that needs doing to sockaudio let me know and I'll take a look.
Thanks for your reply, Graham. Yes aplay -l does list the internal audio card. As for sockaudio, I've browsed thru all pages of the present topic an the other one about running op25 in a virtual machine, and I'm not sure how to use both this and audio.py locally from the same machine (RPi). I just would like to be able to monitor local DMR and Fusion repeaters directly from the Pi, and not remotely.

This is why I didn't try too much, since the nc / aplay command was working and I could listen on what was happening on timeslot 1 on a local DMR repeater. Would be nice however if it would be possible to monitor both timeslots at the same time, with each TS using a separate channel L and R). Don't think there is an easy way to do so right now, unless trying to use another nc / aplay command pointing to the port associated with TS2 (56124), and directing the audio from it to another sound card. My linux knowledge is somewhat limited, however, so I even don't now if this would be feasible as is.

Quote:
Originally Posted by kb9mwr View Post
From what you have posted above in your json file, you need to use the netcat method for audio.

pi@op25:~/op25/op25/gr-op25_repeater/apps $ python multi_rx.py -c cfg.json -v 5

Audio:
nc -kluvw 1 127.0.0.1 1 56122 | aplay -c1 -f S16_LE -r 8000

I used this to monitor DMR and it worked just dandy.
Thanks Steve. Yes that was the command I was using; however with the other Raspbian stretch image, I had to remove the second "1" in the nc part (the one between 127.0.0.1 and 56122) to make the audio work. I was getting no audio with that added "1". I didn't add it back to the command with the new Jessie image; could it be the reason why I don't get the audio now ? Will try adding it back and will report results.

Thanks and 73s
Reply With Quote
  #234 (permalink)  
Old 02-02-2018, 4:51 PM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

Quote:
Originally Posted by ve2vag View Post
Thanks for your reply, Graham. Yes aplay -l does list the internal audio card. As for sockaudio, I've browsed thru all pages of the present topic an the other one about running op25 in a virtual machine, and I'm not sure how to use both this and audio.py locally from the same machine (RPi). I just would like to be able to monitor local DMR and Fusion repeaters directly from the Pi, and not remotely.

This is why I didn't try too much, since the nc / aplay command was working and I could listen on what was happening on timeslot 1 on a local DMR repeater. Would be nice however if it would be possible to monitor both timeslots at the same time, with each TS using a separate channel L and R). Don't think there is an easy way to do so right now, unless trying to use another nc / aplay command pointing to the port associated with TS2 (56124), and directing the audio from it to another sound card. My linux knowledge is somewhat limited, however, so I even don't now if this would be feasible as is.



Thanks Steve. Yes that was the command I was using; however with the other Raspbian stretch image, I had to remove the second "1" in the nc part (the one between 127.0.0.1 and 56122) to make the audio work. I was getting no audio with that added "1". I didn't add it back to the command with the new Jessie image; could it be the reason why I don't get the audio now ? Will try adding it back and will report results.

Thanks and 73s
Well, for some reason, audio started working with the nc / aplay, but as I stated earlier, I had to remove the second "1" from the "nc" part (the "1" between 127.0.0.1 and 56122), to make it work. No audio when that "1" is added.

So the command I must use for audio to work is: nc -kluvw 1 127.0.0.1 56122 | aplay -c1 -f S16_LE -r 8000

Unfortunately, my local Fusion and DMR repeater's frequencies s are too wide spreaded (more than 2,4 MHz), I would have loved to setup multi_rx to monitor all of them,like a scanner. I could always try to also use 2 other rtl-sdr dongles I have (1st gen models without TXCO), will have to check out how to configure these, and if I could use the same outdoor antenna for all three.

Thanks and 73s
Reply With Quote
  #235 (permalink)  
Old 02-02-2018, 6:45 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,268
Default

I've looked at, and thought about the sockaudio/dmr problem quite a bit over the last couple days. Unfortunately I still don't have a good answer.

Background:
- the op25 voice decoders produce streams of raw pcm data that are streamed out over UDP sockets so they can be received and sent to an ALSA compatible audio interface and turned into something you can hear.
- in the case of P25 Trunking the audio comes out on a single UDP port, however with DMR it capable of decoding and sending both time slots simultaneously using two separate UDP ports
- sockaudio.py presently only support opening one UDP port. When run in a standalone environment (using audio.py as a front end) you can select which port number, so theoretically you could listen to either slot 0 or slot 1.
- nc | aplay is similarly only able to monitor a single udp port, much as with sockaudio.

What's Needed:
- While it's easy to simply run two instances of either audio.py or nc | aplay configured with the appropriate ports, this will still not immediately provide a workable solution since you'd have to have two independently addressable ALSA devices. (Once you open the alsa device in one application, you effectively loose access to it from anywhere else). There is probably a way to work around this by building a custom .asoundrc/asound.conf file with virtual device names and mixing of the output streams.
- The other way to solve the problem is to rework sockaudio so that it is capable of opening the two UDP sockets, receiving and interleaving the data then sending it out to a single ALSA device as stereo L/R samples. Practically speaking this is a non-trivial rewrite as it completely changes the application from simple block transfer of 320 byte frames into non-blocking reads that have to be interleaved while handling things when one or other stream starts/stops or simply isn't present.

My recommendation is to look at alsa mixing and see if you can set that up fairly easily, then just run two instances of nc | aplay until inspiration strikes and I think of a good way to make sockaudio do what it needs to do.
Reply With Quote
  #236 (permalink)  
Old 02-03-2018, 5:41 AM
Member
  Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Nov 2011
Location: Quebec Canada
Posts: 35
Default

Thanks Graham. I'll try tinkering around ALSA mixing, will have to do some trial and error to (hopefully) make it work, since I'm a linux newbie. 73s
Reply With Quote
  #237 (permalink)  
Old 02-13-2018, 4:55 PM
fredva's Avatar
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Mar 2007
Location: Virginia/West Virginia
Posts: 1,296
Default

Quote:
Originally Posted by fredva View Post
I'm pretty sure I'm experiencing frequency drift with my generic dongle. Even if I warm it up for 20-30 minutes before activating OP25, OP25 will work for awhile, then I start missing transmissions and get tuning errors. So I plan to get a NooElec NESDR Mini 2+ and hopefully it will perform better.
An update - I'm using a Nooelec Nano 3 dongle now and it works significantly better than the generic dongle. I had to invest some time determining the optimal frequency values, but once I hit them, the reception and decoding works consistently, whether I've just started up the Pi or if OP25 has been running for a day or so.

I'm fairly happy with where I'm at now, considering the clear decoding I'm getting on simulcast systems compared to a $400 scanner. The one thing I'd like to improve upon, if it would be possible, is the speed at which the the device locks onto a voice transmission. I'm currently monitoring a Motorola P25 simulcast system and a Harris P25 simulcast system. I realize there is going to be a delay due to switching between the control channels of the two systems. But it seems like there is an additional delay beyond that. If anybody has a suggestion on speeding things up, I would appreciate it.

Some data that might be relevant: I'm currently using a sample rate (-S) of 960000. I tried 2560000, but that didn't work - I guess the Pi couldn't handle that rate. I haven't tried anything between those numbers yet.

The Motorola system I'm monitoring has frequencies between ~770 and 779 mhz, plus a couple of frequencies in the 850 range. The control channels and most of the voice frequencies I see actually being used are generally between 770 and 774, sometimes no higher than 772. I've been using a center frequency of 773.

The Harris system has frequencies between 851 and 859. The control channel alternates every few days between two or three of those frequencies. The system makes use of all or nearly all of the available voice frequencies. I tried a center frequency of 854.0 but that didn't seem to speed up the scanning. I attempted to use 855.0, but it seemed like OP25 wouldn't pick up the transmissions at all. Currently I'm not specifying a center frequency for this system.
__________________
Mike
PRO-18 upgraded to a WS-1080, PRO-197, PRO-2020, PRO-2021, 436HP, Raspberry Pi SDR
Fire & EMS feeds: http://www.broadcastify.com/listen/feed/527 & http://www.broadcastify.com/listen/feed/3331
Reply With Quote
  #238 (permalink)  
Old 02-13-2018, 5:07 PM
dseven's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 304
Default

Quote:
Originally Posted by fredva View Post
The one thing I'd like to improve upon, if it would be possible, is the speed at which the the device locks onto a voice transmission. I'm currently monitoring a Motorola P25 simulcast system and a Harris P25 simulcast system. I realize there is going to be a delay due to switching between the control channels of the two systems. But it seems like there is an additional delay beyond that. If anybody has a suggestion on speeding things up, I would appreciate it.
That's where I'm at too. It seems to matter most during a conversation - I get the start of the first transmission OK, but often miss the first word or two of subsequent ones. It was discussed a bit some pages back in this thread.


Quote:
Some data that might be relevant: I'm currently using a sample rate (-S) of 960000. I tried 2560000, but that didn't work - I guess the Pi couldn't handle that rate. I haven't tried anything between those numbers yet.
I'm using 2048000 with a recent rtl-sdr.com R820T2 on a RPi3 - seems to be able to handle it OK. My RPi is running the "lite" version of Raspbian (no desktop, so no gnuplot).


Quote:
The Motorola system I'm monitoring has frequencies between ~770 and 779 mhz, plus a couple of frequencies in the 850 range. The control channels and most of the voice frequencies I see actually being used are generally between 770 and 774, sometimes no higher than 772. I've been using a center frequency of 773.

The Harris system has frequencies between 851 and 859. The control channel alternates every few days between two or three of those frequencies. The system makes use of all or nearly all of the available voice frequencies. I tried a center frequency of 854.0 but that didn't seem to speed up the scanning. I attempted to use 855.0, but it seemed like OP25 wouldn't pick up the transmissions at all. Currently I'm not specifying a center frequency for this system.
I think the center frequency is only really helpful if you can find one where the bandwidth (sample rate) centered on that frequency can cover all of the voice channels. Of course the control channel must be within that range, or you'll never get off the ground!
Reply With Quote
  #239 (permalink)  
Old 02-13-2018, 6:10 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 1,268
Default

You don't necessarily have to cover all the frequency range, but if you set the center frequency in a way that you can hit the most commonly used frequencies it may speed things up somewhat.

From what I've seen, it's about 400msec from the request to retune before re-locking the signal and starting successful decode. I've not studied exactly where the time is consumed, but it'd be fairly easy to do with some logging timestamps.
Reply With Quote
  #240 (permalink)  
Old 02-13-2018, 6:39 PM
dseven's Avatar
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 304
Default

Quote:
Originally Posted by dseven View Post
That's where I'm at too. It seems to matter most during a conversation - I get the start of the first transmission OK, but often miss the first word or two of subsequent ones. It was discussed a bit some pages back in this thread.
I lied - it was actually in this other thread
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 2:31 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions