Jump to content

Swift - Pilot client progress


Recommended Posts

CPDLC is something typically only found on modern airliners. I would imagine that it would rather spoil the look and feel of an older aircraft!

 

I don't know what the implementation plans are, but it should be possible to create a generic CPDLC gauge if it is not part of the pilot client interface itself (which I believe is the plan).

David Zhong

Link to post
Share on other sites
  • Replies 328
  • Created
  • Last Reply

Top Posters In This Topic

I have a question about the SDK, I'm currently using a custom made app that calls me when I have a 'Contact me' message. Squawkbox interface offers an offset on the SDK to announce incoming chat, Private Conversation pop messages, info and error events. Will the new client have this included on the SDK?

 

Gonzalo, this app sounds very interesting, could you share it with me or point me to where I can find info?

 

Thanks,

morten_steen_zpsbqpwg3mb.png
Link to post
Share on other sites
I have a question about the SDK, I'm currently using a custom made app that calls me when I have a 'Contact me' message. Squawkbox interface offers an offset on the SDK to announce incoming chat, Private Conversation pop messages, info and error events. Will the new client have this included on the SDK?

 

Gonzalo, this app sounds very interesting, could you share it with me or point me to where I can find info?

 

Thanks,

 

Hi! I appreciate your interest, but to be honest I didn't plan to release it to the public, it was just a Python draft script that I created just to test FSUIPC with Python API and to play with some FSUIPC offsets, BUT I could clean it up a little bit to create a release candidate.

I'm currently testing the app, and has some deficiencies (Every time that you receive a message on the chatbox it calls, so you have to manually pause it when you are private chatting with others, this could be annoying). There is a second issue that currently I don't have the resources to solve, the script uses Skype to place the call, and.. well.. Skype Mobile is no good.

 

 

CPDLC is something typically only found on modern airliners. I would imagine that it would rather spoil the look and feel of an older aircraft!

 

I don't know what the implementation plans are, but it should be possible to create a generic CPDLC gauge if it is not part of the pilot client interface itself (which I believe is the plan).

 

By 'oldies' I was referring to those payware modern commercial aircraft that are not been supported nor updated, like PSS, or some Wilco products that don't receive much attention. Since I still use FS9 (can't afford FSX yet ) there are a lot of payware aircraft that are not receiving active support.

Edited by Guest
Link to post
Share on other sites

In regards of CPDLC, it comes complete with the MCDU and DCDU panel which do not make it necessary, to have a gauge yet. As announced the plan is to integrate this modul in payware aircraft, as I had spoken to PMDG and aerosoft f.e.

Therefore we give them the communication traffic and information, as well the interface slots in the client where they can connect their gauge directly to. Furthermore it is possible to integrate the client completely into a new payware addon, so no other software would be needed. However, we will see how far they will go.

 

Kind regards,

 

Sascha

f72.gif

 

Project Manager - swift pilot client project

Link to post
Share on other sites

Hey!. I was looking some Airline ICAO codes and an idea just popped-up, is it possible to create a VATSIM database with all the ICAO codes available. Virtual Airlines could submit request to add their own ICAO, if they are not real airlines (real ICAO codes would be obviously added by default, and updated continuously, by users requests or by VATSIM admins).

The new client would just have to update the database. This will help a lot the model matching system.

 

The database could have this information.

 

ICAO - Airline Name - thumbnail - website - links to AI repaints

 

(website just available for fictitious virtual airlines).

Link to post
Share on other sites

One of the problems with that idea, while I would support it, is keeping the database updated. I believe the developers of FSINN tried this, only to find that they could not keep an updated database of every suggested ICAO code. Vatsim organizers would probably not support this, given that they have advocated in the past for service over extra amenities (a centralized booking system, if I remember reading about that) I actually enjoy the prospect of your idea, but I'm not sure how others would feel about it.

Link to post
Share on other sites

I'm not talking about callsign here, I'm talking about ICAO Airline codes, for model matching compatibility, standardization is the best way to make progress on it.

 

I've seen that a lot of people are not aware of the importance about Aircraft selection and Airline selection when you connect to VATSIM. Some people thing that just because they enter as AALXXX and had selected a B737-800 other VATSIM users will see him as an American Airlines B737-800, you would be surprised if you type .cheat model and you see how many people had correctly configured their Aircraft type and Airline.

 

We need any form of convention, a way to maintain a database with the majority of the real ICAO codes and make some 'fake' ones for the fictitious VA's. There are 10000 active users on VATSIM, and I think we all deserve to see each other correctly, we could all maintain the database working (It doesn't have to be centralized).

Link to post
Share on other sites
I'm not talking about callsign here, I'm talking about ICAO Airline codes, for model matching compatibility, standardization is the best way to make progress on it.

 

