From: Torsten D. <To...@t3...> - 2014-02-28 11:16:03
|
Hi, I have just push a somewhat bigger patch to replace the current ATIS subsystem by something more configurable. Along with that comes a new comm-radio subsystem to provide some information about the received station. * With the new ATIS system it is now possible to code region and even airport specific atis styles. These styles are defined in FGDATA/ATC/atis.xml and FTDATA/ATC/atis/*.xml. * The phraseology is no longer hardcoded but stored as localized strings in FGDATA/Translations/*/atc.xml (Currently, only english phraseology is implemented). * The ATIS is no longer generated from the weather at the current aircraft position but encoded from the METAR data for the tuned ATIS station. For that, real-weather (live data in the gui) has to be selected. As a fallback, if no live weather data is configured, I will add the old behaviour soon. * The comm-radio subsystem provides some geographic and station specific information about the nearest station for the given frequency. The property tree under /instrumentation/comm[x] now shows e.g. distance, station name, station type, bearing, and airport id. To make use of the new features, I have added a comm radio subsystem to the generic instrumentation file at FGDATA/Aircraft/Generic/generic-instrumentation.xml - however, if an aircraft has defined it's own instrumentation set, please add the following <comm-radio> <name>comm</name> <number>0</number> </comm-radio> for the first comm radio and eventually more with increasing numbers. Please report, if I broke anything. I am planning to merge the radio implementation of the comm radio, the navradio and the newnavradio code so they all use the same codebase wherever possible. Eventually, I'll also touch ATC/trafficcontrol.?xx to better integrate that into the radio code and remove the hardcoded phraseology. I am also planning to use parts of the radio propagation code from adrian to provide a better computation of the signal quality. Cheers, Torsten |
From: Михаил С. <soi...@gm...> - 2014-03-01 14:10:08
|
Hi! How to check new system? I have inserted 2 <comm-radio> definition in my custom instrumentation (copy-pasted from generic), tuned on frequency listed as ATIS in airport selection window, but properties in tree /instrumentation/comm do not show anything. 2014-02-28 15:24 GMT+04:00 Torsten Dreyer <To...@t3...>: > Hi, > > I have just push a somewhat bigger patch to replace the current ATIS > subsystem by something more configurable. > Along with that comes a new comm-radio subsystem to provide some > information about the received station. > > * With the new ATIS system it is now possible to code region and even > airport specific atis styles. These styles are defined in > FGDATA/ATC/atis.xml and FTDATA/ATC/atis/*.xml. > > * The phraseology is no longer hardcoded but stored as localized strings > in FGDATA/Translations/*/atc.xml (Currently, only english phraseology is > implemented). > > * The ATIS is no longer generated from the weather at the current > aircraft position but encoded from the METAR data for the tuned ATIS > station. For that, real-weather (live data in the gui) has to be > selected. As a fallback, if no live weather data is configured, I will > add the old behaviour soon. > > * The comm-radio subsystem provides some geographic and station specific > information about the nearest station for the given frequency. The > property tree under /instrumentation/comm[x] now shows e.g. distance, > station name, station type, bearing, and airport id. > > To make use of the new features, I have added a comm radio subsystem to > the generic instrumentation file at > FGDATA/Aircraft/Generic/generic-instrumentation.xml - however, if an > aircraft has defined it's own instrumentation set, please add the following > <comm-radio> > <name>comm</name> > <number>0</number> > </comm-radio> > for the first comm radio and eventually more with increasing numbers. > > Please report, if I broke anything. > > I am planning to merge the radio implementation of the comm radio, the > navradio and the newnavradio code so they all use the same codebase > wherever possible. Eventually, I'll also touch ATC/trafficcontrol.?xx to > better integrate that into the radio code and remove the hardcoded > phraseology. > > I am also planning to use parts of the radio propagation code from > adrian to provide a better computation of the signal quality. > > Cheers, > Torsten > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Torsten D. <To...@t3...> - 2014-03-01 19:20:42
|
Hi, sounds like it should be working. Just to make sure: you have compiled fg from latest git and also pulled fgdata? To check if it's working, try the SenecaII (--aircraft=SenecaII). I have also just added the new comm to our C172p, you might also check that aircraft. Torsten Am 01.03.14 15:10, schrieb ?????? ????????: > Hi! > > How to check new system? > I have inserted 2 <comm-radio> definition in my custom instrumentation > (copy-pasted from generic), tuned on frequency listed as ATIS in > airport selection window, but properties in tree /instrumentation/comm > do not show anything. > > > 2014-02-28 15:24 GMT+04:00 Torsten Dreyer <To...@t3... > <mailto:To...@t3...>>: > > Hi, > > I have just push a somewhat bigger patch to replace the current ATIS > subsystem by something more configurable. > Along with that comes a new comm-radio subsystem to provide some > information about the received station. > > * With the new ATIS system it is now possible to code region and even > airport specific atis styles. These styles are defined in > FGDATA/ATC/atis.xml and FTDATA/ATC/atis/*.xml. > > * The phraseology is no longer hardcoded but stored as localized > strings > in FGDATA/Translations/*/atc.xml (Currently, only english > phraseology is > implemented). > > * The ATIS is no longer generated from the weather at the current > aircraft position but encoded from the METAR data for the tuned ATIS > station. For that, real-weather (live data in the gui) has to be > selected. As a fallback, if no live weather data is configured, I will > add the old behaviour soon. > > * The comm-radio subsystem provides some geographic and station > specific > information about the nearest station for the given frequency. The > property tree under /instrumentation/comm[x] now shows e.g. distance, > station name, station type, bearing, and airport id. > > To make use of the new features, I have added a comm radio > subsystem to > the generic instrumentation file at > FGDATA/Aircraft/Generic/generic-instrumentation.xml - however, if an > aircraft has defined it's own instrumentation set, please add the > following > <comm-radio> > <name>comm</name> > <number>0</number> > </comm-radio> > for the first comm radio and eventually more with increasing numbers. > > Please report, if I broke anything. > > I am planning to merge the radio implementation of the comm radio, the > navradio and the newnavradio code so they all use the same codebase > wherever possible. Eventually, I'll also touch > ATC/trafficcontrol.?xx to > better integrate that into the radio code and remove the hardcoded > phraseology. > > I am also planning to use parts of the radio propagation code from > adrian to provide a better computation of the signal quality. > > Cheers, > Torsten > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate > reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > <mailto:Fli...@li...> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Михаил С. <soi...@gm...> - 2014-03-01 19:39:23
|
It's working. I have all latest things, but I didn't powered new comm radio via power-btn and power-good, like in this commit: https://gitorious.org/fg/fgdata/commit/b16dc2c7afc80624480489497b1b21643d46328e May be latest commit to C172P needs this properties too? 2014-03-01 23:20 GMT+04:00 Torsten Dreyer <To...@t3...>: > Hi, > > sounds like it should be working. > Just to make sure: you have compiled fg from latest git and also pulled > fgdata? > > To check if it's working, try the SenecaII (--aircraft=SenecaII). > I have also just added the new comm to our C172p, you might also check > that aircraft. > > Torsten > Am 01.03.14 15:10, schrieb Михаил Сойтанен: > > Hi! > > How to check new system? > I have inserted 2 <comm-radio> definition in my custom instrumentation > (copy-pasted from generic), tuned on frequency listed as ATIS in airport > selection window, but properties in tree /instrumentation/comm do not show > anything. > > > 2014-02-28 15:24 GMT+04:00 Torsten Dreyer <To...@t3...>: > >> Hi, >> >> I have just push a somewhat bigger patch to replace the current ATIS >> subsystem by something more configurable. >> Along with that comes a new comm-radio subsystem to provide some >> information about the received station. >> >> * With the new ATIS system it is now possible to code region and even >> airport specific atis styles. These styles are defined in >> FGDATA/ATC/atis.xml and FTDATA/ATC/atis/*.xml. >> >> * The phraseology is no longer hardcoded but stored as localized strings >> in FGDATA/Translations/*/atc.xml (Currently, only english phraseology is >> implemented). >> >> * The ATIS is no longer generated from the weather at the current >> aircraft position but encoded from the METAR data for the tuned ATIS >> station. For that, real-weather (live data in the gui) has to be >> selected. As a fallback, if no live weather data is configured, I will >> add the old behaviour soon. >> >> * The comm-radio subsystem provides some geographic and station specific >> information about the nearest station for the given frequency. The >> property tree under /instrumentation/comm[x] now shows e.g. distance, >> station name, station type, bearing, and airport id. >> >> To make use of the new features, I have added a comm radio subsystem to >> the generic instrumentation file at >> FGDATA/Aircraft/Generic/generic-instrumentation.xml - however, if an >> aircraft has defined it's own instrumentation set, please add the >> following >> <comm-radio> >> <name>comm</name> >> <number>0</number> >> </comm-radio> >> for the first comm radio and eventually more with increasing numbers. >> >> Please report, if I broke anything. >> >> I am planning to merge the radio implementation of the comm radio, the >> navradio and the newnavradio code so they all use the same codebase >> wherever possible. Eventually, I'll also touch ATC/trafficcontrol.?xx to >> better integrate that into the radio code and remove the hardcoded >> phraseology. >> >> I am also planning to use parts of the radio propagation code from >> adrian to provide a better computation of the signal quality. >> >> Cheers, >> Torsten >> >> >> ------------------------------------------------------------------------------ >> Flow-based real-time traffic analytics software. Cisco certified tool. >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> Customize your own dashboards, set traffic alerts and generate reports. >> Network behavioral analysis & security monitoring. All-in-one tool. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Flightgear-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: Torsten D. <To...@t3...> - 2014-03-01 19:45:58
|
Am 01.03.14 20:39, schrieb Михаил Сойтанен: > It's working. I have all latest things, but I didn't powered new comm > radio via power-btn and power-good, like in this commit: > https://gitorious.org/fg/fgdata/commit/b16dc2c7afc80624480489497b1b21643d46328e Great, good to know it's not only working on my machine! > > May be latest commit to C172P needs this properties too? No, she already has everything she needs. The Seneca was a bit out of date, though and the mentioned commit got her back on track. Torsten |
From: Михаил С. <soi...@gm...> - 2014-03-01 19:50:46
|
I will do atis/xxx.xml for Russia and send to you. Another dumb question: whether there should be on-screen ticker with current ATIS? 2014-03-01 23:45 GMT+04:00 Torsten Dreyer <To...@t3...>: > Am 01.03.14 20:39, schrieb Михаил Сойтанен: > > It's working. I have all latest things, but I didn't powered new comm > > radio via power-btn and power-good, like in this commit: > > > https://gitorious.org/fg/fgdata/commit/b16dc2c7afc80624480489497b1b21643d46328e > Great, good to know it's not only working on my machine! > > > > May be latest commit to C172P needs this properties too? > No, she already has everything she needs. The Seneca was a bit out of > date, though and the mentioned commit got her back on track. > > Torsten > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Clement de l'H. <cl...@ho...> - 2014-03-02 10:02:32
|
Hi Torsten, I'm glad to see that radio code has been improved, however it seems that 8.33KHz frequency spacing support is not implemented. Do you plan to implement it ? Robin Peel has started to accept 8.33KHz freq and our apt.dat.gz has some of them: Found a 8.33KHz freq: 16WA - 135.180 Found a 8.33KHz freq: 39WA - 135.180 Found a 8.33KHz freq: 7WA4 - 135.180 Found a 8.33KHz freq: EBAV - 123.430 Found a 8.33KHz freq: EBCF - 125.880 Found a 8.33KHz freq: ED09 - 130.130 Found a 8.33KHz freq: ED11 - 129.980 Found a 8.33KHz freq: EDAR - 118.630 Found a 8.33KHz freq: EDCQ - 123.380 Found a 8.33KHz freq: EDFA - 121.030 Found a 8.33KHz freq: EDFB - 120.430 Found a 8.33KHz freq: EDFE - 118.780 Found a 8.33KHz freq: EDFE - 121.730 Found a 8.33KHz freq: EDFM - 129.780 Found a 8.33KHz freq: EDMT - 122.830 Found a 8.33KHz freq: EDMW - 122.030 Found a 8.33KHz freq: EDOX - 123.480 Found a 8.33KHz freq: EDWL - 122.030 Found a 8.33KHz freq: EDWU - 119.830 Found a 8.33KHz freq: EDXW - 120.230 Found a 8.33KHz freq: EGFF - 132.480 Found a 8.33KHz freq: EGHE - 124.880 Found a 8.33KHz freq: EGHN - 119.280 Found a 8.33KHz freq: EGLD - 130.730 Found a 8.33KHz freq: EGMD - 129.230 Found a 8.33KHz freq: EGMD - 128.530 Found a 8.33KHz freq: EGNE - 130.480 Found a 8.33KHz freq: EGNF - 123.280 Found a 8.33KHz freq: EGNJ - 119.130 Found a 8.33KHz freq: EGNX - 128.230 Found a 8.33KHz freq: EGSP - 120.330 Found a 8.33KHz freq: EGSR - 122.430 Found a 8.33KHz freq: EGTB - 121.780 Found a 8.33KHz freq: EHHV - 131.030 Found a 8.33KHz freq: EHLE - 123.680 Found a 8.33KHz freq: EHNR - 129.980 Found a 8.33KHz freq: EHVK - 123.180 Found a 8.33KHz freq: ENCN - 124.480 Found a 8.33KHz freq: ENGM - 126.130 Found a 8.33KHz freq: EPLL - 124.230 Found a 8.33KHz freq: EPRA - 128.680 Found a 8.33KHz freq: EPWT - 118.730 Found a 8.33KHz freq: GECE - 123.330 Found a 8.33KHz freq: KAAO - 123.880 Found a 8.33KHz freq: KBID - 134.780 Found a 8.33KHz freq: KCLM - 135.180 Found a 8.33KHz freq: KCLM - 122.980 Found a 8.33KHz freq: KIFP - 119.830 Found a 8.33KHz freq: KMHV - 132.230 Found a 8.33KHz freq: KNOW - 122.980 Found a 8.33KHz freq: KNTD - 135.180 Found a 8.33KHz freq: KUIL - 135.230 Found a 8.33KHz freq: KWRB - 133.230 Found a 8.33KHz freq: KWRB - 119.480 Found a 8.33KHz freq: LFJL - 119.130 Found a 8.33KHz freq: LJLJ - 128.180 Found a 8.33KHz freq: LJLJ - 121.630 Found a 8.33KHz freq: LKBO - 118.280 Found a 8.33KHz freq: LKKL - 123.480 Found a 8.33KHz freq: LKKV - 121.230 Found a 8.33KHz freq: LKML - 125.830 Found a 8.33KHz freq: LKPO - 127.780 Found a 8.33KHz freq: LKSB - 120.680 Found a 8.33KHz freq: LKTB - 125.430 Found a 8.33KHz freq: LKTV - 125.830 Found a 8.33KHz freq: LZIB - 134.930 Found a 8.33KHz freq: LZKZ - 129.580 Found a 8.33KHz freq: RCAY - 126.180 Found a 8.33KHz freq: RCDC - 126.180 Found a 8.33KHz freq: RCKU - 126.180 Found a 8.33KHz freq: RCNN - 126.180 Found a 8.33KHz freq: RCQC - 126.180 Found a 8.33KHz freq: RCQS - 126.180 Found a 8.33KHz freq: RCSQ - 126.180 Found a 8.33KHz freq: RCYU - 126.180 Found a 8.33KHz freq: RPUF - 126.180 Found a 8.33KHz freq: S83 - 135.480 Found a 8.33KHz freq: TFFR - 129.080 For example, EDFE has 121.730 channel (means 121.725MHz), using the SenecaII when I switch to 121.725 the frequency found is EDDK instead of EDFE. Also if I switch to 121.730 channel the /instrumentation/comm[0]/frequencies/selected-mhz-fmt = 121.72 which is true for a 25KHz freq, but for 8.33KHz we should have something like /instrumentation/comm[0]/frequencies/selected-channel-fmt = 121.73 I think we need a tag in order to identify a 8.33KHz radio vs 25KHz radio, something like: <comm-radio> <name>comm</name> <number>0</number> <channel-radio>1</channel-radio> </comm-radio> If <channel-radio> is not present or set to 0 = this is a good old 25KHz radio else it's a 8.33KHz radio In real world 8.33KHz is already active in Europe and Austria abod FL195 and will be used in 2015 regardless altitude, so it would be nice for FG to have this real world feature :) Kind regards, Clément |
From: Torsten D. <To...@t3...> - 2014-03-02 12:14:26
|
> I'm glad to see that radio code has been improved, however it seems > that 8.33KHz frequency spacing support is not implemented. > Do you plan to implement it ? Yes, but it's a low priority task. However, I don't think it's too complicated. > > > In real world 8.33KHz is already active in Europe and Austria abod > FL195 and will be used in 2015 regardless altitude, Yeah - one of those useless and expensive ideas of easa :-/ Doesn't Austria belong to Europe anymore ;-) > so it would be nice for FG to have this real world feature :) I'd say, it's a must have! Torsten |
From: Alasdair C. <al...@bt...> - 2014-03-04 15:27:49
|
On 01/03/14 19:45, Torsten Dreyer wrote: > Am 01.03.14 20:39, schrieb Михаил Сойтанен: >> It's working. I have all latest things, but I didn't powered new comm >> radio via power-btn and power-good, like in this commit: >> https://gitorious.org/fg/fgdata/commit/b16dc2c7afc80624480489497b1b21643d46328e > Great, good to know it's not only working on my machine! >> May be latest commit to C172P needs this properties too? > No, she already has everything she needs. The Seneca was a bit out of > date, though and the mentioned commit got her back on track. > > Torsten I'm sorry, but I can't hear a cheep from comm(0) when tuned to KSFO (118.85) with git(next). Works OK with 3.0.0 Can anyone suggest what I am doing wrong? FWIW, I think the current method of generating ATIS speech ends up as incomprehensible rubbish and wonder if anyone has thought of generating the entire ATIS message and firing it off to a festival server. My initial experiments show that with easily available voices, we can achieve realistic human-like ATIS transmissions. Alasdair Campbell |
From: Torsten D. <To...@t3...> - 2014-03-04 18:54:39
|
Am 04.03.14 16:27, schrieb Alasdair Campbell: > I'm sorry, but I can't hear a cheep from comm(0) when tuned to KSFO > (118.85) with git(next). > Works OK with 3.0.0 > Can anyone suggest what I am doing wrong? Do you see anything in /instrumentation/comm/atis ? If not, can you post the properties under /instrumentation/comm ? Torsten > > FWIW, I think the current method of generating ATIS speech ends up as > incomprehensible rubbish > and wonder if anyone has thought of generating the entire ATIS message > and firing it off to a > festival server. My initial experiments show that with easily available > voices, we can achieve > realistic human-like ATIS transmissions. Yes, that's one of my mid-term goals.. Cheers, Torsten |
From: Alasdair C. <al...@bt...> - 2014-03-05 10:07:52
|
On 04/03/14 18:54, Torsten Dreyer wrote: > Am 04.03.14 16:27, schrieb Alasdair Campbell: >> I'm sorry, but I can't hear a cheep from comm(0) when tuned to KSFO >> (118.85) with git(next). >> Works OK with 3.0.0 >> Can anyone suggest what I am doing wrong? > Do you see anything in /instrumentation/comm/atis ? > If not, can you post the properties under /instrumentation/comm ? > > Torsten >> FWIW, I think the current method of generating ATIS speech ends up as >> incomprehensible rubbish >> and wonder if anyone has thought of generating the entire ATIS message >> and firing it off to a >> festival server. My initial experiments show that with easily available >> voices, we can achieve >> realistic human-like ATIS transmissions. > Yes, that's one of my mid-term goals.. > > Cheers, Torsten > Thank you for your interest, Tosten, Below follows the section of the property tree you requested' BTW, I can hear the nav-radio(s), dme and adf idents as well as the marker beacons. Only the comm radios remain stubbornly silent. I am puzzled. Kind regards, Alasdair > > > Contents of "/ <http://localhost:5400/>instrumentation > <http://localhost:5400/instrumentation/>/comm > <http://localhost:5400/instrumentation/comm/>/" > > *airport-id* (KSFO) > <http://localhost:5400/instrumentation/comm/airport-id> > *atis* (This is San Francisco Intl airport information romeo. Time > zero eight five six Zulu. Expect visual approach. landing and > departing ruway zero one . Weather . Wind: zero zero zero degrees at > zero knots . Visibility one zero kilometers or more. Clouds few five > hundret feet broken two thousand feet broken two zero thousand feet. > Temperature one three dewpoint one three. QNH one zero one niner > hektopascal or three zero decimal niner inches. nosig. Advise on > initial contact you have information romeo) > <http://localhost:5400/instrumentation/comm/atis> > *frequencies <http://localhost:5400/instrumentation/comm/frequencies>*/ > *frq-swap-btn* (0) > <http://localhost:5400/instrumentation/comm/frq-swap-btn> > *height-above-station-ft* (4.882636503) > <http://localhost:5400/instrumentation/comm/height-above-station-ft> > *power-btn* (true) <http://localhost:5400/instrumentation/comm/power-btn> > *power-good* () <http://localhost:5400/instrumentation/comm/power-good> > *ptt* (0) <http://localhost:5400/instrumentation/comm/ptt> > *serviceable* (true) > <http://localhost:5400/instrumentation/comm/serviceable> > *signal-quality-norm* (1) > <http://localhost:5400/instrumentation/comm/signal-quality-norm> > *slant-distance-m* (1481.606617) > <http://localhost:5400/instrumentation/comm/slant-distance-m> > *station-name* (ATIS) > <http://localhost:5400/instrumentation/comm/station-name> > *station-type* (atis) > <http://localhost:5400/instrumentation/comm/station-type> > *track-distance-m* (1481.604776) > <http://localhost:5400/instrumentation/comm/track-distance-m> > *true-bearing-from-deg* (201.3652468) > <http://localhost:5400/instrumentation/comm/true-bearing-from-deg> > *true-bearing-to-deg* (21.36151602) > <http://localhost:5400/instrumentation/comm/true-bearing-to-deg> > *volume* (0.7) <http://localhost:5400/instrumentation/comm/volume> |
From: Alasdair C. <al...@bt...> - 2014-03-05 10:20:25
|
On 05/03/14 10:07, Alasdair Campbell wrote: > On 04/03/14 18:54, Torsten Dreyer wrote: >> Am 04.03.14 16:27, schrieb Alasdair Campbell: >>> I'm sorry, but I can't hear a cheep from comm(0) when tuned to KSFO >>> (118.85) with git(next). >>> Works OK with 3.0.0 >>> Can anyone suggest what I am doing wrong? >> Do you see anything in /instrumentation/comm/atis ? >> If not, can you post the properties under /instrumentation/comm ? >> >> Torsten >>> FWIW, I think the current method of generating ATIS speech ends up as >>> incomprehensible rubbish >>> and wonder if anyone has thought of generating the entire ATIS message >>> and firing it off to a >>> festival server. My initial experiments show that with easily available >>> voices, we can achieve >>> realistic human-like ATIS transmissions. >> Yes, that's one of my mid-term goals.. >> >> Cheers, Torsten >> > Thank you for your interest, Tosten, > Below follows the section of the property tree you requested' > BTW, I can hear the nav-radio(s), dme and adf idents as well as the marker > beacons. Only the comm radios remain stubbornly silent. > I am puzzled. > Kind regards, > Alasdair >> >> >> Contents of "/ <http://localhost:5400/>instrumentation >> <http://localhost:5400/instrumentation/>/comm >> <http://localhost:5400/instrumentation/comm/>/" >> >> *airport-id* (KSFO) >> <http://localhost:5400/instrumentation/comm/airport-id> >> *atis* (This is San Francisco Intl airport information romeo. Time >> zero eight five six Zulu. Expect visual approach. landing and >> departing ruway zero one . Weather . Wind: zero zero zero degrees at >> zero knots . Visibility one zero kilometers or more. Clouds few five >> hundret feet broken two thousand feet broken two zero thousand feet. >> Temperature one three dewpoint one three. QNH one zero one niner >> hektopascal or three zero decimal niner inches. nosig. Advise on >> initial contact you have information romeo) >> <http://localhost:5400/instrumentation/comm/atis> >> *frequencies <http://localhost:5400/instrumentation/comm/frequencies>*/ >> *frq-swap-btn* (0) >> <http://localhost:5400/instrumentation/comm/frq-swap-btn> >> *height-above-station-ft* (4.882636503) >> <http://localhost:5400/instrumentation/comm/height-above-station-ft> >> *power-btn* (true) <http://localhost:5400/instrumentation/comm/power-btn> >> *power-good* () <http://localhost:5400/instrumentation/comm/power-good> >> *ptt* (0) <http://localhost:5400/instrumentation/comm/ptt> >> *serviceable* (true) >> <http://localhost:5400/instrumentation/comm/serviceable> >> *signal-quality-norm* (1) >> <http://localhost:5400/instrumentation/comm/signal-quality-norm> >> *slant-distance-m* (1481.606617) >> <http://localhost:5400/instrumentation/comm/slant-distance-m> >> *station-name* (ATIS) >> <http://localhost:5400/instrumentation/comm/station-name> >> *station-type* (atis) >> <http://localhost:5400/instrumentation/comm/station-type> >> *track-distance-m* (1481.604776) >> <http://localhost:5400/instrumentation/comm/track-distance-m> >> *true-bearing-from-deg* (201.3652468) >> <http://localhost:5400/instrumentation/comm/true-bearing-from-deg> >> *true-bearing-to-deg* (21.36151602) >> <http://localhost:5400/instrumentation/comm/true-bearing-to-deg> >> *volume* (0.7) <http://localhost:5400/instrumentation/comm/volume> > It may or may not be significant, but the Time reported be atis seems to a little old. The time I actually tuned to the atis frequency was around one zero five zero Zulu. regards AC |
From: Alasdair C. <al...@bt...> - 2014-03-05 10:23:36
|
On 05/03/14 10:20, Alasdair Campbell wrote: > On 05/03/14 10:07, Alasdair Campbell wrote: >> On 04/03/14 18:54, Torsten Dreyer wrote: >>> Am 04.03.14 16:27, schrieb Alasdair Campbell: >>>> I'm sorry, but I can't hear a cheep from comm(0) when tuned to KSFO >>>> (118.85) with git(next). >>>> Works OK with 3.0.0 >>>> Can anyone suggest what I am doing wrong? >>> Do you see anything in /instrumentation/comm/atis ? >>> If not, can you post the properties under /instrumentation/comm ? >>> >>> Torsten >>>> FWIW, I think the current method of generating ATIS speech ends up as >>>> incomprehensible rubbish >>>> and wonder if anyone has thought of generating the entire ATIS message >>>> and firing it off to a >>>> festival server. My initial experiments show that with easily available >>>> voices, we can achieve >>>> realistic human-like ATIS transmissions. >>> Yes, that's one of my mid-term goals.. >>> >>> Cheers, Torsten >>> >> Thank you for your interest, Tosten, >> Below follows the section of the property tree you requested' >> BTW, I can hear the nav-radio(s), dme and adf idents as well as the >> marker >> beacons. Only the comm radios remain stubbornly silent. >> I am puzzled. >> Kind regards, >> Alasdair >>> >>> >>> Contents of "/ <http://localhost:5400/>instrumentation >>> <http://localhost:5400/instrumentation/>/comm >>> <http://localhost:5400/instrumentation/comm/>/" >>> >>> *airport-id* (KSFO) >>> <http://localhost:5400/instrumentation/comm/airport-id> >>> *atis* (This is San Francisco Intl airport information romeo. Time >>> zero eight five six Zulu. Expect visual approach. landing and >>> departing ruway zero one . Weather . Wind: zero zero zero degrees at >>> zero knots . Visibility one zero kilometers or more. Clouds few five >>> hundret feet broken two thousand feet broken two zero thousand feet. >>> Temperature one three dewpoint one three. QNH one zero one niner >>> hektopascal or three zero decimal niner inches. nosig. Advise on >>> initial contact you have information romeo) >>> <http://localhost:5400/instrumentation/comm/atis> >>> *frequencies <http://localhost:5400/instrumentation/comm/frequencies>*/ >>> *frq-swap-btn* (0) >>> <http://localhost:5400/instrumentation/comm/frq-swap-btn> >>> *height-above-station-ft* (4.882636503) >>> <http://localhost:5400/instrumentation/comm/height-above-station-ft> >>> *power-btn* (true) >>> <http://localhost:5400/instrumentation/comm/power-btn> >>> *power-good* () <http://localhost:5400/instrumentation/comm/power-good> >>> *ptt* (0) <http://localhost:5400/instrumentation/comm/ptt> >>> *serviceable* (true) >>> <http://localhost:5400/instrumentation/comm/serviceable> >>> *signal-quality-norm* (1) >>> <http://localhost:5400/instrumentation/comm/signal-quality-norm> >>> *slant-distance-m* (1481.606617) >>> <http://localhost:5400/instrumentation/comm/slant-distance-m> >>> *station-name* (ATIS) >>> <http://localhost:5400/instrumentation/comm/station-name> >>> *station-type* (atis) >>> <http://localhost:5400/instrumentation/comm/station-type> >>> *track-distance-m* (1481.604776) >>> <http://localhost:5400/instrumentation/comm/track-distance-m> >>> *true-bearing-from-deg* (201.3652468) >>> <http://localhost:5400/instrumentation/comm/true-bearing-from-deg> >>> *true-bearing-to-deg* (21.36151602) >>> <http://localhost:5400/instrumentation/comm/true-bearing-to-deg> >>> *volume* (0.7) <http://localhost:5400/instrumentation/comm/volume> >> > It may or may not be significant, but the Time reported be atis seems > to a little old. The time I actually tuned > to the atis frequency was around one zero five zero Zulu. > regards > AC Correction: one zero zero five Zulu. Oops, sorry! AC |
From: Torsten D. <To...@t3...> - 2014-03-06 14:46:25
|
>>> Below follows the section of the property tree you requested' >>> BTW, I can hear the nav-radio(s), dme and adf idents as well as the >>> marker >>> beacons. Only the comm radios remain stubbornly silent. >>> I am puzzled. >>> Kind regards, >>> Alasdair Thanks for the response. So the METAR to ATIS generation code seems to be working. The only thing missing is the text to speech part. That's just because I have removed the current implementation and have not yet pushed a replacement. So this was my bad - sorry if that caused any trouble for you. >>> >> It may or may not be significant, but the Time reported be atis seems >> to a little old. The time I actually tuned >> to the atis frequency was around one zero five zero Zulu. >> regards >> AC > Correction: one zero zero five Zulu. Oops, sorry! The time comes from the METAR report. If you experience the discrepancy again, can you compare the value of /environment/metar[3]/data (which holds the raw metar) and that of /instrumentation/comm[0]/atis? Torsten |
From: James T. <zak...@ma...> - 2014-03-05 10:28:57
|
On 4 Mar 2014, at 15:27, Alasdair Campbell <al...@bt...> wrote: > FWIW, I think the current method of generating ATIS speech ends up as > incomprehensible rubbish > and wonder if anyone has thought of generating the entire ATIS message > and firing it off to a > festival server. My initial experiments show that with easily available > voices, we can achieve > realistic human-like ATIS transmissions. Just to comment on this: shipping Festival (or one of the variants) with the simulator is possible, and has some advantages indeed. However when I’ve looked, festival (and the fvox? variant) are not very easy to drop in as a library and use. (As in, easy enough that I could do it in a few days hacking). If anyone wants to try, I would be happy to support them since some ugly code could die. The API needs to be: text string int, .WAV data out - i.e the library should not attempt to talk to sound card since we do that ourselves. Kind regards, James |
From: Alasdair C. <al...@bt...> - 2014-03-05 11:55:02
|
On 05/03/14 10:28, James Turner wrote: > > On 4 Mar 2014, at 15:27, Alasdair Campbell <al...@bt... > <mailto:al...@bt...>> wrote: > >> FWIW, I think the current method of generating ATIS speech ends up as >> incomprehensible rubbish >> and wonder if anyone has thought of generating the entire ATIS message >> and firing it off to a >> festival server. My initial experiments show that with easily available >> voices, we can achieve >> realistic human-like ATIS transmissions. > > Just to comment on this: shipping Festival (or one of the variants) > with the simulator is possible, and has some advantages indeed. > However when I've looked, festival (and the fvox? variant) are not > very easy to drop in as a library and use. (As in, easy enough that I > could do it in a few days hacking). If anyone wants to try, I would be > happy to support them since some ugly code could die. The API needs to > be: text string int, .WAV data out - i.e the library should not > attempt to talk to sound card since we do that ourselves. > > Kind regards, > James Thanks, James. I had a go at this a longish while ago, and even went so far as to use a sort of circular FIFO to allocate different voices to the various AI pilots etc. I am particularly fond of the "nitech" voices and use nitech_us_awb_arctic_hts as my default voice for speaking cookery recipes and timed instruction and such. It is a particularly fine Scottish accented voice which I used for ATIS, though some of the female voices might be preferable as they tend to cut through engine noise and such. I adapted preferences.xml to select the voices I wished to use for various roles. Sadly, all my experimental code died when trying to convert my NAS to striped raid. Yeah, yeah, I've heard it all about backups, which were fine and dandy when you had a bunch of operators on a mainframe to do it for you on the night-shift. I've also heard it said that "I would rather stand on my head in a bucket of s**t, than wait for a couple of terrabytes to copy even over a 1Gb lan", 'specially if it's a backup of a backup! IIRC, I ran `festival --server &` and had a socket in FG connecting to port 1314, through which I fired the voice select and "SayText" commands to festival. If an aged geezer like me whose tired brain "perplexes and retards" through decades of debauchery & abuse could manage it, I imagine it would be a walk in the park for you smart guys who know the ins-and-outs of flightgear and simgear task scheduling and and such like the back of your hands. You might want to try out the idea by issuing system calls such as: `echo "gribble griobble grinable" | festival --tts` I hope my ruminations have given some impetus to add what I think would be a huge (optional) improvement to FlightGear's realism. Keep up the good work, Devs. Though I don't contribute very much these days, I am always listening a and learning. My very best regards, Alasdair Campbell |
From: Torsten D. <To...@t3...> - 2014-03-01 20:09:12
|
Am 01.03.14 20:50, schrieb ?????? ????????: > I will do atis/xxx.xml for Russia and send to you. Very good! > > Another dumb question: whether there should be on-screen ticker with > current ATIS? Yes, I just didn't have the time to make one yet ;-) And I haven't figured out a nice way to do so. Ideas and volunteers are welcome! Torsten > > > 2014-03-01 23:45 GMT+04:00 Torsten Dreyer <To...@t3... > <mailto:To...@t3...>>: > > Am 01.03.14 20:39, schrieb ?????? ????????: > > It's working. I have all latest things, but I didn't powered new > comm > > radio via power-btn and power-good, like in this commit: > > > https://gitorious.org/fg/fgdata/commit/b16dc2c7afc80624480489497b1b21643d46328e > Great, good to know it's not only working on my machine! > > > > May be latest commit to C172P needs this properties too? > No, she already has everything she needs. The Seneca was a bit out of > date, though and the mentioned commit got her back on track. > > Torsten > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate > reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > <mailto:Fli...@li...> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Adrian M. <kan...@gm...> - 2014-03-05 10:56:36
|
On Wednesday, March 05, 2014 12:28:39 James Turner wrote: > > Just to comment on this: shipping Festival (or one of the variants) with > the simulator is possible, and has some advantages indeed. However when > I’ve looked, festival (and the fvox? variant) are not very easy to drop in > as a library and use. (As in, easy enough that I could do it in a few days > hacking). If anyone wants to try, I would be happy to support them since > some ugly code could die. The API needs to be: text string int, .WAV data > out - i.e the library should not attempt to talk to sound card since we do > that ourselves. > > Kind regards, > James Hi James, libfestival supports that, I've used it. In addition you need libestools. However, if you don't want voice to sound like a robot, you need Nitech voices which are pretty state of the art. Unfortunately, they are hard enough to install on Linux, I don't even know how you'd go about doing that on Windows. Cheers, Adrian |
From: James T. <zak...@ma...> - 2014-03-05 11:14:03
|
On 5 Mar 2014, at 10:57, Adrian Musceac <kan...@gm...> wrote: > Hi James, > libfestival supports that, I've used it. In addition you need libestools. > However, if you don't want voice to sound like a robot, you need Nitech voices > which are pretty state of the art. Unfortunately, they are hard enough to > install on Linux, I don't even know how you'd go about doing that on Windows. I thought Festival voices were data, not code - so the deployment would be relatively easy if we move them into FGDATA and pass the necessary search paths into libfestival. (He says making wild guesses about how the API might work…) Or are these voices sufficiently state-of-the-art that they are now plugin DLLs? To be clear, I’d be looking to take the same approach as we do for sqlite / iaxclient - include a code drop in 3rdparty, but allow the brave / foolish / those using a Linux-distro to use the system festival if such a thing is available. On Mac and Window it sure isn’t :) (Also, at least for ATIS, I think robot voices are quite accurate, right?) Less so for ATC…. Kind regards, James |
From: Saikrishna A. <sai...@gm...> - 2014-03-05 12:42:18
|
On Wednesday, March 05, 2014 11:13:36 AM James Turner wrote: To be clear, I’d be looking to take the same approach as we do for sqlite / iaxclient - include a code drop in 3rdparty, but allow the brave / foolish / those using a Linux-distro to use the system festival if such a thing is available. On Mac and Window it sure isn’t :) -- Saikrishna Arcot |
From: James T. <zak...@ma...> - 2014-03-05 12:53:03
|
On 5 Mar 2014, at 12:42, Saikrishna Arcot <sai...@gm...> wrote: > A system version of festival is indeed available on Ubuntu (and likely Debian). Is there a libfestival available to link to, or just the festival binary? Regards, James |
From: Adrian M. <kan...@gm...> - 2014-03-05 13:05:54
|
On Wednesday, March 05, 2014 14:52:29 James Turner wrote: > On 5 Mar 2014, at 12:42, Saikrishna Arcot <sai...@gm...> wrote: > > A system version of festival is indeed available on Ubuntu (and likely > > Debian). > > Is there a libfestival available to link to, or just the festival binary? > > Regards, > James Yes there is: libFestival.a (Debian Wheezy) Adrian |
From: Saikrishna A. <sai...@gm...> - 2014-03-05 13:09:33
|
On Wednesday, March 05, 2014 12:52:29 PM James Turner wrote: On 5 Mar 2014, at 12:42, Saikrishna Arcot <sai...@gm...[1]> wrote: A system version of festival is indeed available on Ubuntu (and likely Debian). Is there a libfestival available to link to, or just the festival binary? Regards, James Yes. The main festival binary is linked to three libraries: libeststring.so, libestbase.so, and libestools.so (with the headers for libraries available), but there is a separate set of headers for festival itself. There is also a static festival library available named libFestival.a. The documentation for festival headers is here[2].-- Saikrishna Arcot -------- [1] mailto:sai...@gm... [2] http://www.festvox.org/docs/manual-1.4.3/festival_28.html#SEC133 |
From: James T. <zak...@ma...> - 2014-03-07 09:51:05
|
On 7 Mar 2014, at 09:38, Torsten Dreyer <To...@t3...> wrote: > As I am totally naive when it comes to festival, I just checked the documentation and found at > http://www.cstr.ed.ac.uk/projects/festival/manual/festival_28.html > That: > int festival_text_to_wave(const EST_String &text,EST_Wave &wave); > Synthesize the given string into the given wave. Returns TRUE or FALSE depending on where this was successful. > Isn't that just what we are looking for? Yes absolutely. The issue is not code, it’s build + deployment. If we can get to a point where we have a build of festival, portably, then the code side is nice as you see. But we also have to deploy the correct voice(s), which other people have said is non-trivial (I have no personal experience). So unfortunately I think most of the work is ‘boring’, not fun hacking. Especially if there’s actual source changes needed for compile without Cygwin. Regards, James |
From: James T. <zak...@ma...> - 2014-03-07 13:24:26
|
On 7 Mar 2014, at 09:50, James Turner <zak...@ma...> wrote: > So unfortunately I think most of the work is ‘boring’, not fun hacking. Especially if there’s actual source changes needed for compile without Cygwin. > I did some further digging, there is /some/ Win32 portability stuff in the esound-tools layer. So with some luck the ‘needs Cygwin’ comments are out of date, and the code will compile on Win32 native. I also have the strong impression there are entire subdirs of both esound-tools and festival we simply don’t need for use as a library, which reduces the work. This leaves all the Cmake hacking and deployment issues to solve, then :) Regards, James |