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
  #1161 (permalink)  
Old 07-12-2017, 6:17 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 373
Default

Quote:
Originally Posted by whatradio View Post
Using nc | aplay setup at moment, but will definitely try your changes later.
Anyway, verbosity level 10, stderr output and some source code reading helped me to pin down the problem.
From what I see, phase1 and phase2 decoders each using a separate UDP connection, so first decoded audio grabs the nc UDP port, making it unable to receive another phase audio packets. So you either hear every p1 or every p2 conversation, on a first-come first-serve basis.. Perhaps sockaudio.py is handling connections differently, will take a look.
You are correct that p25p1_fdma and p25p2_tdma separately open their own UDP sockets, but the protocol is by it's nature connectionless so there shouldn't be any downsides of doing that since the receiving app will neither know nor care where the data originated.

Quote:
Originally Posted by whatradio View Post
boatbod, I've downloaded and built your changes, had to manually merge your rx.py code with some latest git changes though.

Both phase1 and phase2 audio works now, no more UDP problems, so sockaudio.py its definitely more robust and comfortable way to listen. Thank you for your work, good job! Hope your code get pushed to official git repository soon.
The primary difference in logical handling between nc | aplay and sockaudio is that the latter knows when to flush the pcm stream at the end of a transmission. In itself this shouldn't really change the handling of intermingled Ph1 and Ph2 transmissions, but the new code you are running also has subtle changes to the trunking logic to keep the radio tuned to a given phase 2 audio frequency during MAC_HANGTIME until the repeater notifies MAC_END_PTT. This allows more stable listening in cases where back to back chatter occurs on a given TGID on the same voice channel. Previously you'd see numerous re-tunes to the control channel and back again every time a subscriber released the PTT, even if momentarily prior to reacquiring. Practically it seems to add about 1-2 sec silence at the end of a conversation (depending on repeater configuration) but the overall listening experience is better. Unfortunately there is no equivalent Ph1 capability, so that re-tunes immediately on receipt of DUID3 or DUID15.
Reply With Quote
Sponsored links
  #1162 (permalink)  
Old 07-12-2017, 2:41 PM
Newbie
   
Join Date: Jul 2017
Posts: 4
Default

Quote:
You are correct that p25p1_fdma and p25p2_tdma separately open their own UDP sockets, but the protocol is by it's nature connectionless so there shouldn't be any downsides of doing that since the receiving app will neither know nor care where the data originated.
Agree, in theory UDP is supposed to be stateless fire-and-forget thing..

Launched Wireshark to check whats going on loopback network interface during "nc | aplay"

Phase1 packet, gets send by op25, received by nc and played by aplay just fine.
User Datagram Protocol, Src Port: 56366, Dst Port: 23456
Source Port: 56366
Destination Port: 23456
Length: 328
Checksum: 0xff5b [unverified]
[Checksum Status: Unverified]
[Stream index: 1]

Phase2 packet, sent but instantly followed by "Port unreachable" ICMP reply.
User Datagram Protocol, Src Port: 51252, Dst Port: 23456
Source Port: 51252
Destination Port: 23456
Length: 328
Checksum: 0xff5b [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0xd883 [correct]
[Checksum Status: Good]
Unused: 00000000
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 51252, Dst Port: 23456

Obviosly it can be other way around with P1/P2, depending on what comes first during OP25 session.
Reply With Quote
  #1163 (permalink)  
Old 07-12-2017, 5:00 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 373
Default

But you say the same is not true with sockaudio? Curious. My code (sockaudio) only opens the inbound udp socket once and keeps the handle going for the whole session. The nc | aplay appears to be opening/closing/reopening possibly based on aplay receiving an xrun.

whatradio: which options are you passing to nc? When I used to run it, this was my start script:
Code:
nc -kluv 127.0.0.1 23456 | aplay --buffer-size=1024 -c 1 -f S16_LE -r 8000

Last edited by boatbod; 07-12-2017 at 6:46 PM..
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 9:53 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, 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