WIP: Add support for DVSI AMBE3000 hardware codec devices #376
Conversation
Not fully functional yet. For example: - It only work with 8kHz audio at the moment - Error handling need to be improved - Serial protocol synchronization need to be done on startup
- Add more code documentation - Rename CodecVector type to Codecs - Use std::copy instead of for loop - Return AudioEncoderAmbe/AudioDecoderAmbe instead of AudioCodecAmbe objects when allocating encoders/decoders - Correct setup of fileds length indicator in the multi field Packet constructor
sm0svx
changed the title
|
Set up a simple svxlink<->remotetrx environment with ThumbDV (two sticks, one on SvxLink site the other on remotetrx site). Got the following error message on remotetrx: Program received signal SIGSEGV, Segmentation fault. SvxLink v1.6.99.9 |
|
Try now |
|
very well done, Tobias :) |
|
Maybe there is a new (or recent) problem with RemoteTRX. I've configured a Voter and a MultiTX on SvxLink and a RemoteTRX with VOX. Here is the RemoteTRX's logfile: Tue Mar 6 08:02:44 2018: RemoteTrx v1.2.99.2 Copyright (C) 2003-2015 Tobias Blomberg / SM0SVX 06.03.2018 08:03:02.751: 192.168.178.57:5400: RemoteTrx protocol version 2.7 As you can see, there is no "Tx1: Turning the transmitter ON" when the TX is going on and no "The squelch is CLOSED (NetDmrRx=xxx)" on SvxLink site when the SQL has been closed on RemoteTRX's site so the Tx on SvxLink's site remains on. The bold text shows the stop of remotetrx (with kill -9), after that the SQL was closing on SvxLink and it continues the normal behavior. |
|
Probably some problem with the flow control in the audio pipe. Does it work if you change to another codec? |
|
With the same config S16, OPUS and GSM seem to be ok. On SvxLink the log messages are normal (with TX is ON/OFF): |
|
BTW: Havn't changed the name of "NetDmrRx" to NetOpusRx or something like this, changed only the codec |
|
Ok. I'll have a look at it tomorrow. |
|
It should work better now |
|
unfortunately no. Some less audio is transmitting but then the SQL remains open as well as the PTT. The first try create a segfault (could not reproduce it later): |
|
Looks like communications with the DV3k dongle is getting out of synch, which is very strange. I've had my remotetrx running with an example config here (attached remotetrx-dv3k-test.conf.txt) for several days without a single problem. Please try that to see if you get the same error as with your own config. Handling communication failures with the dongle gracefully is still on the TODO-list so if communications is getting out of synch a failure like the one above is to be expected. I'd expect failures to be rare though but your setup seem to fail immediately which is very odd. From your screen dump it looks like you are running this on a normal intel based laptop. Is that so? |
|
Ahh, ok. I think I found my mistake. I was running it as a fullduplex remotetrx connected to my repeater. Will try it in a simplex environment. |
|
ok, with one RX it's working :) |
|
Ok, that's good but don't you think your first setup should work as well? You should be able to set up a NetTrx with one transmitter and one receiver and then use one codec dongle to handle both streams. The receiver is using the encoder part and the transmitter is using the decoder part. If this does not work there still is a bug in my code, right? |
|
I'm not sure what the problem is right now. Will set up it tomorrow again. |
|
It should not be a problem since SvxLink is single threaded. The two uses should not interfere with each other but it certainly looks like it does that anyway. As long as there is only one SvxLink/RemoteTrx process accessing the dongle it should be fine. In theory... |
|
OK, I've finally setup a new remotetrx and it's working :) Maybe that some old files/libs have influenced my installation. There is one issue if the thumbdv stick couldn't open: NetUplinkTrx: Client connected: 192.168.178.45:56336 Program received signal SIGSEGV, Segmentation fault. BTW: The audio quality between the stations is much better than expected and in my opinion the qso: |
|
That is good news! Interesting that you think audio quality is better than the real DMR stuff. It must be that the analogue audio path is not as good on your Hytera as it is on your other rigs. I guess it would not be as good if you have a weak signal in with a lot of noise. That would be hard work for the codec. I'll have a look at the segfault. It looks like a simple problem. You should also expect other problems since I've only implemented the bare minimum for you to have something to develop against. There are still error handling and timeouts missing. My test application ran for three or four days before it lost communication synchronization with the dongle and the code cannot handle that at the moment. |
|
I made my tests without Rf from the RemoteTRX side, only on side is a analgue repeater. If disturbances or noise are involved into the path the quality may decrease. But for the moment it's really great. But I have still the problem we discussed last weeks (maybe AudioSelector but not sure): |
No description provided.