Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POCSAG and usbradio makes PTT stuck ON #371

Open
eliggett opened this issue Jul 24, 2024 · 2 comments
Open

POCSAG and usbradio makes PTT stuck ON #371

eliggett opened this issue Jul 24, 2024 · 2 comments

Comments

@eliggett
Copy link

eliggett commented Jul 24, 2024

Greetings,

On my system I am using the usbradio channel driver with a simplex radio node. Not realizing that usbradio doesn't have POCSAG support, I issued the following test command, which caused the radio to hang keyed (transmitting silence on the air) until asterisk was killed.

; note, this is a single node system, node number is 617081
simplex900*CLI> rpt page 617081 600 123 A "test 123 de W6EL"
[2024-07-23 17:41:54.442] ERROR[288797]: chan_usbradio.c:1851 usbradio_text: Channel 617081: Cannot parse usbradio cmd: PAGE 600 123 A  test 123 de W6EL
simplex900*CLI> radio unkey ; does not work
simplex900*CLI>

There are really three requests here.

1: Don't route POCSAG to chan_usbradio since it does not support paging yet. This can possibly be prevented here, in rpt_cli.c.

2: Modify the error handling from chan_usbradio so that if it receives a text command that it doesn't understand, something makes sure the channel driver isn't keyed up. I don't really understand why it keys up to begin with but this is just my own unfamiliarity with the code. Adding this level of fault protection may end up helping other use cases too. Ie, if we don't understand the text command, we report this, and, if something told us to key up, that thing is told to stop keying.

3: Eventually, add POCSAG to chan_usbradio, because it's so cool. With my 900 MHz node, I am tempted to get some of those inexpensive pagers and try it out.

Thank you all for your hard work on ASL, I love it!!

Version: Asterisk 20.8.1+asl3-3.0.2-1.deb12
using ASL3's Pi image

--E
de W6EL

@KB4MDD
Copy link
Collaborator

KB4MDD commented Jul 29, 2024

I have confirmed this issue on my install.

k4mdddevelop*CLI> rpt page 2231 600 123 T test
[2024-07-29 09:41:41.706] DEBUG[88692]: channel.c:4799 ast_sendtext_data: Thread LWP 88692 is blocking 'Radio/usb_2231', already blocked by thread LWP 88688 in procedure ast_waitfor_nandfds
[2024-07-29 09:41:41.706] ERROR[88692]: chan_usbradio.c:1830 usbradio_text: Channel usb_2231: Cannot parse usbradio text: PAGE 600 123 T  test

My device was also hung in transmit.

@KB4MDD
Copy link
Collaborator

KB4MDD commented Aug 6, 2024

This is caused by the incomplete implementation of paging in chan_usbradio. chan_usbradio is not sending an end of page text message to drop out of transmit.

I will remove chan_usbradio from paging until this can be fully implemented.

KB4MDD added a commit that referenced this issue Aug 6, 2024
This updates app_rpt to address a crash that occurred when using the rpt page command.

ast_sendtext should not require locking according to the documentation, but that does not seem to be the case. In some instances, the main processing loop had control of the channel. ast_sendtext would cause an assert abort in channel.c.

This was shown by the message ast_sendtext_data: Thread LWP 88692 is blocking 'Radio/usb_2231', already blocked by thread LWP 88688 in procedure ast_waitfor_nandfds.

Adding rpt_mutex_lock around ast_sendtext resolved the problem.

Corrected an if statement in the same routine that was already flagged in the code as a bug.

Remove chan_usbradio as a destination for paging.  chan_usbradio does not implement paging. Sending pages to chan_usbradio resulted in a stuck PTT.

Applied coding standards to the routine.

This closes #375 and #371.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants