Again, I’m not sure I’m asking the question in the best place - but here goes:
I’m running Allstar via a Wouxun handheld and one of G7RPG’s nodes - which comprises an R_Pi 3 (Asterisk, Allmon 2 and Supermon) and a Baofeng BF888. This links via my wifi to the internet, and can be controlled either via dtmf codes from the radio or from Supermon 6.2+.
The software is fully up-to-date (as of yesterday).
When making contacts via Allstar, I’m getting audio drop-out on my transmissions.
I’ve checked the radio - it’s set on low power (so 1W), narrow FM and 12.5kHz channel spacing. Looking at my signals on the Hubnet audio monitor shows peak levels around -10dB, so I’m confident I’m not over-driving anything. I don’t have any problems with received audio from other stations, but having reviewed the recording (Hubnet Listen Again facility) of a conversation I had with HG5CMH the other day, it’s very obvious that my signal has irregular drop-outs losing perhaps a second or more of audio each time.
I’ve listened to a recording of my outgoing signal (using my scanner and its related software) whilst transmitting to the parrot server - the recording from the scanner had no signs of drop-out during my transmission, but the playback from the parrot (also recorded via the scanner) showed one or more drop-outs in my audio as received by the parrot. That said, I’ve tried the parrot again and got no drop-out - so it’s not consistent.
I should note that everything is rather close together here - I’m sitting beside the node, and the wifi hub is maybe 10 feet away - is there a possibility that RF from the radio could be overloading something?
I’d welcome any suggestions for things to try next!
You may be falsify DTMF decode. Look at the CLI and logged in with asterisk -r… talk into the radio and as you recite something sufficiently long see if snd digits are decoding
Thanks for that. I did as you suggested - but didn’t see anything unexpected on the cli, even though I did still get (sometimes very short) dropouts in the playback after transmitting to the M0HOY Parrot test server. I then sent a couple of dtmf codes across the parrot - just to see the kind of response I was looking for. The pick-up of dtmf codes (I now see) is easy to identify - and I definitely didn’t get any.
I have no details for the link between the radio and the R-Pi - all I can tell you is that is (apparently) a USB sound card which has been modified by hard-wiring the mic and speaker connections directly to the PCB of the radio, and there’s also a hard-wired connection between the ground on the radio and the ground on the R-Pi. As I understand it, there are probably hundreds of G7RPG’s nodes in use - I haven’t heard of any problems, so I’m guessing my difficulty arises elsewhere in my local system. I’ll drop Peter an email to see if he has any advice to offer.
Busy day yesterday, so didn’t get back to the testing till today.
I’ve run a series of tests using the parrot. In order to make it easier to spot drop-outs (as distinct from pauses in speech, etc.) I ran a constant audio signal (from a morse oscillator) alongside the audio - effectively a constant amplitude carrier.
I did three separate tests, each run twice:
Firstly, using the normal wifi connection from the node to my plusnet hub - and, sure enough, got quite a number of drop-outs each time (they’re easy to see if you look at the audio waveform using Audacity).
Secondly, I connected to the internet using my Android phone as a wifi hotspot - thus eliminating the plusnet hub from the equation altogether (the R-Pi is the only common factor now) - and again got quite a number of drop-outs.
Finally, I used an ethernet link into the plusnet hub - thus eliminating the wifi link from the node to the hub - and there were no drop-outs.
It therefore appears that there is a problem of some sort in the wifi provision on the R-Pi.
I’m not sure there’s a lot I can do about that - so I’ll tidy things up and see if I can get another ethernet cable under the floorboards!
I should mention that I’ve had great support from Peter, who supplied the node - I’ve updated him with this info as well - we’ll see if he has any further ideas.
In the meantime, further suggestions welcome.
Many thanks for your input.
I mentioned that for a check because most do not think of or can easily measure interference on the wifi spectrum. Most meters do not measure signal strength but packet rejection. Just like your Cell signal meter on your phone. No way to see noise in that from cfl ballasts etc.
Audio in app_rpt is not very tolerant to dropped packet/packet collisions because the stream become time sensitive and you will run out of buffer quick.
And more and more folks have additional wifi junk in their house starting with streaming TV dongles that may even be your neighbors along with microwave ovens etc.
So if you test with wire, that should give you a better indication where to look before you start adjusting anything.
Thanks for that - and it’s a good point. There are a few gadgets connected wirelessly through our plusnet hub (split across 2.4GHz and 5GHz) and there are quite a few more wifi systems in the local area, any of which could have an impact, I suppose.
Anyway, I’ve got the ethernet cable in place, and I had excellent audio reports over Allstar yesterday - so I’ll park it for now. It works, and I’m happy enough with that.
Thanks for the support, everyone - much appreciated!
Are you using an actual usb radio interface like a Masters Comm RA40 or a modified headphone sound dongle I have seen advertised for around $5 on the internet.
Is your USB interface using a CM119 or CM108?
As noted in the earlier discussions, the interface is an RPi with a USB fob suitably modified, linked to a Baofeng 888.
What CM119 and CM108 are, I have no idea (sorry - my ignorance).
The Wifi link was via the RPi, and it transpired that the local wifi was the problem.
Since changing to a hard-wired ethernet link to the hub, I’ve had no further problems, so I regard the issue as resolved.