Board index FlightGear Support Tools FGCom

Current changes vs. echo test issue

FGCom is a realtime voice communication system specially designed for FlightGear.

Current changes vs. echo test issue

Postby mickybadia » Sat Jul 25, 2015 9:13 am

Hi,
I am happy to see FGCom is evolving, and for better realism even. The phone book business was never really very satisfying to me, and I do encourage the free frq choice coming up. Thank you Kevin.

Question: Does this mean you will be working on the client yourself as well, to adjust it to the new expected behaviour?

I also have a question concerning a new issue, but I suspect it is a consequence of the changes the server is undergoing, which you could confirm.

Issue: Echo test is not working any more, while ATIS recording and normal frequency use seem still to. Has anything changed regarding command line options for instance? Example command presently executed for echo test:
Code: Select all
fgcom --frequency=910.000 --server=fgcom.flightgear.org --port=16665 --callsign=KSFOobs

Log output:
Code: Select all
FGCom 3.4.0 compiled Jan 20 2015, at 15:19:26
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered
Message: Call disconnected by remote


Perhaps we can someday have a chat once you have stabilised your choices and implementations, so that I make sure I do not miss anything and ensure a working, spec-compliant radio system in ATC-pie. Also, if Wolfram does not join for OpenRadar, I will sum everything up and send him any change he needs to make.
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Sat Jul 25, 2015 9:40 am

Thank you for the support. :)

mickybadia wrote in Sat Jul 25, 2015 9:13 am:Question: Does this mean you will be working on the client yourself as well, to adjust it to the new expected behaviour?

My knowledges are more advanced at C++ than Python so yes, I'll try to do it.

mickybadia wrote in Sat Jul 25, 2015 9:13 am:Issue: Echo test is not working any more, while ATIS recording and normal frequency use seem still to. Has anything changed regarding command line options for instance? Example command presently executed for echo test

I've just solved the issue, I forgot to remove something in the dialplan. Thank you for letting me know.
There is others bugs, I'm solving.

mickybadia wrote in Sat Jul 25, 2015 9:13 am:Perhaps we can someday have a chat once you have stabilised your choices and implementations, so that I make sure I do not miss anything and ensure a working, spec-compliant radio system in ATC-pie. Also, if Wolfram does not join for OpenRadar, I will sum everything up and send him any change he needs to make.

Good initiative, does ATC-pie support the recording of auto-informations message for AWOS and ASOS frequencies like ATIS? The FGCom client is already ready for this.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby mickybadia » Sat Jul 25, 2015 11:32 am

Saga wrote in Sat Jul 25, 2015 9:40 am:
mickybadia wrote in Sat Jul 25, 2015 9:13 am:Question: Does this mean you will be working on the client yourself as well, to adjust it to the new expected behaviour?

My knowledges are more advanced at C++ than Python so yes, I'll try to do it.

The thing is, if you create necessary changes to the client, FGCom is doomed for a while if you do not change it yourself. And if old clients keep working, you may have to wait until the new features are used at all... Do not hesitate to ask on the forum if you need help though.

Saga wrote in Sat Jul 25, 2015 9:40 am:does ATC-pie support the recording of auto-informations message for AWOS and ASOS frequencies like ATIS? The FGCom client is already ready for this.

ATC-pie is able to do whatever FGCom is, but I think it is FGCom that cannot do what you ask. As far as I know, the FGCom client (and server at the time) only considers recordable the frequencies containing "ATIS" in their description string. The reason is that the "recorded" frq type in the Xplane data includes ASOS, AWOS and ATIS while only ATIS should really be human-recorded. The poor trick to distinguish them was by searching through the names, which created bad things like EGKK string "Gatwick Information" not be regarded as ATIS.

I personally think AWOS/ASOS should not be human-recordable, but it is much less important to exclude them than to allow ATIS everywhere there is one. So I would vote for all "recorded" freqs (type 50 in Xplane) to be human-recordable, and if you open all '50's for recording, I will follow immediately with ATC-pie.
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Sat Jul 25, 2015 11:59 am

mickybadia wrote in Sat Jul 25, 2015 11:32 am:The thing is, if you create necessary changes to the client, FGCom is doomed for a while if you do not change it yourself. And if old clients keep working, you may have to wait until the new features are used at all... Do not hesitate to ask on the forum if you need help though.