I've seen that a lot of people are not aware of the importance about Aircraft selection and Airline selection when you connect to VATSIM. Some people thing that just because they enter as AALXXX and had selected a B737-800 other VATSIM users will see him as an American Airlines B737-800, you would be surprised if you type .cheat model and you see how many people had correctly configured their Aircraft type and Airline.

 

We need any form of convention, a way to maintain a database with the majority of the real ICAO codes and make some 'fake' ones for the fictitious VA's. There are 10000 active users on VATSIM, and I think we all deserve to see each other correctly, we could all maintain the database working (It doesn't have to be centralized).

 

In regards of model matching, klaus has written a database which is approachable via a website

as well. So the client will get a correct information about all the aircraft installed, you have correctly set the values for your aircrafts etc and synchronise these informations between all users of the new client.

We must separate airline icao code and aircraft code. The airline coding are not relevant to us in the first line but you specify them for your models to set a correct value. If someone is not able to set a correct icao for his airline he his flying for, the controller will kindly correct him, I think. For the database and the aircrafts we will discuss how we can arrange a correction or validation service, so it will be [Mod - Happy Thoughts]ured there is only correct information given by the users.

 

Regards,

 

Sascha

f72.gif

 

Project Manager - swift pilot client project

Link to post
Share on other sites

I was unaware that controllers should correct ICAO codes, something that's not so easy to do because some VAs (and a number of individuals) create their own codes that sometimes conflict with those used by obscure real world airlines. It's hard to imagine VATSIM adopting some sort of clearinghouse for callsigns.

 

Good fortune and many thanks to the development team,

 

John

John Wiesenfeld

ZNY - C1

FAA IFR/SEL in a galaxy long ago and far away

Link to post
Share on other sites

Airline matching is in some way 'eye-candy',but aircraft-type matching must be near perfect.

 

Squawkbox has a list with tons of Aircraft and Airlines, selecting one is as simple as typing 'b' '737' and choose your specific model. On the new client you could include an auto-update service, everytime you start the client it will update the Airline and Aircraft ICAO codes from a database, that shouldn't be hard to implement. The last thing that could be added, are some warnings, before you connect 'Are you sure you want to connect without selecting your aircraft type', 'Your model could not be recognized, please select an aircraft type to connect' etc...

Link to post
Share on other sites

Unfortunately there is not much space for improvements. The VATSIM voice servers use a very low rate codec, which is the main cause for bad voice quality. This cannot be changed otherwise all older clients (FSInn, SB and also older ATC clients) are not usable any more. This may change, in the future when the majority has moved, but can't be done from release date on.

swift - Technical Manager

http://swift-project.org/

Link to post
Share on other sites
This may change, in the future when the majority has moved, but can't be done from release date on.

 

I'm not familiar with way Vatsim makes coding/decoding, BUT there is always one option. It's more difficult (or actually time consuming) for the developers, but the only one to make smooth transition.

 

I [Mod - Happy Thoughts]ume, that vatsim is working like every other voice room - it [Mod - Happy Thoughts]igns the port to connect to, mixes the streams from all connected and sends back (simplified).

 

