Open g4klx opened 5 years ago
Hello!! I have the picture download and upload working all right now.. I implemented somewhat fail-safe code.
Also I build Mode 1 decoding to implement Voice uploading and I get Voice Message uploading working, but when I download voice messages in Mode 2 format, equipment want Mode 1 audio and not Mode 2 audio. So, I must change Voice Message implementation to use Mode 1 instead Mode2, as I realise by reverse engineering. I think as I managed to work with mode 1 decoding I could build mode 1 Encoding... ;-)
You can watch the code in github, sorry because is long and complex. Next I will build a command line program to manage news (add, delete, change type) and some php code to manage news from the dashboard. Then I will factorize the code and I will port the news support code to ysfgateway.
I will use Telegram or a server to distribute news. along all connected nodes.
But bear in mind, that MMDVMHost need patching because STM32 modem lost Header of packets that have little time sync or that are very near ones from others as they are generated by Yaesu transmitter when Pictures are uploaded.
Take Care Manuel
I want to use the YSF2DMR module to create a bridge between a fusion repeater and a fixed DMR Talkgroup. This bridge MUST ignore all WiresX and also not repeat data packets on the mode they are received on. ie RF from the repeater does NOT go back out RF as it causes looping. and any data packets received on the net only go out RF(This appears OK)
Currently I cannot stop YSF RF data from going back out RF. Is there a setting I can adjust??? Phil VE3RD
We need to modify the gateway to respond to a Wires-X command to link to a YSF2xxx program with a Wires-X Disconnect to the user and then a Wires-X Connect to the YSF2xxx. The former is easy to achieve, simply call m_wiresX->processDisconnect() but the connect is more complex. It needs to appear to come from the user and the gateway doesn't create Wires-X Connects as it only replies to them normally.
We need to get a dump of a Wires-X Connect and then create a new function for it, and remember to send it from the YSF Network to the correct YSF2xxx program rather than to the user. I may have such a dump at home but a new one would be nice. Failing that, reverse engineering my own Wires-X Connect handler is probably an easy option.
The individual reflectors have a new flag added to them to indicate that they are Wires-X capable, and this is only set for the YSF2xxx programs.
The branch YSF2xxx has been created for developing this capability.