That's the challenge!

mickybadia wrote in Sat Jul 25, 2015 11:32 am:ATC-pie is able to do whatever FGCom is, but I think it is FGCom that cannot do what you ask. As far as I know, the FGCom client (and server at the time) only considers recordable the frequencies containing "ATIS" in their description string. The reason is that the "recorded" frq type in the Xplane data includes ASOS, AWOS and ATIS while only ATIS should really be human-recorded. The poor trick to distinguish them was by searching through the names, which created bad things like EGKK string "Gatwick Information" not be regarded as ATIS.

I'm glad to tell you that it already works. :lol: I succeed to record a message on the AWOS 1 frequency of KSFO. See the status page and test by yourself.

mickybadia wrote in Sat Jul 25, 2015 11:32 am:I personally think AWOS/ASOS should not be human-recordable, but it is much less important to exclude them than to allow ATIS everywhere there is one. So I would vote for all "recorded" freqs (type 50 in Xplane) to be human-recordable, and if you open all '50's for recording, I will follow immediately with ATC-pie.

I don't know how AWOS/ASOS should really work, I've just read some wikipedia pages and I supposed, maybe I'm wrong, that it should be possible to record auto-information messages on them.
So as I said before, all the frequencies type 50 are "open". But if for AWOS/ASOS frequencies this is not the correct behaviour, we should not do that.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby mickybadia » Sat Jul 25, 2015 12:42 pm

Saga wrote in Sat Jul 25, 2015 11:59 am:So as I said before, all the frequencies type 50 are "open".

Are you sure?
Code: Select all
$ fgcom --airport=EGKK --atis=136.525 --server=fgcom.flightgear.org --port=16665 --callsign=EGKKobs
FGCom 3.4.0 compiled Jan 20 2015, at 15:19:26
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call rejected by remote


Saga wrote in Sat Jul 25, 2015 11:59 am:But if for AWOS/ASOS frequencies this is not the correct behaviour, we should not do that.

Probably debatable but I think it is better this way. As I said, nothing distinguishes auto-message freqs from human-message freqs, and relying on the description string has not proven to be a success. So again, I vote for invading the AWOS/ASOS freqs which would remain silent anyway instead of killing several ATIS freqs in the world (I have had reports against ATC-pie not working on ATIS frequencies that were actually rejected by FGCom, e.g. EGKK).
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Sat Jul 25, 2015 12:53 pm

I see what's going on. The database contains the frequency 136.52. for your airport and not 136.525. I removed the redirection xxx.xx5 -> xxx.xx0 because I didn't see the purpose. Do you know why?

mickybadia wrote in Sat Jul 25, 2015 12:42 pm:Probably debatable but I think it is better this way. As I said, nothing distinguishes auto-message freqs from human-message freqs, and relying on the description string has not proven to be a success. So again, I vote for invading the AWOS/ASOS freqs which would remain silent anyway instead of killing several ATIS freqs in the world (I have had reports against ATC-pie not working on ATIS frequencies that were actually rejected by FGCom, e.g. EGKK).

So be it. :)

EDIT: This is the file apt.dat.gz which is not enough accurate. Let me correct this.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby mickybadia » Sat Jul 25, 2015 4:23 pm

Just in case you consider the issue solved, I have been testing ATIS just now at Stuttgart (3-decimal ATIS freq) and here is what happened:
Code: Select all
FGCom 3.4.0 compiled Jan 20 2015, at 15:19:26
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Call 0 answered


The server does answer, but the usual countdown never comes. In contrast, the 1-decimal ATIS freq at LFPO did work fine.
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Sun Jul 26, 2015 9:49 am

I think I solved the problem yesterday at ~22h UTC. It was a tough issue, I had to review my Python code and build Asterisk from source.
By the way, I accidently removed a feature, we don't see the Echo-Test on the status page anymore. But I hesitate to let this like that.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby mickybadia » Sun Jul 26, 2015 10:30 am

I personally don't need to know who is echo testing lol. It can be useful to check one's self while testing, but if regular freqs are listed I think we have enough. So fine that way in my opinion.

