towsim

@Dejjvid Could you please unpush the horizon button in the quality dialog and and check whether it improves the short range quality?

You can do some tests to find the reason for the degradation. Go to the quality dialog and disable the different quality checks by their buttons. One after the other. With this method, you can find out which of the calculations cause the degradation. If you could post the result here, it would be great.

Dear Aries users, the download of Aries Radio V 1.976 was raised to V 1.976a. The only change is the TeamSpeak plugin, which caused the TS crash. Since the bug was located in the protocol system, all protocol functions are suppressed in this repaired version. The software is available on the Aries download page: http://ariescon.com/index10.html

Dear Aries users, as quick repair, a download file is prepared at: http://ariescon.com/ariesradio.zip The ZIP file contains AriesRadio.dll. It shall replace the file in C:\Program Files\TeamSpeak 3 Client\plugins The file has the internal version number 1.976a. The installation package will be modified tomorrow. It will even have the version number 1.976a. The solution was, to prevent all protocol functions. Therefore, no protocol file is produced for the moment. If any issue comes up, please post it here. Thank you and sorry…

I think, I have solved the bug. We will test it this night in our community. If no issues come up, I will publish it immediately after our session. There is only one file to be replaced.

To exclude operating system issues, please add the answers to the following questions if you post: What operating system (Windows 7/8…)? In case of Windows 7: Windows Home, Professional, Ultimate ? How are you logged in (Administrator, standard user..)? In my test environment I run Windows 7 Home as administrator and can provoke the crash. In my development environment I run Windows 7 Ultimate and no crash is observed.

Dear stressed Aries users, as a first measure to prevent the TS crash, please delete or rename the file: C:\Program Files\AriesWings\PRCL\AriesProtocol.exe It seems to be the reason for the crash. There is obviously a timing problem which causes a TS crash in a special situation. If TS does not find AriesProtocol.exe, it will not send protocol messages to this application. At least in my test environment it worked reliably. If someone still experiences the crash after the change, please post it here. Sorry…

To all frustrated V 1.976 users: I am working on the TS3 crash bug. It is a bit complicated because it appears now and then only. I am sorry for stressing your patience...

TF P51 Any when last days I got a request regarding the TF P51. It seems, that I accidently deleted this message. Therefore I cannot find the originator anymore. But here my answer: I was not aware, that the TF is that different from the one seater P51. I will have a look to the cockpit radios and its logic. If it is possible, I will add the TF to the list of supported models.

Sorry, this was ambiguously worded. The new models are in the release version only.

Version 1.976 Dear Aries users, Version 1.976 of Aries Radio is now officially available on the Aries download page http://ariescon.com/index10.html Version 1.976 contains the following bug fixes and new features: Communication quality dialog The Horizon Bug is fixed and the function may be enabled again. The selected quality values are stored in the INI file so that the configuration is set automatically with the next mission start. Protocol File The protocol file generation is moved to a separate application. All protocol messages are centralized in only one file for all Aries applications. This ensures, that probable bugs in the protocol file will not impact the running application. Furthermore, the performance is not dragged down, if complicated and long messages have to be interpreted and stored. The common protocol file can be found now at: C:\Program Files\AriesWings\PRCL\ApplicationData\Aries_Session_Protocol.html The activation of the protocol was removed from the configurator. The protocol generation is active permanently. IFF/SIF There is an additional hardware key configuration for IFF/SIF. This will be used with the coming Aries Radar software. If you are requested to squawk ‘ident’, you can trigger it with this key. New models The following models are now added to Aries Radio: Bf-109K-4 Mi-8MT Beta Testers The release version 1.976 has no new features compared to version 1.976 beta. The only difference is the appearance of the protocol application. However, if the release version shall be installed, take care, that AriesProtocol.exe is deleted from C:\Program Files\AriesWings\PRCL, before you install the release version. The reason is a version detection mismatch caused by the Aries Radar installation.

If Aries still works with DCS-BIOS enabled. It would be the better choice to post the problem in the DCS-BIOS thread. Aries takes care, that the export interface chain is not interrupted (LuaExportBeforeNextFrame, LuaExportAfterNextFrame, LuaExportActivityNextEvent).Nevertheless, I could have a look to your log file for unusual situations. For that you have to enable the log file creation in the configurator first. After a session you find the required log file at DCS World\AriesWings\logs\AriesAirborneRadio_log.html. send the file to support @ariescon.com