So, the only other solution would be to take more modern technology (actually, same voice coding technology with higher bandwidth I believe - you can't do much if bandwidth stays the same, as current Vatsim codec is quite up to standard, what spoils it is the bandwidth restricted), set it to work parallel (or - by choice of user) on another port, providing a better quality. Of course some minor issues would need to be solved (interconnecting both channels, so CTR with high quality can talk to old clients/low quality, and opposite; some sort of fallback procedure in case of short bandwidth lack for high quality codec, etc). Still, it's the only procedure to allow new voice quality to be developed without having to provide a backward compatibility. And you'll always consider backward compatibility - I don't think there's any way to change ALL the clients (pilots, ATC) otherwise.

 

Best regards,

Adam

Link to post
Share on other sites

Why do you want to improve the voice quality?

 

What is wrong with the current quality related to VHF voice transmission in reality? Are we trying to simulate the reality "as real as it gets" or not?

I think if you want to have a clear transmission, use a phone or Teamspeak. But voice transmissions in aviation are based on a rather old technology, with all its consequences. One sould accept that, or use CPDLC in future ...

 

Kind regards

Jonas

Jonas Kuster Leader Operation - vACC Switzerland | www.vacc.ch

Link to post
Share on other sites

Adam,

 

what you are suggesting is a valid solution and this was already discussed as a future way forward. Anyhow, this requires a major change in the server infrastructure and is therefore out of scope of this client project. For the time being we have to use the existing solutions.

 

But since you mentioned this point: Yes it would work and I would love to see progress in the server infrastructure (FSD & Voice). This is not only about voice quality. There is btw. a difference between bad voice quality and VHF simulation. The used voice implementation can never compete with current state of the art code. For example a voice setup without the squelch and mic tests is not readable. You just hear noise. Unfortunately most beginners to not know how to properly setup their clients. This is also a big issue for the client team and we have identified already a lot points which need to be improved in order to make our all lifes easier.

But as usual its a matter of human resources. I'm sure my client team would be happy to contribute to a 2nd generation Vatsim infrastructure but on the client project we are currently 3-5 active developers. So we have to focus on the client for the moment. So technically its not a big issue IMHO, you just need a team to get it done. When the client is released, I hope to continue work on the server side with the same team. However, we will see how the workload will be after public release. I fear the time will be even more busy

swift - Technical Manager

http://swift-project.org/

Link to post
Share on other sites
Why do you want to improve the voice quality?

 

What is wrong with the current quality related to VHF voice transmission in reality? Are we trying to

simulate the reality "as real as it gets" or not?

I think if you want to have a clear transmission, use a phone or Teamspeak. But voice transmissions in aviation are based on a rather old technology, with all its consequences. One sould accept that, or use CPDLC in future ...

 

Kind regards

Jonas

 

Jonas, I didn't mean to increase quality at all, perhaps I had to describe what is actually wrong with fsinn.

fsinn apperrently simulates VHF radio voice, but it actually does not. it simulates digital voice transmission.

digital voice transmition is new actually, and it's range is extremely wide, and it can be encrypted heavily. however, it's quality is robotic.

on the other hand analog radios are not robotic (while still being on low quality plus the static sounds), and they can't be scrambled with strong encryption methods. I can be slightly wrong at this, but I'm certin that fsinn is totally wrong at simulating ATC radio voice.

please do a google search on digital vs analog radio and hear some youtube samples. you will instantly get the idea, and will find out that fsinn actually simulates digital voice which is modern and does not sound like real VHF radio transmissions.

I say this because squawqbox does not apply that terrible filter which fsinn does, which is totally unrealistic.

 

edit: even unchecking "VHF simulation" setting in fsinn does not fix the bad filter. Maybe I'm too sensitive since I'm visually impaired, but I think those who are radio operators or are real controllers can agree with me.

hope I could clerify what I actually ment to roland and others.

Blind (Visually impaired) Pilot flying with voice control and virtual co-pilot.

 

Delta Virtual Airlines pilot, DVA10222

Link to post
Share on other sites

Jonas, I didn't mean to increase quality at all, perhaps I had to describe what is actually wrong with fsinn.

fsinn apperrently simulates VHF radio voice, but it actually does not. it simulates digital voice transmission.

digital voice transmition is new actually, and it's range is extremely wide, and it can be encrypted heavily. however, it's quality is robotic.

 

This cut in quality is exactly the same as was in telephony, or old ISDN telephony systems. There's some math behind this, but the voice quality you transmit with digital channel depends on two things: dynamics (how many levels of membrane move in speaker are allowed), and frequency range you want to transmit. The more you expect from both, the more bandwidth it takes. Typical telephony is cut at 256levels (1 byte per sample) and 4kHz (8000 samples per second), equalling to 8kBytes per second. If you wanted to change that to DVD quality, you put 2 bytes per sample, and 44.1kHz (let's forget about stereo), raising bar to 88.2kBytes per second. Additionally it's compressed with modern codec (like mp3, for example), they do some extra math to cut out things you wouldn't hear anyways, or use previous value to describe current value, things like that. I know I'm simplifying to avoid math as much as possible, it's for sake of easy understanding. You end up with 10 times less bandwidth, so with the modern links, it's not a problem of bandwidth for most of us, but rather - as Roland mentioned - someone would have to do a job in quite many places, also getting some extra CPU power at least for transition. So it's not a question how, or if, it's more "where" and "who". And when it's implemented, the result in most cases will be way better.

 

Adam

Link to post
Share on other sites

What Adam said in the post above actually makes sense.

Here's a youtube vid for example. the first mode sounds very close to ATC radio voices, while the second mode, which is digital, sound exactly like fsinn and not like the ATC communication voice.

Blind (Visually impaired) Pilot flying with voice control and virtual co-pilot.

 

Delta Virtual Airlines pilot, DVA10222

Link to post
Share on other sites

Hadi, I understood that you just don't like the filter of FSInn, also not the additional option for VHF. That might be, I can't do a comparison to the reality at my own right now as I have been reading the frequency from aircraft only a few times. But I myself have not more difficulties to understand ATC in VATSIM that f.e. listening to liveATC.net.

I agree that a realistic VHF filter would be a nice feature also in the new client, even if I normally don't use it.

 

But Adam, I still think that the general voice transmission of VATSIM voice is good enough to understand. I don't find changing technologies there an important task. But, as mentioned before, the filter may be improved to do a realistic simulation of VHF.

 

Always think that any filtering is just a simulation. Due to we are working with computers, it will be difficult to leave out a digital voice transmission completely.

Jonas Kuster Leader Operation - vACC Switzerland | www.vacc.ch

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...