As for the other issues mentioned here, everything is now working perfectly. Thank you very much. 1-, 2- and 3-decimal digit freqs working, sound seems improved, beep is better (it had got a little stressfully funny for some reason), live page is accurate and responsive. So thank you for all your appreciated work.

Two questions possibly to adapt my FGCom encapsulation:
- any spec for the allowed duration of a recording? (used to be 90 secs but I have felt that was reduced at some point)
- any spec for the time a recording stays on the server? (some seem to have been there for ages now)
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Sun Jul 26, 2015 1:52 pm

mickybadia wrote in Sun Jul 26, 2015 10:30 am:any spec for the allowed duration of a recording? (used to be 90 secs but I have felt that was reduced at some point)

I've just tested myself and it's still 90secs. Are you sure?

mickybadia wrote in Sun Jul 26, 2015 10:30 am:any spec for the time a recording stays on the server? (some seem to have been there for ages now)

Yes I didn't developed a feature to remove them automatically. How long it should be?
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby mickybadia » Mon Jul 27, 2015 12:25 pm

Saga wrote in Sun Jul 26, 2015 1:52 pm:Yes I didn't developed a feature to remove them automatically. How long it should be?

As I told you on Mumble---but people could have a different opinion here---I think a first implementation with 24 hrs is appropriate. Shorter could do, but I like the idea of enabling special events to be announced in advance for example. Longer is just useless, and will probably only end up being abused. You will want to shorten that as soon as you notice your storage space gets flooded with messages.

To see if we need a less intuitive proposition, 2 questions:
- how much space is available? (Stot)
- how much space takes a full 90-sec message? (Smsg)

I am counting N=2918 recordable frequencies. Do we have N * Smsg < Stot?
mickybadia
 
Posts: 394
Joined: Tue Sep 24, 2013 9:12 am

Re: Current changes vs. echo test issue

Postby Saga » Mon Jul 27, 2015 1:50 pm

Recordings are very light ~150KB for 90 secs (sampling of 9KHz, 16bits and mono of course). So let's take the extreme scenario, all the recordable frequencies have a message. Then, it takes in memory: 150*2918=437.7MB. So the space is not a problem at all.
And as you said, this is pointless to keep recordings more than 24 hours.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 2:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Re: Current changes vs. echo test issue

Postby Johan G » Tue Jul 28, 2015 7:32 pm

I have looked up the recommendations and regulations from the horse's mouth, so to speak, and have links to the resources with more information here. :)

Saga wrote in Sat Jul 25, 2015 11:59 am:I don't know how AWOS/ASOS should really work, I've just read some wikipedia pages and I supposed, maybe I'm wrong, that it should be possible to record auto-information messages on them.

For the USA the differences between them are outlined in the US Aeronautical Information Manual (AIM), section 7-1-12, "Weather Observing Programs" (AWOS/ASOS) and 4-1-13, "Automatic Terminal Information Service (ATIS)".

Somehow I have got the impression that AWOS and ASOS are US specific, though I might be wrong.


For the international situation see ICAO Annex 11, "Air Traffic Services", section 4.3 "Operational flight information service broadcasts"

Apparently there is also two services similar to ATIS but with slightly less information, HOFIS and VOFIS (HF and VHF operational flight information service).

I was a bit surprised you mentioned recording messages for VOR beacons, but apparently if there is little bandwidth for a discrete frequency for ATIS, it can be made available on most appropriate terminal navigation aids voice channel:
ICAO Annex 11, section 4.3.4.2 wrote:... If a discrete frequency is not available, the transmission may be made on the voice channel(s) of the most appropriate terminal navigation aid(s), preferably a VOR, provided the range and readability are adequate and the identification of the navigation aid is sequenced with the broadcast so that the latter is not obliterated.

In addition to these there is also VOLMET broadcasts on HF/VHF (see ICAO Annex 3, "Meteorological Service for International Air Navigation", section 11.6, "Use of aeronautical broadcasting service - contents of VOLMET broadcasts").

Edit: Somehow I was oblivious to that there are different kinds of ATIS services with slightly different information, for example for arrivals vs. departures.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5294
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit


Return to FGCom

Who is online

Users browsing this forum: No registered users and 3 guests

cron