Example A10: DCS World\Mods\aircraft\A-10C\Cockpit\Scripts\clickabledata.lua for buttons and MainPanel IDs DCS World\Mods\aircraft\A-10C\Cockpit\Scripts\devices.lua for device IDs I did not test whether TACAN and ILS support the the 'is_on()' function.

If you go via export.lua, you can use the the DCS interface function [radio device id]:is_on(). Example: if BoxOneRadio:is_on() then Box1usable = 1 else Box1usable = 0 end if the returned value is 1 then it is ensured, that the radio is powered and usable. The logic covers the entire power chain like power switches, batteries, generators and external power.

The radio software does not use any port. It uses inter-process communication. Try to change the sequence of the ‘dofile’ entries in export.lua. Since I do not use DCS-BIOS, I cannot test this configuration.

To be sure, I just made the test again. Full screen works with some limitations. As long as you leave the Aries panel on a second monitor. If you drag the panel into the DCS window, it disappears into the background. Full screen seems to be bound to a situation if the DCS window covers only one single monitor. If the DCS window is spread over two or more monitors, the behavior changes back to windowed mode and the Aries panel stays in the foreground again. If someone likes, he can use this configuration. But the radios must then be controlled out of the cockpit if DCS uses a single monitor only. Older versions of DCS did not like Aries with full screen mode active. The simulation crashed immediately. The full screen allergy story of Aries came from that times.

Full screen mode is still not possible and I see no chance to solve this problem. The reason is the additional Aries radio panel, which must be visible all the time on top of the DCS screen. In full screen mode, the entire window z-order is under control of the DCS application. The Aries panel is not usable anymore. In difference to older DCS version, the program does not crash if started with Aries in full screen mode. There would be some black magic possible if I would hack the internal DirectX function scheduler. But this would interfere the DCS program code which must be prevented in the interest of the software creator. BTW, all damaged trees are removed and we are in a good health with the exception, that my body is stiff by all this lumberjack work.

NIKLAS visited my house... Dear Aries user, because of storm damages at my property I can only offer limited service for the rest of the week. I beg your comprehension, TOWSIM

What I found out so far: First Test environment 2 computers in a LAN first computer drives the TS server and a client second Computer drives a TS client only Connection established with two GossipBoxes Every PTT causes 100000 messages in a loop Test 1 Settings are Reduced points per tick1 Points needed to block commands99998 Points needed to block IP99999 Result No anti-flood message Test 2 Settings are Reduced points per tick1000 Points needed to block commands99998 Points needed to block IP99999 Result No anti-flood message Test 3 Settings are Reduced points per tick100 Points needed to block commands150 Points needed to block IP250 Result No anti-flood message Second Test environment 2 computers connected via internet Server anywhere in Bavaria first computer drives a TS client (weak performance) second Computer drives a TS client (strong performance) Connection established with two GossipBoxes Every PTT causes 100000 messages in a loop Test 1 strong sends to weak Settings are Reduced points per tick1 Points needed to block commands99998 Points needed to block IP99999 Result No anti-flood message Test 2 strong sends to weak Settings are Reduced points per tick1000 Points needed to block commands99998 Points needed to block IP99999 Result No anti-flood message Test 3 strong sends to weak Settings are Reduced points per tick100 Points needed to block commands150 Points needed to block IP250 Result No anti-flood message Test 4 weak sends to strong Settings are Reduced points per tick1000 Points needed to block commands99998 Points needed to block IP99999 Result anti-flood message after 01:30 min Conclusion It seems, that the anti-flood configuration is not the reason for the anti-flood block. In the LAN, it was not possible to produce the anti-flood messages with different settings. With a connection over the internet it was possible to provoke the situation if the weak computer fires 100000 messages in a loop. Vice versa, if the strong computer fires the messages, no anti-flood comes up. The anti-flood seems to be in relation to network speed and performance of the transmitting computer. So finally I have no idea how to set the anti-flood values to prevent the messages. If there is a TS specialist here in the community, it would be welcome if it could be explained how the TS cogwheels are running.

I will do a test run with different settings to provoke anti-flood. The results will be posted here.

The minimum TeamSpeak version required is 3.0.14 (64 bit) If the spam message appears permanently, try the following TeamSpeak setting: Right click the Server symbol in the TeamSpeak tree (left window, first line) In the opening dialog select Anti-Flood Set ‘Reduced points per tick’ to 1 Set ‘Points needed to block commands’ to 9999 Set ‘Points needed to block IP’ to 9999 You need administrator rights for your TeamSpeak server to modify these settings. To modify the com quality settings you should use the quality settings dialog only. If you want to go with concert quality you must set the sliders with every mission start. For details see the Radio User Manual on page 25 and followings. The radio versions > 1.973 will hold the settings once defined in the quality dialog.

