Closed 24e2 closed 4 years ago
Yeah, I'm not super proud of that side of the code, but individual clients are tracked on that side using an incrementing integer, so as channels are opened and closed you should see higher numbers. the ar: ## is the number of currently active receiver channels.
Receive channels will be kept around idle for a time period to minimize flowgraph lock() and unlock() activity, as that is fairly disruptive...
Also, the P25 code should be fairly well tested, as I've run it for years on a dozen or so sites, the EDACS code is also well tested, the Motorola smartnet code is the least well tested, and might be kind of buggy on different systems (I noticed that for each new motorola smartnet system I added it would need tweaks, because of the weird way their protocol works).
Also, congrats, you are the first person who has mentioned they've gotten the code running!
Oh also, Re: end of transmission issues, I believe I eventually figured out that was an issue in OP25 itself... and I was using a modified version of OP25 that should be available on my github profile, although it's probably very out of date by now.
I believe I figured out that the way OP25 was buffering packets was not totally compatible with the way my code worked, and would leave off little bits of the buffer without my patch.
Cool, ill checkout your op25 stuff.. Thanks..
FYI I also added some stuff to op25 so I could track how many errors each transmission had to try to figure out which recording was "best" when something was recorded to multiple sites, it should be pretty obvious if you want to exclude it.
Very cool project.
Are these quit from clients normal with incrementing client numbers?
I am recording my p25 P1 audio, although it feels like the end of the transmission are being cut off. Need to get out a digital radio to compare.