----- Forwarded Message -----
Sent: Tuesday, January 7, 2025, 1:50:23 PM ESTSubject: Re: [op25-dev] TX Support
Should be straightforward to sectionalize this problem but will need your help - we'll assume for the moment there's been no regression (bug introduced). If your HackRF has not been stabilized (using GPSDO or other), I'd guess there could be a frequency-offset error between TX and RX - probably sufficent to cause RX failure.
Can you run one of the RX apps (rx.py or multi_rx.py) and enable the "datascope" (eye pattern diagram), and attach a copy of that plot...
Max On Tuesday, January 7, 2025, 12:26:32 PM EST, absi.joey(a)gmail.com <absi.joey(a)gmail.com> wrote:
Hey there,
I was testing the P25 Tx support of OP25 with a hackrf but I am encountering strange behavior.
I am able to transmit "something" with the hackrf using the cmd:
./dv_tx.py -p p25 --args 'hackrf' -f ./test.wav -Q 145000000 -q 0 --gains 'RF:0,IF:20'
On SDR# (img: https://ibb.co/C58Q592) I am getting signal so something is being transmitted but the squelch won't open. Even when disabling squelch I am getting a signal (that seems distorted/noisy), check at DSD+ Source Audio window (img: https://ibb.co/mJJy3J0). I tried lowering the gain but the signal is still "noisy" so I figured I would ask the experts over here.
Thanks
Hey there,
I was testing the P25 Tx support of OP25 with a hackrf but I am encountering strange behavior.
I am able to transmit "something" with the hackrf using the cmd:
./dv_tx.py -p p25 --args 'hackrf' -f ./test.wav -Q 145000000 -q 0 --gains 'RF:0,IF:20'
On SDR# (img: https://ibb.co/C58Q592) I am getting signal so something is being transmitted but the squelch won't open. Even when disabling squelch I am getting a signal (that seems distorted/noisy), check at DSD+ Source Audio window (img: https://ibb.co/mJJy3J0). I tried lowering the gain but the signal is still "noisy" so I figured I would ask the experts over here.
Thanks
Hello OP25 devs,
I'm an amateur radio operator working on implementing an open source DMR tier
3 trunked radio base station based on a multi-carrier SDR structure. I have
reached a point where I no longer know how to interpret the ETSI standard and
I thought to ask for help here due to your expertise with trunked radio
systems.
The outbound Reverse Channel PDU is used in DMR tier 3 for MS power control
and MS de-key (transmit interrupt). Based on my interpretation of the
standard, a couple of things are clear:
1. Reverse channel is only available if aligned timing is used
2. It is supposed to be embedded in voice burst F of a voice transmission on
the alternate timeslot
3. The MS is supposed to monitor the alternate timeslot during transmit and
derive RC information from it
There are a few scenarios where it seems to me these tier 3 services (power
control, priority interrupt) cannot be available at all...
1. Alternate timeslot is a control channel
2. Alternate timeslot is idle
3. Alternate timeslot carries something other than voice payloads
The standard doesn't clarify these cases and I have doubt that these 2
services can even be reliably implemented.
Are you able to help me understand how the Reverse Channel is used in the real
world by existing industry implementations of DMR tier 3?
Thanks,
Adrian YO8RZZ
Happy New Year!
Has anyone worked on demodulating H-CPM?
This is the modulation used by the SU when transmitting in an APCO P25 Phase II system.
Thanks Osmocom for all the pioneering SDR work you have done!
Dear Osmocom community,
while many people with a long history in FOSS development have no issues
at all with mailing lists as primary form of engaging with their
community, they have undoubtedly fallen out of fashion in favor of
various chat/messaging systems or web based forums.
In Osmocom, we've just launched an installation of the discourse forum
software available at https://discourse.osmocom.org/ providing an
alternative to our traditional mailing lists at https://lists.osmocom.org/
We're looking forward to see whether this web-based approach will
facilitate more and/or other people to engage with the Osmocom
developer/contributor community.
Feel free to join and get the discussions started. If there's a need
for more categories or sub-categories, just let one of the moderators
know and we can help with that.
The old mailing lists will continue to remain available for those who
prefer them.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
LRK Geovision LLC is a supplier of multi products. They are valuable <a href="https://lrkgeovision.us/product/clay-liner-suppliers/">Clay Liner suppliers</a> for their clients. They give special attention to the product
Minor request.
It multi_rx.py it is difficult to find other issues because of messages regarding unsupported TSBK opcodes. It isn't hurting but just filling the log. Not sure how best to report these (increase the log level?).
Examples in my case are as below:
received unsupported TSBK opcode 30 (b00000040000000033200000)
received unsupported TSBK opcode 38 (b800080c2e000c2e00010000)
received unsupported TSBK opcode 14 (9400000165ffff3125d70000)
I understand the need to know about these but it isn't helpful to have the log filling up with these.
Kevin
Hi all!
[please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if
there is any discussion, we don't want to drag it over tons of mailing
lists in parallel]
Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody
noticed the ticket or had any comments to it.
So let me post this as RFC here on the mailing list:
In the past, we had a gitolite/gitosis setup, which was fine in the
early days of git, but it means that people cannot easily create new
repositories, see who has permissions, and we cannot delegate ownership.
Even updating SSH keys requires manual interaction of a sysadmin like
me.
I would therefore suggest to migrate git.osmocom.org to gitea[1]
This would allow the following features:
* users can self-create any number of personal repositories (like gitlab/github)
* we can create 'organizations' along the line of reasonably independent
osmocom member projects like op25, who can then manage their own
repos/permissions/...
* gitea can link to redmine wiki and redmine issue trackers (rather than
using its own built-in)
For those repositories hosted in gerrit (mainly CNI), we would still
keep git.osmocom.org a read-only mirror, like we do it right now.
For those repositories not hosted in gerrit, users/projects could then
accept merge requests in gitea. Coupling this with 3rd party
authentication via github/gitlab/etc should make it easier for the
occasional contributor to submit changes.
There is a downside, of course; A lot of repo URLs have to change. Most
of our current repositories are at git.osmocom.org/project.git while
gitea follows a git.osmocom.org/organization/project.git scheme. I'm not
sure there is any way to help to mitigate this...
Any thoughts, comments?
[1] https://gitea.io/
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
support receiving signals from the OS? For example, SIGUSR1 might
re-read the list of white-listed talkgroups.
We have a countywide fire dispatch talkgroup, plus a number of
fireground channels. I'm imagining a simple web interface that would
rewrite whitelist.tsv and then send SIGHUP or SIGUSR1 to rx.py so it
reloads the configuration. If we don't need to hear the incident on
fireground 2, the end-user can easily "nuisance delete" that talkgroup
from the web interface. Alternatively, maybe we start with all the
fireground channels muted and use the web interface to un-mute the
one(s) we want to listen to.
--
_
| |
|-|
| |pu <apu(a)spfld.com>
http://www.spfld.com/
--cz8u4a15S3Z8xhXIANZsSIz-PwimiGtKD0DIZFM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>
<body style="background-color: #fff;">
<span style="display:none"> </span>
<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id="ygrp-mlmsg" style="position:relative;">
<div id="ygrp-msg" style="z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->
<div id="ygrp-text" >
<p>Graham,<br>
<br>
Thanks for all your hard work on updating and adding new features to op25.<br>
<br>