@Rossi It is a bit hard to determine, what’s going on. Which application shows the error message? DCS, Aries Wings or TeamSpeak. In any case, in the folder, where SetUp.exe was started, you will find a file named AirborneRadioInstaller_log.html. The content can be shown with the internet explorer. If anything was wrong during the installation, you will find it there in. Regarding the administrator rights, even DCS and TeamSpeak must be started with administrator rights. You can set this item permanently in the desktop icon’s properties.If all this does not help, send the following files to support@ariescon.com : [setupFolder]\ AirborneRadioInstaller_log.html DCS World\AriesWings\logs\ AriesAirborneRadio_log.html C:\Program Files\TeamSpeak 3 Client\plugins\AriesRadio\AriesRadioLog_log.html C:\Users\[your username]\Saved Games\DCS\Logs\ dcs.log If exists: C:\Users\[your username]\Saved Games\DCS\Logs\DCS-20150214-150614.crash I will try to find the reason for the crash.

@Mr.White OK, let’s go one step deeper. Please activate the protocol function in the GossipBox configurator (GBO configurator) and in the Airborne Radio configurator (ARD configurator). Both programs have a check mark to enable the protocol message file generation. Then start the Aries Software to provoke the crash. You should do it one time with the GossipBox and one time with DCS and Aries enabled. You find the resulting HTML files at: C:\Program Files\AriesWings\GossipBox\AriesGossipBox_log.html And DCS World\AriesWings\logs\AriesAirborneRadio_log.html Please send the files together with the TS dump files to support@ariescon.com.

@Mr.White I had a look to the source code and compared your description with the situation during a reception. The blue light is controlled by TeamSpeak and indicates an incoming voice package. The only critical action in Aries at that moment is the receiver quality check. The quality check includes even the horizon calculation, which has the reported bug.Furthermore, if the Eavesdropper is active, the quality check I passed by. These all points to the quality check. When you unpushed all the buttons, did you push the send button after all? Only if the send button is pushed, the changes become active. The new configuration is not stored in version 1.973. Therefore you find the old configuration with the next start.

To all participants of the yesterday stress test with the 132nd VirtualWing To verify the reason of the communication slow down during the yesterday stress test with Aries radio, I made some measurements with DCS, TeamSpeak and the network load. The calculations base on an 8 Mbit internet connection. TeamSpeak With the default setting of Speex Ultra Wideband at quality 7, the documentation specifies a bit stream of 25600 bits per second. With the network overhead for each package, the actual rate is (measured with Wire Shark) 37504 bits per second. As a result, an 8 Mbit internet connection should allow theoretically up to 213 clients speaking at the same time (8 000 000 / 37 504 = 213.3105). DCS I used a mission with 39 AI aircraft in the air and 20 ground vehicles active moving. The entire network traffic measured between the server and one client was 156 192 bits per second. The yesterday setup was about 50 clients which should cause a load of 1 875 200 bits per second for the radio, if all clients would speak at the same time. This would leave 6 124 800 bits per second (6.125 Mbits) for DCS. Conclusion The only answer seems to be, that the TeamSpeak Server is source of drag downs. The server has to receive the voice packages of all clients and has to deliver the entire amount to all clients. I have no clue what the server has to do beside this package management. While the client has only one connection to the server to send and receive, the server has to have a one connection per client. This means, each voice package has to be repeated 50 times, if 50 clients are in the same channel. If all are talking at the same time, the package management as to handle 50 x 50 packages (receiving 50 and transmitting each package 50 times). This is 50 times more than a client has to handle as maximum. An often heard argument is, that a conference of 100 people works with TeamSpeak. The difference is, that even with this number of people normally only one is speaking while all others are only listening.The Aries concept allows to speak at the same time for all participants in a channel, because they are filtered by frequency on reception. DCS has other problems which are not network related. The load I have measure is far too low to impact the network capacity. Since it seems, that we have reached the capacity of a normal TeamSpeak server, I would recommend not to exceed ~30 radio participants in a mission. Last not least, I want to say ‘thank you’ to the 132nd who gave me the opportunity to observe such a stress test. The same ‘thank you’ even to all participants for their patience during the test.