744 Forum

Apron => Accessories => Topic started by: martin on Sat, 21 Mar 2020 16:32

Title: NEW: PSX_Wheramium, a moving map
Post by: martin on Sat, 21 Mar 2020 16:32
UPDATE 13. August 2020
A (small) update to PSX_Wheramium v.02 is now available.
See the updated documentation (http://www.saunalahti.fi/erdel/psxwher/PSX_Wheramium_Docs.html) for details and download link.
Have fun! Martin


Original announcement:

Greetings,

over the last weeks I have struggled to "pare down" PSX_Tellurium to a simple (ha!) 2D moving map, the outcome being PSX_Wheramium.

Making "simpler" an application cobbled together* five years ago is a complicated task at the best of times, but the fun was greatly increased by frequent system crashes suffered during the work on this little project; sometimes several per day, sometimes one in three days (always when I thought the issue had finally been solved). No CTDs, no BSODs, just uncommanded reboots; thus no diagnostic screens, and also no traces in the Event Log etc. (other than the informative message, post factum, that "the previous system shutdown was unexpected", which I generally had already noticed).

Eventually some "distributable" was produced nevertheless, but I am rather suspicious of the product. It still seems to put undue loads on the CPU (an i7-8700 at 3.2 GHz; perhaps not quite cutting edge but no slouch either), frequently pushing it into uncomfortable temperature ranges (up to 80°C and sometimes even beyond). Then again, perhaps it's just me: gamers seem to regard this as an OK temperature. Still, some serious optimisation is clearly indicated, but equally clearly beyond my paygrade (a.k.a. level of cluefulness).

Moreover, even with modest settings (details in the doc.s) the map runs rather stuttery (obviously also depending, among other things, on the aerial/satellite images having already been cached vs. being downloaded for the first time).

So, normally I would not release anything like this to an unsuspecting public.

However, there are indications that these problems have to do with my specific computer rather than with the program. I had the same issues (and worse) when I tried the old PSX_Tellurium on this (new) machine, but I know that at least three other fellow PSXers can still run that with no problems.
Besides, very recently, for crash #21 (of the 24 over the last four weeks), Windows actually managed to generate a dump file, and this (if it can be trusted) seems to point to a video driver issue**, to be sorted out later.

So in a way it might be overly "harsh" to withhold Wheramium (only because of my issues) from those who were kind enough to clamour for a moving map and thus meaningful taxying.

But you have been warned. Proceed at your own discretion and risk.

The documentation is here (http://www.saunalahti.fi/erdel/psxwher/PSX_Wheramium_Docs.html).
(The ZIP file contains a local copy.)
Please do read before trying, even though it looks the same as the Tellurium doc.s.
It isn't.   :D
It also contains the download link.   ;)

Good luck!

Cheers,
Martin "M---ovi-n---gM-a--p" E.
(Moving Maps as Expl.OS.ive Devices a specialty)

* Java, webpage serving, Javascript, webpage clienting, CesiumJS API,
     threads, HTML, jQuery, CSS, AJAX, HTTP, TCPIP,  ...

** "VIDEO_TDR_ERROR", which I interpret to mean that the video driver does not talk to Win10 every 2 seconds at the latest, because it (the driver, not Win10) is trying to do something useful, such as some actual work for the user and his application. Upon which Win10 goes into high dudgeon, throws that error and thus crashes the box.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Pierre Theillere on Sat, 21 Mar 2020 17:15
Hi Martin,

Wow, it's running fully fine under MacOS 10.14.6 and Safari 13.0.5! I tried using my Android tabled with Chrome, and I get a big "Go Away" (in yellow with red background), will try with some old iPads gathering dust to see how it goes...
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sat, 21 Mar 2020 18:42
Bonsoir, Pierre,

thanks for the encouraging feedback :)

Quote from: PierreI get a big "Go Away" (in yellow with red background)

That's a feature, as a (sort of) security measure (same as it was for Tellurium earlier):

The  built-in webserver has a list of the Wheramium files which it may serve on request.
If it gets a request for anything else, it will only send that red "Go Away" page.

So the question is now, what "illegal" request had been made... Or was it a mistake?
(I think we had the same issue once with Tellurium; I'll try to find out more.)

EDIT: Found it, see this post .
In that case, a wrong URL was used; let's hope it's something equally simple now...

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: cagarini on Sat, 21 Mar 2020 19:06
Wow !  Martin !!!  Ya did it again !!!!!

I am back to PSX with my preferred visuals !!!!!!!!!!!!

Thank you so so much !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Tested it in a small circuit around LPMA and it was super smooth - no CPU heat detected ( i5 2500 2011 model ) and no problems with the GPU either ( GTX 960 4 GB ).

For browser I used EDGE.

Superb!

(http://www.hoppie.nl/forum/var/Wherarium.PNG)
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Sun, 22 Mar 2020 02:34
I will try tomorrow, thanks!
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Robert Staudinger on Sun, 22 Mar 2020 11:09
Hi Martin,

it is not possible to open the PSX_Earth documentation, no URL found.

Wheramium suggests to read Tellurium and Tellurium suggests to read PSX Earth.

So I'm not able to configure Google Earth.

Everything else looks good: After starting Wherarium.jar and loading Wherarium.html into the browser there is a correct connection and correct Lat/Lon position showing, the same as in PSX.

Regards Robert

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Sun, 22 Mar 2020 13:00
Hi Martin,

thank you for the nice add-on. I'm using your default settings, and it works fine on my iMac and Firefox. Quickly started, no heat, no frame rate problem.


Regards,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Sun, 22 Mar 2020 13:04
A short test run on Chrome and no problems.
However, can you increase the zoom out?

Cheers,
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 13:07
Hello Robert,

Quote from: RobertTellurium suggests to read PSX Earth.

Ah yes, sorry, that's a glitch in the documentation.
I was trying not to re-write all of the old doc.s for the new Wheramium, hence the pointer to Tellurium (just for background info), but I forgot that Tellurium (which is five years old) in turn still points to the PSX_Earth doc.s (which are four years older still, more or less from the time when mammoths roamed the Earth...).

But the PSX_Earth documentation is no longer really relevant (except for the historian), and therefore I had removed it from the website long ago, but forgot to change the Tellurium reference.

UPDATE: For the sake of history buffs and nostalgicians, the PSX_Earth documentation has now been restored. :D

In fact, much even of the Tellurium doc.s is not relevant for Wheramium either any more, because all the complicated "3D view" and "Belly Cam Control" stuff has been thrown out in Wheramium.

So if you are not interested in the general background and history, it should not be necessary to refer to the PSX_Earth or Tellurium doc.s at all in order to run Wheramium.
But if any questions remain, please ask here on the forum!.
I'll fix the Tellurium doc.s and will remove or comment the pointer to PSX_Earth. Or may be I'll even restore the PSX_Earth documentation, but only for trips down Memory Lane... :D

Quote from: RobertSo I'm not able to configure Google Earth.

Note that Tellurium already had switched from Google Earth to Cesium as the map provider.
(That was in fact the reason to develop PSX_Earth further into to PSX_Tellurium: Google had stopped the support for the kind of interface that PSX_Earth needed.)

Wheramium is still based on Cesium. But it should not be necessary to configure anything on the Cesium side*.
All you have to do is to set up PSX (the Boost server) and Wheramium itself (the INI file); both of which already works for you (i.e. the coordinates do show up properly); so you are just missing the map from Cesium for some reason.

Cheers,
Martin

* Obviously your browser (and tracking blocker, firewall etc., if you use them) must allow the display of Cesium data (maps), as these come from external 3rd party servers (Cesium and Bing). But they use a normal webpage type connection, so for the browser it's just usual content, nothing special.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 13:32
Hardy and Avi,

thanks for the good news! :D
It is becoming clearer by the day (and user feedback) that I need to work on my ability to stay cool.

Quote from: AviHowever, can you increase the zoom out?
Technically not a problem (I think...), but by how much?

E.g. when I am at FL340, I can see, at max zoom-out, most of Europe already now:
(Click image for full size.)

So, probably you need it for zooming on the ground at some airport?
But as mentioned, I have found the current zoom range to be sufficient (for taxying) even at EHAM, which I thought to be the airport that needs the most zooming out (even if initially at 1x it looks "broken").

So, what would be the specific situation you are referring to?
Just to give me an idea what  may need changing by how much.

Cheers,
Martin



Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Sun, 22 Mar 2020 13:56
Quote# POLLINTV: interval (msec) at which the Wheramium _PSX client_ requests coordinate updates from the PSX _Boost server_

This note surprised me a bit because the boost server doesn't provide any request functions. It just sends its stuff as per the frame rate limit setting in the PSX preferences. Maybe you meant to write that one part of your software copies data from another part of your software at the defined interval?


|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 14:31
Quote from: Hardythe boost server doesn't provide any request functions

Yes, bad terminology (hopefully not design) on my part, a misplaced residue from the Javascript/HTTP side where there are genuine GET requests... (and perhaps the term "POLL"is not much better).
The Boost server is of course sending data all the time, at the rate set in PSX.

But my client actually consumes them and passes them on for further processing in Wheramium only every POLLINTV milliseconds.  The idea being* that Wheramium would probably choke on 72 "records" (lines) per second, but throttling the PSX frame rate merely for the purpose of a moving map seemed inappropriate...

INI file with improved(?) wording is here.
(I don't want to repackage the whole ZIP file, so this "update" is an exclusive bonus for the readers of this thread! :D )

Cheers,
Mar..POLLINTV..tin

* This is all grounded in my thermophobia, i.e. the fall-out from those >80°C experiences...
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Robert Staudinger on Sun, 22 Mar 2020 15:42
Hi Martin,

works now perfect. Most useful for taxi.
But now another question: is it possible to show the map on a screen of my second PC within the network.

Notebook(win10, very powerful) : PSX and Wherarum.jar

PC(win7, old)

The reason for all this is due quarantine in my summerhouse because of Corona.

Cheers, Robert
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Sun, 22 Mar 2020 15:47
Just curious. Why the Boost server? Main not detailed enough (in time) for smooth motion on the ground?
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Sun, 22 Mar 2020 15:53
The Cesium map runs at 10 Hz or higher. The PSX main server's position data output runs at 5 Hz.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 17:47
Hello Robert,

Quote from: Robertis it possible to show the map on a screen of my second PC within the network.

Good question. Unfortunately I can't test it as my second box died some time ago.
But it "should" work... Let's see:

Wheramium needs to know where to find PSX (i.e. the Boost server).
It finds this info (IP address and port number) in its INI file.
(This INI file must always be in the same folder as the JAR file.)

When PSX and Wheramium are on the same machine, this address is usually 127.0.0.1 and the port is 10749.
So now Wheramium can talk to PSX.

The browser then needs to know where to find Wheramium.
This is the address (URL actually) you put into the browser address bar.
If it is also on the same machine, the URL would be
http://localhost:10314/PSX_Wheramium.html
(localhost is just another name for 127.0.0.1, and 10314 is the port for this connection).

If PSX and Wheramium sit on different computers, then the URL for the browser would look e.g. like this
http://192.68.1.17:10314/PSX_Wheramium.html
(Replace 192.68.1.17 with whatever the actual address for the PSX machine is in your network.)

The browser will get the Wheramium webpage from wherever, as long as the address is correct, just like when you surf on the Internet.

And if it all works, you can then try and have PSX, Wheramium (JAR file and INI file) and the webpage with the map on three different computers... ;D

Good Luck!

Cheers,
M------ar---------tin

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 18:10
Quote from: HoppieWhy the Boost server? Main not detailed enough (in time) for smooth motion on the ground?

My answer would have been "for hist{o|e}rical reasons". When I started with the old PSX_Earth v.1 (using stand-alone Google Earth), or possibly even earlier*, my impression at the time was that not all systems (including mine) could handle the Boost frequency (or may be Boost was not even available yet?)**.

So I ended up, later, making two Tellurium versions, one for use with the Main and one for the Boost server. But later the Main variant became sort of obsolete, and thus only Boost survived. Obviously a true (fake) 3D "cockpit view" requires all the update speed it can get; a moving map is less critical (and has less to do anyway).

But as Wheramium is based on Tellurium I stuck with Boost even though it's now merely for a 2D map. Otherwise it would have become a major re-write. (It did so anyway, but I didn't know that :D ).

Of course Hardy's reply above is much more to the point. That was the rationale for my decision! :D

Cheers,


* Only when reviving the PSX_Earth doc.s earlier today, I was reminded that there had even been a PS1_Earth before that; I can't remember for the life of me what that was and how it worked. Must excavate!

** Actually it wasn't all that hist{e|o}rical, I did have good reasons after all (forgotten by now).
If you have social-distance time to kill, you can read this detailed justification (for the Main / Boost split).


Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Robert Staudinger on Sun, 22 Mar 2020 18:15
Hello Martin,

thanks for all your advice but unfortunatly it does not work. I tried all this some hours ago already.

In the beginning everything looks good: After starting Wherarium.jar and loading Wherarium.html into the browser on the second machine I get a correct connection and correct Lat/Lon position showing, the same as in PSX. But it does not open Cesium.

By the way, my setup here in the mountains consists of two computers with three screens.

Cheers Robert

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Sun, 22 Mar 2020 18:23
Do you run a PSX client on your second computer? If so, you can use the boost server of that PSX client for your Wherarium on that second computer.


|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Sun, 22 Mar 2020 18:42
Yup, worked. Interesting that if you switch labels on, they appear as graphics, not à la Google Maps as overlays that remain oriented up. Not that I mind.

Next... use aeronautical maps and charts instead!    :-P

https://skyvector.com

Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 18:44
Hello Robert,

if you can see the correct coordinates on the web page, it means that Wheramium "per se" does work: the data are coming from the Boost server to the PSX client built into Wheramium), and then the webpage gets them from the webserver (also built into Wheramium).

The part not working for you is thus the delivery of the actual map or satellite image from the Cesium/Bing servers.
And that can have many reasons.

Instead of a map, do you see a large empty brown area?
Or do you see some kind of black textbox there, with a lot of (incomprehensible) Cesium error messages in yellow?

If the area is simply empty (just the brown background): This happened to me frequently. The reason is that I am running an anti-Schnüffel plugin for Firefox (uBlock origin), and often forgot to tell it that data coming from "virtualearth.com" (which is the Bing map server address) are OK and should not be blocked.

So perhaps this, or something similar, in your setup, too, is blocking it? Hard to say from the distance.

BTW, which browser are you using anyway?

If you use Firefox (Google Chrome has something similar), you could open the Developer Tools (in FF: ctrl-shift-i), and go to the "Network" tab.
This will show all GET requests made from the webpage to anywhere. The requests to the Wheramium webserver address (see browser address bar!) should all have a "200" flag (meaning "request and reply OK").
If there is any other number, it would tell us more about the problem. (E.g. "404" means something the webpage requested could not be found on the server, etc.).

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 22 Mar 2020 18:50

Quote from: HoppieNext... use aeronautical maps and charts instead!    :-P

You did get the Road Map at least... :D

Cheers,
<Martin
   O  O

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hessel Oosten on Sun, 22 Mar 2020 19:37
QuoteYou did get the Road Map https://i.ytimg.com/vi/kcBD4sJ6fuc/maxresdefault.jpg (https://i.ytimg.com/vi/kcBD4sJ6fuc/maxresdefault.jpg) at least...

Heeee, is that Steff's bus ???

H.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Sun, 22 Mar 2020 19:39
Quote from: martin on Sun, 22 Mar 2020 13:32

Quote from: AviHowever, can you increase the zoom out?
Technically not a problem (I think...), but by how much?

Martin,

I checked it only for few minutes on the ground.
Max zoom in was too much, I couldn't see a thing and had to zoom out.
Max zoom out was also too much for taxi, I had to zoom in to see the taxiways.
That means it is ok for ground operations.

I still didn't check it inflight but if it looks as in your print screen (and I'm sure it is), it is ok too so no modification is needed.

Cheers,
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Sun, 22 Mar 2020 20:21
@Hessel. No it isn´t my bus... :-) mine is much nicer ! :-)

Guys,
I have no cheance to get this stuff to run. After Connecting the page gets black and a failure message occurs

RangeError: invalid array length
updateFrustums@http://localhost:10314/cesium_min/Build/Cesium/Cesium.js:139930:9
createPotentiallyVisibleSet@http://localhost:10314/cesium_min/Build/Cesium/Cesium.js:140080:27
render@http://localhost:10314/cesium_min/Build/Cesium/Cesium.js:140494:36
Scene.prototype.render@http://localhost:10314/cesium_min/Build/Cesium/Cesium.js:140534:19
tick@http://localhost:10314/fetchCoords.js:181:9

Any help?
Best
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: cavaricooper on Sun, 22 Mar 2020 20:42
Steff-

I got caught out by the PSX port (mine is the default 10747 not the one that Martin uses).  Once I changed that it all started working.  It appears that you may be running port : 10314.  Is that intentional, and does your Boost Server broadcast on that? I'm not a genius at networking, so perhaps Hoppie or some other kind soul will look in soon.

I did not change the IP as it runs on the machine that a Boost Server runs on.

HTH- C

PS- Martin- Ta mate!
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Sun, 22 Mar 2020 20:51
Hi Carl,
after reloading the machine it seems to work now..But wondering about just 20fps now...

Testing yet...
Best
Steff

P.S:disregard, doesn´t move the aircraft position in the webbrowser.. still just 20 fps alsowithout using the program... hmm..
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Mon, 23 Mar 2020 02:25
I installed and ran it with no initial problems.

But PSX runs at about 25 fps (down from 72 fps), and the moving map tends to magnify PSX movements. Like if PSX makes a minimum radius turn on the ground at 3 kts (per GS display on the ND), then the Whereamium map shows a turn with a much increased radius, maybe 10 times as large. There's no way to stay on the Whereamium map's runway, even if the aircraft is still on the PSX runway. I did not have time to troubleshoot.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 06:49
Hello Avi,

Quote from: Aviso no modification is needed.

I'm glad to hear it. :)

The problem here is that the program has to start with some initial zoom value (I decided on 1x), which will always be OK in some situations but not in others, depending on where you are, and how high above ground. So some initial manual correction will always be needed (at least until the day when I add Artificial Intelligence).

Still, the zoom range could be changed if necessary.  If someone else encounters difficulties, please report, including a description of the situation where the current zoom range was not sufficient.

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 06:54
My greater problem is that I still get just 20 fps since I tried to use Wheramium yesterday. No Idea how to get back to 50 or so...
Any ideas?
Best
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 07:13
Hello Steff,
Quote from: SteffAfter connecting the page gets black and a failure message occurs:
RangeError: invalid array length
updateFrustums@http://localhost:10314/cesium_min/Build/Cesium/Cesium.js:139930:9
...

This is a tricky one, alas.

Somewhere one of the Cesium contributors themselves described it as "unfortunately kind of a catch-all error from the inside of the Cesium render loop", meaning it will pop up for all sorts of very different reasons (some of them deep inside the Cesium engine), and will give not many clues to the actual cause.

I have seen this, too, when I had actual errors in my Javascript code. But that cannot be the cause here, for then everyone would run into this.

The other possibility is (perhaps) that for some reason, the Cesium/Bing map data do not arrive in your browser.
You could try and monitor the net traffic via the Firefox or Chrome Developer Tools (see above), or check if the Console tab (also in those Dev Tools) shows any Javascript error messages.

Alternatively, try one of the Cesium demos to see if the problem is only with Wheramium or with Cesium use in general.
For the most simple test, go to their "Sandcastle", and if not already visible, select the "Hello World" example at the bottom.
Ignore the left hand box with the code, enlarge the right hand box (with the Earth) to full screen, and see how it goes.

Other than that it's hard to give advice without involving more debugging tools.

Cheers,
Martin


Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 07:31
Hello Carl and everyone else,

Caution with the port numbers!

Quote from: CarlI got caught out by the PSX port (mine is the default 10747 not the one that Martin uses).  Once I changed that it all started working.  It appears that you may be running port : 10314.  Is that intentional, and does your Boost Server broadcast on that?

Some confusion here perhaps.

To clarify:
¤ 10747 is default the port for the PSX MAIN server; alternatively it can be changed to 10748 (in the PSX Preferences)
¤ 10749 is the port for the PSX BOOST server; this can not be changed (I think).
¤ 10314 is the port for the Wheramium webserver; hardcoded and thus cannot be changed either.

So the address "//localhost:10314/etc" in that cryptic Cesium error message is actually correct and not the reason for the error.

To complete the confusion, I have painted a clarifying picture. The upper part shows the configuration where everything is on one computer.
The lower part is the setup where PSX+Wheramium are on one box, and the browser with the map on a second one.

(This is a thumbnail only! >Click on image for readable full size! :) )

Hope this helps.

Cheers,
Martin

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 07:46
Hi dear Martin,
thanks for the last explanation. For now I just want to get my good FPS back to 50 or so... Do you have an idea how your program can influence the fps in PSX ?
Since I tried it out yesterday I just have 20 fps instead of 50, seting 48.

best
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 07:56
Hello Steff and Will,

in this reply I'll address only the more urgent problem that low fps don't go back up again even when Wheramium is (supposed to be) closed:

Quote from: SteffI still get just 20 fps since I tried to use Wheramium yesterday. No Idea how to get back to 50 or so...
Any ideas?

Why the fps goes down at all  so much is a mystery in itself*...
But it certainly should not stay down once Wheramium has been exited.

The only thing I can think of is that Wheramium is in fact still running in the background.
¤ Did you use the EXIT button in order to stop the program?
¤ If so, what did the bottom of the web page say afterwards?
(See the doc.s about this.)

To verify if Wheramium has really stopped, check it in the Task Manager ("Details" tab) or in Process Explorer if you have it.
If you find a process for "javaw.exe" (and you are not running other Java programs except PSX), kill it.
!!! Do  not kill "java.exe" as that will be the PSX process.

BTW:
¤ When you say you "can't get back to 50 fps or so", do you mean not even after restarting PSX?
And not even after stopping the Boost server, too, to make sure it is not talking to Wheramium or its zombie process?

EDIT: With regard to your latest post above (was crossing with my reply):
Just for completeness: Did you since yesterday reboot the computer? If you did, there is of course no chance anyway that Wheramium is still running. And it does of course not mess in any way with the permanent PSX settings.
If you did not reboot, try Task Manager as mentioned above.

In any case: even when still running (but not actually connected to PSX, and not actually moving the map), Wheramium should not be able to infliuence PSX or its frame rate in any way. Something else is going on here...

Cheers,
Martin

* I'll send another reply later about the issue that the PSX frame goes down dramatically when Wheramium is being used.

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 08:35
Hi Martin,
found javaw.exe and killed it, no change in fps. restarted the computer after switching off yesterday evening.
further investigation needed..:-)
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 09:10
Installed PSXfresh from the disk, version 10.1.7 in a new folder and also just 20 fps, so it seems there is something wrong with my system at all... hmm...
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 09:19
Hello again, Will and Steff,

regarding the steep decrease in PSX frame rate you are reporting (I am assuming this is the frame rate as indicated by PSX itself):

Quote from: WillBut PSX runs at about 25 fps (down from 72 fps), and the moving map tends to magnify PSX movements. Like if PSX makes a minimum radius turn on the ground at 3 kts (per GS display on the ND), then the Whereamium map shows a turn with a much increased radius, maybe 10 times as large

Quote from: SteffMy greater problem is that I still get just 20 fps since I tried to use Wheramium yesterday.

As far as PSX is concerned, Wheramium is strictly "read-only":
¤ The PSX Boost server pumps data out as it always does (at the frequency set in the Preferences, e.g. max. 73 fps),
¤ Wheramium (PSX client part) reads them at user-defined intervals (POLLINTV in the INI file)
¤ and the webpage fetches (requests) them from Wheramium (webserver part) at other user-defined intervals (REQINTV in the INI file).

At no point does Wheramium send anything to PSX, let alone try to control any of PSX settings or behaviour.

So if the fps go down, the only thing I can think of is that running Wheramium (over)loads the system (CPU or possibly graphics card, etc.) so much that PSX is slowed down far below its set frame rate limit.

If and to what degree this happens is of course highly dependent on the hardware, the operating system, and the general system configuration.
But with current boxes, I find it difficult to see how Wheramium can force the fps value down from ca 50 or even 70 to ca 20 or even lower, just by putting extra load on the CPU etc.

Things which were good to know:

¤ When exactly does this slow-down happen?
   ¤ As soon as Wheramium is started (but before the webpage is loaded in the browser)?
   ¤ As soon as the webpage is loaded (but before it is connected to Wheramium/PSX)
   ¤ Only after the connection is made (and the map is now actually being updated constantly)?

¤ Similar: At what point does the frame rate go up again (if it does, which is not the case for Steff).

¤ Also: try to vary the REQINTV and POLLINTV settings. making Wheramium fetch and process the data at large intervals,
e.g. POLLINTV=200 (data read from PSX only 5x per second),
and REQINTV=500 (data requested by browser only 2x per second),
The map will then stutter badly of course, but the point is to see if this relieves the CPU and thus helps with the slow-down of the PSX frame rate at all.
 
Finally: a test.
(I am aware the situation may be overly "favourable" for Wheramium (i.e."best case"), but it should be on the ground (because of the taxying problems reported by Will), and it should use a SITU which is the same for all of us. Feel free to suggest other situations to test... ;)

¤ load the situ "Basic 004 - Cleared for takeoff.situ"  which comes with PSX.
¤ start Wheramium (if possible from a Command Prompt, to see any error messages)
¤ load the webpage for Wheramium
¤ (optional: open the browser's Dev Tools so you can monitor any error messages on the webpage side, and perhaps also the GET requests)
¤ connect webpage to Wheramium/PSX
¤ zoom out until the coastline/surf becomes visible at the left edge of the screen*
¤ check that the "heartbeat" indeed shows activity (numbers changing), and that the correct coordinates are displayed
¤ in PSX, unlock the parking brake
¤ in the Instructor (Situation > Position > TAS field) set a ground speed of 12 kn
¤ let her trundle down the (extended) runway with throttle at idle (speed will increase anyway by a few knots, it's a 744)
¤ take the first exit to the right (shortly before the actual threshold)
¤ roll on to the apron and do some more turns etc at your discretion.

On my box, during all of this exercise, I never saw a PSX frame rate less than 73 fps. I took the turn (and some more on the apron), somewhat boldly but intentionally, at 19 kn and had no issue with the turn radius. Also, frame rate was still not affected (although turns always generate higher loads).
I didn't even see a major increase in CPU temperature (which perhaps indicates the test is indeed too "harmless"?? ;D) 
Obviously, YMMV.

Will: If I understand correctly, you are seeing these wrong turn radii only on the map but not in PSX itself?
Which would mean that map movement and PSX are actually not in sync?
This is strange: what I would expect (if the map lags behind the actual movement and cannot catch up) is that it jumps, but even then it should not be able to put the marker to a position which is different from the PSX one (although perhaps delayed).
In other words: instead of a smooth arc, the marker would describe a kind of "polygon", jumping from one corner to the next, but the radius should still be the same, and those marker positions which are displayed (even if updated at large intervals) should still be in the respective correct places.

Cheers,
Martin

* I realise only now that the zoom value in the webpage display should have more decimals; only one decimal is not informative for the lower range.
(It used actually to be 4 decimals during development, and then I overcorrected... :) )
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 09:21
Quote from: Stefffresh from the disk, version 10.1.7 in a new folder and also just 20 fps
Over to Hardy...  ;D

Cheers,
Martin

PS.
Random idea: Could this be a *.situ thing?
Something wrong buried in the situ which thus survives even restarting the computer?
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Mon, 23 Mar 2020 10:07
Quote from: martin on Mon, 23 Mar 2020 09:21
Random idea: Could this be a *.situ thing?
Something wrong buried in the situ which thus survives even restarting the computer?

Nope.

Fresh from the DVD there isn't even a saved situ but a fresh situ from the DVD.

Maybe Firefox taking all resources since the last experiment?


|-|
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Robert Staudinger on Mon, 23 Mar 2020 10:13
Hello Martin,

everything works with Firefox perfect and FPS is 73 to 74. Chrome or IE11 produce a nice error screen as you predicted.

Hardy, my screen is just 18cm diagonal, the setup in my Covid19 retreat is very provisionally.

Thanks to both of you for your help, Robert

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 10:51
Me again, did a flight yet and it doesn´t feel like 20 fps, no stuttering at all, smooth as ever.. strange thing..
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 11:23
Hello Robert, Steff, and everyone else,

glad to hear progress is being made.

Quote from: RobertChrome or IE11 produce a nice error screen as you predicted.
In the meantime I have heard (offline) that running the map in a browser on an iPad also does not work.

One possible(!) reason could be that the mini-webserver built into Wheramium uses the old HTTP protocol (should be safe enough in this case as it is only a local connection; and the server will in any case serve only legitimate stuff, or else say "Go Away!" :) ).

But the browsers more and more move towards accepting only HTTPS connections; may be that is why some of them won't play with Wheramium.

Cheers,
Marttpsin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: cagarini on Mon, 23 Mar 2020 11:24
Only thing I noticed in my Win 10 is that when I close the application there's a process ( Java ) still active.

I kill it manually going to the Task Manager / Processes, making sure I am not killing the PSX one :-)

Didn't test if successive Wheramium starts leave this processes acumulating but I'll try to check it later at home.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 23 Mar 2020 12:05
Quote from: jcommwhen I close the application there's a process ( Java ) still active.

If it's "javaw.exe" it may indeed be Wheramium.

It's a bit of a user interface design issue:

As the user you have only two options to shut Wheramium down properly:

A. from the webpage by clicking the EXIT button.
This will however work only when the connection to Wheramium/PSX has been established.
(If you click the button while the webpage is not connected, you'll get a warning.)

B. from the console by typing ctrl-c
This requires that you have started Wheramium from a command line (see doc.s)

If you however (unfortunately a case more frequent than hoped for)
a. have started Wheramium by double-clicking the JAR file, and then
b. have not been able to establish a connection from the webpage to Wheramium/PSX

...then your only chance is the Task Manage or similar to kill the process, or else you will be left with a zombie Wheramium...

It's not exactly a design oversight, but I simply have no place other than the webpage (with its limited options) where to put an EXIT button. I had been thinking about a miniGUI with nothing but that button, but any GUI will increase both the complexity and the load, and it did not seem worthwhile just for a better exit solution...

Cheers,
MartinMartinMartinMartin

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: cagarini on Mon, 23 Mar 2020 12:41
@martin,

not really a problem, since that's what I always do after using Check Point VPNs...

Anyway I'll closely follow the right steps you mention, including the "Exit" and see how it goes.

Thx for the hint Martin!
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Mon, 23 Mar 2020 13:35
Quote from: Captain_Crow on Mon, 23 Mar 2020 10:51
Me again, did a flight yet and it doesn´t feel like 20 fps, no stuttering at all, smooth as ever.. strange thing..
Steff

"Feel"? You know that PSX has a frame rate indicator :-) -- So in your previous posts you were always referring to the frame rate of the Cesium map, not to the frame rate of PSX?

Did you reinstall PSX in the hope it would increase the frame rate of the Cesium map?


|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Mon, 23 Mar 2020 18:16
Dear Hardy,

sorry for the mismatch, FPS of PSX, I don´t use Wheramium anymore since I have this low FPS´s.

The Sim itself feels like always smooth, also with the indicated FPS of 20.

I did a reinstall with the version 10.1.7 from the disk and the FPS was also on 20. Something on my Win10 system has been broken I suspect. But which part? I don´t know...
On the client computer (I use two) I have 50 FPS in PSX as ever.

Best as ever
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Mon, 23 Mar 2020 18:44
Windows energy saving mode active?
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Mon, 23 Mar 2020 20:26
The usual stupid video issues when your window overlaps the task bar 1 pixel or extends beyond your physical display 1 pixel? Reduce the size so it sits comfortably within the display borders and see what happens.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Markus Vitzethum on Mon, 23 Mar 2020 21:11
Hi Martin,

Great work, what a marvelous tool!
I finally got it to work, once I realized that starting from the command line works best.

> In the meantime I have heard (offline) that running the map in a browser on an iPad also does not work.

I cannot confirm that, it seems to work fine from my iPad. Hey, it (almost) works on my watch!

Markus
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Dirk Schepmann on Mon, 23 Mar 2020 23:44
Hei Martin,

Fantastic, thank you very much for this nice tool! Worked almost out of the box, no problems to report. I'll test iPad tomorrow and let you know.

Hyvää yötä,
Dirk

PS: Whereamium is a very creative name, too. I'd have called it YASG (yet another scenery generator). :-)
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Steve Hose on Tue, 24 Mar 2020 08:13
Martin,

Another wonderful add-on - thank you so much for 'answering the call' and producing this for us.

Works just fine under Chrome for me and defintely lighter on CPU resources.

Another great reason to spend more time with PSX when Australia (eventually) goes into lockdown :-\

Hope you and everyone is staying safe in the meantime.

Best regards, Steve.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 24 Mar 2020 11:09
Ladies & Gentlemen,
(...it's 2020 and still not a single Lady, or??)

many thanks for the kind comments.

While we're at it:

A General Caveat

It's mentioned in the doc.s, but perhaps I should point it out once more:

While the Javascript in Wheramium (and Tellurium) is using the CesiumJS API, the maps / satellite images are coming from Microsoft/Bing*.
This means that you are potentially exposed to data slurping a.k.a. surveillance capitalism.
Therefore the usual caveats for that apply, proceed at your discretion.

This is a general remark; I have no knowledge of, or indication for, any data slurping to actually occur while you use Tellurium / Wheramium.
I'm just generally paranoid (which does not mean someone is not...etc), and routinely consider data harvesting in one form or another as the default behaviour of practically every website these days.

Cheers,
(((Martin)))

* I did investigate other alternatives, but they would all lead to considerable complications, such as re-writing the code from scratch...
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Tue, 24 Mar 2020 11:36
Yes, there are ladies on the forum. That's why I always write "ladies & gentlemen".
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 24 Mar 2020 13:32
Post amended.

M.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Britjet on Tue, 24 Mar 2020 15:14
Thanks very much Martin.
FYI I get things working nicely remotely an IPAS running IOS 13 and Chrome but on an IPAD with IOS 10 and Chrome I get lots of Cesium error messages. Not a problem, though ;-)
As you know I have a P3D scenery generator - but this is also extremely useful for positioning accurately at a gate pre-flight!

Peter
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Robert Staudinger on Tue, 24 Mar 2020 16:46
Hi Martin,

it works with an android-pad and Chrome also.

Cheers, Robert

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Wed, 25 Mar 2020 08:47
Miraculum: After two days of a break, FPS back on 45. no idea what happened..
Best
Steff
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Wed, 25 Mar 2020 21:18
Windows happened.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Dirk Schepmann on Fri, 27 Mar 2020 11:06
Quote from: Jeroen Hoppenbrouwers on Wed, 25 Mar 2020 21:18
Windows happened.

No, it was the MOF gremlin.

Sorry Steff, couldn't resist. :-P

Stay safe,
Dirk
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Captain_Crow on Fri, 27 Mar 2020 13:28
Passuffdu !
:-)
May be my rig isn´t strong enough to handle both, PSX and Wheramium.

Best
Steffen
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: MalcolmT on Sat, 28 Mar 2020 17:31
Hi all

For Info - works perfect for me out of the box.
My PC is i7-4770K @3.50GHz.  16.0GB Ram
I use Microsoft Edge browser, Windows 10 (64)

Thanks for the app Martin!

Malcolm
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Kabbers on Thu, 6 Aug 2020 19:57
Thanks Martin, I'm using Whereamium, it rocks, and want to thank you. I am running it well on Win10/Chrome, I tried setting the .ini variables you document to the more demanding levels and I get a very smooth scrolling map indeed with no frame problems.

I do have a little bit of trouble reading the very small lettering on the place name labels on the MAP+LABEL map option, the letters seem to flee from me and get smaller as I zoom in to try to read them, haha, so it would be ver nice if the place name letters stayed stayed bigger but - hey - it's also totally easy to hit the Disconnect button and zoom in to read the place labels that way. Thanks again Martin - marvellous addon!

Cheers and best wishes,
Kabbers
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 7 Aug 2020 18:22
Hello,

thanks for the kind words!

Quote from: Kabbersa little bit of trouble reading the very small lettering on the place name labels on the MAP+LABEL map

There are two problems with this.

The first (idiotic) one being that I myself currently cannot run Wheramium -- the web page refuses, for unknown reasons, to load an essential script...  :(  So right now I cannot try and  test.
(I suspect it has to do with newer Firefox versions.)

More importantly: The labels are part of the map "style", which means they come with the Bing maps and are not coded or styled directly by Wheramium; the program uses the maps just "as is". It may be possible to change that, but it would at the very least require messing about with the innards of the Bing maps. Perhaps doable but would require an expansion of the existing code (and might thus violate the "keep-it-simple" approach which was the basic idea).

I'd also have to see how the Wheramium-specific zoom slider interacts (or not) with the zoom mechanism built into the maps (e.g. Does the font size of the labels adapt only to the latter?); so it's not trivial.
Luckily you have pointed out yourself the work-around.   ;)
I'll try and have another look when (if) I can get Wheramium to run again even for me...

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Fri, 7 Aug 2020 21:46
You can always try stupid browser zoom, Ctrl-+.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Sat, 8 Aug 2020 03:26
Update. The issue with the turn radius has resolved itself. I'll report back if I see it again, but as of now it's gone; the PSX position and the Whereamium position are perfectly synched.

But I'm still seeing PSX frame rates in the teens.

Quote¤ When exactly does this slow-down happen?
   ¤ As soon as Wheramium is started (but before the webpage is loaded in the browser)?
   ¤ As soon as the webpage is loaded (but before it is connected to Wheramium/PSX)
   ¤ Only after the connection is made (and the map is now actually being updated constantly)?

It happens when the webpage is loaded.

After Whereamium is started but before the webpage is loaded, the PSX frame rate is 72.
As soon as the webpage is loaded, but before it is connected to Whereamium/PSX, the PSX frame rate drops to 18.
After the connection is made (and the map is being updated constantly), the PSX frame rate stays steady at 18.

My system is this:

i5-9400 @ 4.1GHz, cheap-ass Intel UHD Graphics 630

Which I understand is pretty bad for gaming, but it runs PSX at between 65 and 72 frames/second at all times.

Any thoughts?

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sat, 8 Aug 2020 10:11
Hello Will,

Quote from: WillAny thoughts?

Always, but alas! no helpful ones... :(

I am currently completely hobbled to make any progress on this: Not only does Wheramium itself no longer work for me, but I am now finding that I cannot even get Cesium to send me maps directly, quite independent from Wheramium/PSX, but using the same approach (via test scripts). The error message I see comes from very deep inside the Cesium jungle of scripts which are definitely beyond my "expertise" (rudimentary at the best of times); apparently some subsubsubscript is not correctly imported. Or something.

I can only speculate that "something" has changed either in the Cesium API/library/code, or with Firefox, or both. What makes it weird is that apparently others were/are still able to use Wheramium during the last days, and even today (I can see that from the Bing statistics about my access quota). So this seems to be something specific to my own setup.

As to the specific issue of the frame rate going down so much: As I have explained earlier, Wheramium does not talk to PSX (i.e. changing settings or variables, etc.) in any way; the Wheramium  PSX client merely reads the records issued by PSX and processes them without talking back.

So the only cause I can think of for the slow-down is a general load on the system which will of course also put the brakes on PSX. Have you had a look at the system load in general (with Process Explorer, Task Manager, or similar)?

One vague suspicion I have had for a long time is that Windows 10 "somehow does not like" Java, and/or that Java unduly overloads even a strong computer. But I have not been able to nail this down to a solid argument (e.g. it may be Eclipse, my dev environment, rather than Java itself).
Integrated graphics (as opposed to graphics cards) are also often suboptimal for simulations and games, I think; but I don't really believe that this is an explanation for the PSX frame rate going down so much. And as you report, the frame rate is in fact fine for PSX unencumbered by Wheramium...

So, investigations will have to continue, but it may well take some time to figure this one out.

C.....h.....e.....e.....r.....s,
Martin

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Sat, 8 Aug 2020 14:54
Well, I went into the task manager and with PSX but without Whereamium running, I get:

CPU: 22%
Memory: 36%
GPU: 11%

With Whereamium running, I get:

CPU: 92%
Memory: 44%
GPU: 79%, attributed to Google Chrome.

And the computer is universally slow; it's not just the PSX frame rates that are low.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Sat, 8 Aug 2020 16:11
Another update: Resizing the Whereamium browser gets the frame rates back into the 40's. I'm talking about shrinking it to about 3 inches across on my monitor. Unfortunately, this means the white triangle is no longer centered. But this is usable for getting around airports.

Thanks for all your work on this, Martin!
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Sat, 8 Aug 2020 16:26
Quote from: Will on Sat,  8 Aug 2020 14:54
GPU: 79%, attributed to Google Chrome.

That feels wrong, as if Whereamium directs Chrome to redraw most of the map many times per second.

If PSX does not move over the ground, does this CPU consumption change and drop to near-zero? If not, some mechanism that calculates position changes is broken (or does not exist at all).

How often per second does Whereamium try to update the map when PSX is in flight?


Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Sat, 8 Aug 2020 18:39
QuoteIf PSX does not move over the ground, does this CPU consumption change and drop to near-zero?

No, for me the GPU consumption is the same, regardless of the state of PSX.

PSX could be in flight, in motion on the ground, on the ground with the park brake set, or even paused, and the Google Chrome GPU consumption is still about 80%.

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sat, 8 Aug 2020 18:50
Quote from: HoppieHow often per second does Wheramium try to update the map when PSX is in flight?

It's configurable (up to a point). The INI file has two entries (POLLINTV and REQINTV) which determine how often Wheramium (as a PSX client) reads the PSX data, and how often the web page requests them from Wheramium (as a web server), resp.
See doc.s for details.

Cheers,
Martin


Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Sat, 8 Aug 2020 18:59
Quote from: martin on Sat,  8 Aug 2020 18:50
... which determine how often Wheramium (as a PSX client) reads the PSX data

Hmmm. I wonder. PSX does not "answer client requests" -- it just constantly sends data. It depends on how your program has been written, but if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what. It can, in extremis, lock PSX up as it can no longer get rid of its data and blocks on the pipe.

Now, if you always read everything but just throw it away unless your "I want new data" timeout has expired, that would be fine.

If on the other hand you stop reading for, say, 100 ms and then start reading again, you will get all data that has been piling up in those 100 ms, and you may get a large number of updates of the same variable, while you may expect just one.


Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Sat, 8 Aug 2020 22:17
As far as I recall from other forum threads, Martin uses the "read" code snippet that my public AddonExampleNetThread.java suggests:

in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
String message;
while (true) {
  if ((message = in.readLine()) != null) {
    // do something with message
  }
}

The Java function "readLine" blocks the loop as long as no data is in the pipe. So there's no overload inside the loop nor outside the loop. This works correctly in PSX and other Java add-ons. This loop must not be stopped by any other function in the add-on.

Maybe there's another while-loop around this loop when Martin's "poll" mode is active?


Cheers,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Kabbers on Sun, 9 Aug 2020 00:51
Hi Martin, just to quickly add as well, mindful of the error you mentioned you're getting, I also had an error come up today in the Browser (chrome) about Range error - with several lines of detail. A Win10 reboot did the trick though for me, which I'm sure you've tried of course, but mentioning in case this suggests Whereamium doesn't like some other addons?

I have triggered this error twice now, from setting up PSX+NavigraphCharts via a slaved xview/XP11 hidden window, and PSX main+boost server. I figured maybe a process (e.g. simlink, or xview) from that setup, even once dismantled, might still be running in the background somewhere and interfering with Whereamium in a way I didn't understand. Could there be sometimes a conflict between Whereamium and other addons was the small offering here... best, Kabbers
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 10 Aug 2020 08:40
Greetings,

[There's a reason why I have always tried to keep away from network stuff. Breaking that vow, in order to make PSX add-ons, seems now to have come back to haunt me... :o]

Quote from: Hoppie...if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what.

This idea of "clogging the pipe" I don't understand. My perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not. ("If a TCPIP packet is sent and no one receives it, is there still a packet?"). After all, I can run the PSX servers without running any client taking them, and even then no pipes or buffers will fill up and eventually choke PSX. Or?  On the other end, as Hardy says, the client will "take" data only when it feels like it, but the ones ignored in between won't accumulate anywhere. Or?

Quote from: HardyMartin uses the "read" code snippet that my public AddonExampleNetThread.java suggests
Correct, that code was lifted from there.
Here is the full run() method code, in case I have somehow ruined the example; but there are at least no surrounding loops:

public void run() {                                                             
   try {                                                                     
     socket = new Socket(hostName, portNumber);                             
     ou = new PrintWriter(socket.getOutputStream(), true);                   
     in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
   } catch (UnknownHostException e) {                                           
      [...]    );                                                             
      return;                                                                 
   } catch (IOException e) {                                                 
      [...]
      return;                                                                 
   }                                                                         
                                                                             
   try {                                                                     
      String received;                                                       
      long lastTime = 0L ; // !!                                             
      while (true) {                                                         
         received = in.readLine() ;                                           
         if (received != null) {                                             
            try {                                                             
               if (received.length()<5) continue ;                           
                                                                             
               if (System.currentTimeMillis() >= (lastTime + POLL_INTERVAL)) {
                  try {                                                       
                     recBoost = received ;                                   
                     lastTime = System.currentTimeMillis() ;                 
                  }                                                           
                  catch (NumberFormatException nfe) {                         
                     [...]                                   
                  }                                                           
               }                                                             
            } catch (StringIndexOutOfBoundsException sioobe) {               
               [...]                                     
            }                                                                 
         } // if received                                                     
      } //try                                                                 
   } catch (IOException e) {                                                 
      //                                                                     
   }                                                                         
   finalJobs();                                                               
                                                                             
} // end run() 



Moreover, I vaguely recall (needs re-verification, but at the moment I can't do that, for the reasons given above) that this CPU overload is not generated by the interaction between PSX and Wheramium anyway; I seem to remember that the load increases so much only when the webpage is connected to Wheramium, and thus the web server function of Wheramium comes into play. Or it could even be the mere Cesium stuff running in that webpage, never mind the connection to Wheramium. This, too, would need further investigation. If I can get the add-on to run for me again...

Quote from: Kabbersthis suggests Whereamium doesn't like some other addons?

I don't see how Wheramium can even be aware of any other add-ons running. The only mechanisms for that I can think of are either a general overload of the system (which will of course affect all add-ons), or perhaps a port conflict (two or more add-ons happening to try and use the same port).

In general, two aspects are bothering me:

For one, some people seem(ed) still to be happily (or at least unhappily) running Wheramium, possibly without issues. It's not clear to me if this "overload" problem affects everyone, and some are simply not disturbed by it, or if it happens only on some systems but not others.

More importantly: The precursor of Wheramium is PSX_Tellurium, which is quite a bit more complex (3D views etc.). But on my previous computer (i7-3700, 4 cores) I could run it under Windows 7 without seeing any of these CPU overload/overheat problems. These occurred only when I tried to run Tellurium on my current box (i7-8700, 6 cores, Windows 10).
(In fact, this was the original motivation to make the simpler Wheramium, see third paragraph of first post in this thread. I was hoping the simplification would alleviate the problem, which apparently it does not, alas.)

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Mon, 10 Aug 2020 09:36
QuoteMy perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not.

No, not when using TCP/IP. There are two phases:

Phase 1: The server has started listening for client connection attempts.
Phase 2: Whenever a client connects, the server starts another multitasking thread just for that new client.

The server only sends data when at least one client is connected.

The client has to read the buffer permanently because, according to the TCP "contract", every data package sent by the server must be received by the client.

I see no problem in your code snippet, but where inside that loop do you process the incoming data? If this process takes longer than a PSX time frame, e.g. longer than 14 ms (at 70 fps), the buffer will accumulate more data than your loop can read. If this problem occurs 70 times per second, the buffer may reach its limit pretty quickly.

I would run two independent loops in two separate threads. One loop reads the buffer without any delay and without any further process. The other loop may run at any frequency and copy the latest data from the buffer loop whenever it wants to, e.g. every second or every Friday.


Regards,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Mon, 10 Aug 2020 09:42
Quote from: martin on Mon, 10 Aug 2020 08:40
Quote from: Hoppie...if you stop reading the pipe then PSX will pile up a lot of data that eventually all must get processed no matter what.

This idea of "clogging the pipe" I don't understand. My perception has always been that PSX broadcasts (in the general, not the network protocol sense) the data without paying the slightest attention if someone is listening or not.


I agree with your analysis that this is most likely NOT the reason why Whereamium locks up some machines, but I can explain why it is important to think about this kind of stuff nonetheless.

Slightly simplified, there are two kinds of network links:

1. UDP - truly unreliable data packets, that are fired by the sender and may land somewhere, or not.
2. TCP - reliable byte streams, where both sides can be assured that all bytes sent, were received, in the same order.

The price to pay for the reliability of TCP is performance. Reliability requires a lot of back and forth handshaking and this leads to much more network traffic (overhead) than UDP. If raw performance over the wild internet is important, such as for streaming audio and video, while it is possible to bridge occasional gaps in the stream, UDP is preferred. The same holds for severely underpowered equipment.

However when power is not a problem and the line is by itself reliable, such as in Ethernet linking home computers, TCP will work brilliantly and makes life simpler.

PSX uses only TCP for these reasons.

Now, if PSX would use UDP, your reasoning that a sent packet that was never received would not hurt, would be true. PSX would launch packets all the time and if nobody wants to read them, the packets expire when they reach the end of the network. Like sound waves.

But TCP is reliable. PSX (the operating system on which it runs, actually) is not going to rest until it gets confirmation that the bytes it has sent, have been correctly received. TCP is connection oriented. You open a pipe and from then on, either end of the pipe can rely on it working completely, or not at all (broken pipe). The operating system has buffers to absorb small network irregularities, but  these buffers are not infinite.

So if your client opens a pipe and PSX starts pressurizing the water hose, your client is required to read all bytes that PSX pumps into the hose. Else, eventually, PSX won't be able to pump more bytes and the operating system will block PSX to avoid losing bytes. It is fine if your client reads the bytes and then promptly throws them away. This is how you treat PSX data streams: you read it all, and then ignore what you don't need.

If you run PSX connections over the wild internet, this is occasionally an issue. If the long line snaps, or is stepped upon for a moment, the PSX server may encounter full buffers and literally stop for a while. This problem can be solved by inserting one of the PSX Routers into the stream between the server and the wild internet. The Router will absorb the blockage and keep the server pumping freely.

If somebody really wanted, (s)he could write a PSX Router that connects to PSX over TCP and to another router over the wild internet via UDP. This would allow two PSX instances to sync up when able, and run independently for a while when needed.

Hence ... if you write a TCP socket client, you must assure that you read whatever bytes appear often enough, to avoid the far end buffer running full. Typically this is done by setting your socket as non-blocking, and implementing some kind of interrupt-driven handler that wakes up as soon as there is something to read. Since PSX uses linefeed separated streams, it is totally okay to have your client accumulate one line of bytes before it interrupts your program. This makes for a one-line buffer, which is never going to block the sender as TCP buffers are in the order of dozens of KiB on most systems.

What typically also works, but is not recommended, is to have your client periodically check whether there is something to read. This blocking mode operation works if you poll often enough, but causes a lot of useless looping around if there is no traffic, and causes stop and go processing if there is traffic.


Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 10 Aug 2020 13:53
Very good clarifications, thanks!

But (apart from the Wheramium issue; this is now mere curiosity) they don't quite cover (or at least not explicitly) the case where there is no client.
What does the server then do?
My idea (probably wrong, as I now realise) has always been that it is emitting data anyway. In the light of your explanations it is more probably so that if there is no client, there is no connection, and the server serves nothing. Correct?

[EDIT] Actually I should have known that (RTFM), it's in the Java tutorials (https://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html) (I just haven't paid enough attention to the server side. And of course the  moment you "look", you are a client and the server starts serving, so you'll never catch it waiting...  ;D):

Quote from: Oracle...the ServerSocket object is successfully created and the server continues to the next step — accepting a connection from a client [...]:
   clientSocket = serverSocket.accept();
The accept method waits until a client starts up and requests a connection on the host and port of this server. [my bold]

Cheers,
MMMM.... <---->   
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Mon, 10 Aug 2020 15:09
Martin, did you read my reply #76? :-)


|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 10 Aug 2020 19:43

Quote from: HardyMartin, did you read my reply #76? :-)

Sorry, I had missed that*  :(

Quote from: Hardywhere inside that loop do you process the incoming data?

The PSX data record (line) is not really processed at all; it is forwarded "as is" to the web page (Wheramium now acting as web server), and then parsed there, with Javascript.
But the timing for polling PSX is still in that Java-side loop indeed, and perhaps that should be rectified according to what you suggest.
With Hoppie's and your help I understand now the potential "constipation" problem; and I can see why e.g. "buffer full" might become an issue. But could this also lead to the CPU "overload"?
(Even if it's not quite real overload; perhaps it's just that I am not used to such high loads and temperatures.)

Thanks to all for the comments. The next episode will address  Kabbers's original problem!  :D

Cheers,
Martin


* Too many things going on at once (I don't like, and am no good at, multitasking...). I had tried to run the old Tellurium so as to get a baseline on things, but that threw now even weirder errors never seen before...
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Mon, 10 Aug 2020 20:02
I think it's interesting that my CPU and GPU get overloaded when I put the Whereamium URL in the browser, but before Whereamium starts drawing the map. This is when the overload starts:

Quote¤ As soon as the webpage is loaded (but before it is connected to Wheramium/PSX)

Maybe it falls into some loop that's unrelated to actually fetching data from Cesium?

Also, are we thinking that this happens to everyone, but only those of us with low-powered systems can actually see it?

Martin, I think this is probably what led to your overheat situation. The percentage load numbers aren't static, they bounce around, and so there are times my CPU goes to 100% and stays there a while before falling back to 90% or so.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 10 Aug 2020 20:04
..and back to the original question about the font size of the map labels. I have now been able to get Wheramium working again for me, too, and have had a look.

As I suspected, this is a Bing Map thing. But what I see (in Firefox) is a bit different from what Kabbers describes:

If I zoom out (using the slider)  further and further, the font initially becomes smaller indeed.
But at some point it does a little jump and becomes bigger again. If zooming out is continued, the font shrinks again, then does another jump and grows again.  Sometimes even some of the labels are "still" small, while others are "already" bigger again.
So for me at least it never becomes really tiny and thus illegible.

See this picture  and note the name "Lisse" and also the respective zoom factor displayed above the slider (smaller = more zoomed-out). These screenshots are all at the same scale, only the map changed.
(http://www.saunalahti.fi/erdel/psxwher/LabelFont_s.jpg) (http://www.saunalahti.fi/erdel/psxwher/LabelFont.jpg)
(Click on the picture for full-sized version.)

Two conclusions:

There is not much I can do about this (unless I would attempt deep surgery on Bing maps, but I am not sure if that is even possible to that degree).

But what at least I see does not actually need any change.
(Unless it is a browser issue, and Chrome behaves differently from Firefox, in which case I can do even less about it...  :D)

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 10 Aug 2020 20:13
Quote from: Willmy CPU and GPU get overloaded when I put the Whereamium URL in the browser, but before Whereamium starts drawing the map.

Thanks for the comments, Will. There is definitely something not right (and never was), and now that I can run Wheramium again (sort of), I'll try to have another look. The difficulty is that this requires juggling Java, Javascript, HTML, TCPIP, Bing maps, and especially the rather vast Cesium cosmos, where of course the last two components, being located on the Internet,  can change any time...

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Mon, 10 Aug 2020 22:14
I would suggest to equip the very first piece of code that catches PSX data with a simple filter, to weed out all the masses of data you are sure you do not need. And only pass what you do need to JavaScript.

JavaScript running in a browser is lots of things, but not a speed monster for data crunching. I am not surprised that you can heat up your CPU by processing a full PSX data feed in a web browser while attempting to also process Bing maps.

If you program a master switch into your PSX data catcher that allows it to either pass filtered data on to the browser, or simply throw all incoming data away, you have a nice test facility to see where the heat comes from.


Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Tue, 11 Aug 2020 01:23
Quote from: martin on Mon, 10 Aug 2020 19:43
The PSX data record (line) is not really processed at all; it is forwarded "as is" to the web page ...

It shouldn't be forwarded. There may be a long process in that external web page code. That external process happens within your primary loop thread if your forward command sits within that loop.

The only process within your primary loop should be a string copy from the readLine function. You don't even need a text filter because the boost network sends just one variable anyway (no Q vars like in the main network).

There should be a secondary loop thread. This may run at any frequency you like, e.g. 30 Hz. Inside this secondary loop you copy* the latest received string from the primary loop. Also, inside this secondary loop, you forward that copied string to the external web page. If that web page takes a long time to process the data, it doesn't matter; the next cycle of that secondary loop will just start a bit later -- it won't affect the timing of your primary loop because you now have two independent threads (primary and secondary).

* using a thread safe method


Cheers,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 11 Aug 2020 07:35
Thanks to both of you, all good advice!

Quote from: Hoppieequip the very first piece of code that catches PSX data with a simple filter

A filter is not really needed, I think: what comes from the PSX Boost server is just one string anyway. Which is later (currently in Javascript) simply split into pieces, and the coordinates are then picked out.
But that operation should perhaps not happen on the web page / Javascript side indeed, I had already had my suspicions in that direction. The difficulty is that it's not immediately clear if the Javascript-side load comes from my code (which I can change) or from the Cesium stuff. But I'll do more tests to figure that out.

Quote from: HardyIt shouldn't be forwarded.
"Forwarded" was an unfortunate term perhaps. What happens is really just that the string coming from PSX is copied to a variable (recBoost), and that is then sent to the web page where Javascript splits it up and processes the coordinates.
But I'll also follow up your tip about a secondary loop (as soon as I get my head around "thread safe". I know what it means but knowing what it means and actually applying are two different things. At heart I am still a procedural monothread guy with some inkling of object orientation from the happy Algol68/SIMULA days...  :D).

Cheers,
Martin "The Threadunsafe" E.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Tue, 11 Aug 2020 08:01
Quote from: martin on Tue, 11 Aug 2020 07:35
... and that is then sent to the web page ...

Hehe :-) We're moving the meaning of a word further but the actual problem remains the same. Not "processed" but "forwarded"; not "forwarded" but "sent" ... :-)

Where in the loop does your "send process" start? Is it just this?

recBoost = received;

Is there another thread outside your primary thread that does something like this?

finalCopy = recBoost.toString();


By the way, if you code this recBoost = received; then you just copy the string address but not the content of the string. To copy the content, you need to use the .toString() function or something similar.

"Thread safe" means this: While thread A is reading string X, thread B cannot overwrite string X. Only one thread can read or write string X at a time. Otherwise, if thread B were changing the string content from "hoppie" to "martin" while thread A is reading the string, thread A may get a random result like "marpie", for example.


Cheers,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 11 Aug 2020 11:20
Thanks!

Quote from: HardyHehe :-)
Semantics are always fun (as well as an excellent Excuse of Last Resort)! :-)

Quote from: Hardyyou just copy the string address but not the content of the string
readLine() delivers type String, and both received and recBoost are of type String, too*, and I still have to convert?
OK, they may all be swapping the address and not the string literal, but does this make a difference here? What later arrives in Javascript (see below) is still the correct literal, not an address.
       * the difference being that received is local and recBoost is protected, thus accessible by other classes.

What happens is this:
The recBoost variable can be accessed by the Wheramium web server class, and as soon as the latter GETs a request from the web page, it serves this string (after prefixing it with a HTTP header).
The real issue at the background of all this is that I need communication between Java (the PSX client part of Wheramium) and Javascript (web page and scripts), hence the built-in web server; but all that is very unfamiliar territory to me.
That's also the reason why I send the whole PSX "record" to the web page "as is" and do the parsing into coordinates there, in Javascript. As Hoppie says, probably a bad idea with regard to performance, but if I do the parsing on the Java side already, I'd then have to send several pieces of data to Javascript, probably each via its own GET request and HTTP server reply (at least that is the only way I could think of).

But we digress... The non-Update to follow will explain how I got rudely returned back to real problems...

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 11 Aug 2020 11:28
(Non-)UPDATE

While exploring new ways to mess with the Wheramium code, I have now been hit, again, by a computer crash, as was frequently the case in March already (but never since, after I stopped working on this project!).

In "end-user mode", running just PSX + Wheramium (from JAR file) + web page, all is well, and even the CPU temperature remains within reasonable boundaries (for now -- this may however have to do with the choice of PSX situ to test with, or with the zoom level applied, etc.)

But in "developer mode", which means running PSX + Eclipse* + Wheramium from within Eclipse + web page, all still goes well for a while, but then, after a seemingly random interval of a few to many minutes, the crash hits (not just BSOD or CTD, but machine shutting down, and requiring Power button for restart.)
     * Eclipse being the Java IDE and itself a Java application

So, the same thing as with the earlier Wheramium work.

I am sharing all this only by way of a warning to everyone concerned with Wheramium and potential updates:
Do not cease respiration!
(Don't hold your breath...)

I'll keep trying for a while longer, but it's possible I have to give up; I can currently not afford to embark (again) on a meta-project to identify (let alone fix) whatever may cause these crashes. Nor do I wish to "experience" another 24 crashes or so (http://aerowinx.com/board/index.php?topic=5697.msg61813#msg61813) over the next four weeks...

So don't be surprised if/when further updates are not forthcoming.
Sorry!

Cheers,
Martin "The previous system shutdown was unexpected." E.
(the only "error message" the Win10 Event Log is offering to help with crash diagnosis...)
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Tue, 11 Aug 2020 12:42
Quote from: martin on Tue, 11 Aug 2020 11:20
OK, they may all be swapping the address and not the string literal, but does this make a difference here?

I wouldn't rely on that either; it doesn't look thread safe to me. I'm not sure if the address change runs so fast that  the address data can never be garbled at the receiver's side. When it runs for, say, two hours at 70 fps, the address will change half a million times. There's a real chance that you get garbled address bytes, I think.


Best wishes,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Thu, 13 Aug 2020 11:57
Greetings!

Following the discussion above, and crashes notwithstanding, I have managed to produce a Wheramium "version 02" which may or (more probably) may not make a difference. See the first post (http://aerowinx.com/board/index.php?topic=5697.msg61813#msg61813) in this thread.

I am not at all sure that this really improves the performance, but did find that I can run Wheramium with REQINTV=50 (= 20 Hz; noticeably smoother than the value of 100 I used previously), with CPU load and temperature staying within reasonable limits. The question is however if this is really due to the changes made, or just plain good luck e.g. with the selection of the situ for the (one!) test I did ("Basic 020 - Descending to 10000 ft").
So you'll have to try it yourself and form your own opinion. :-)

The plan is that no further development or updates will be inflicted on Wheramium (the crashing thing is just too inconvenient).
But if you run into any serious new problems, let me know anyway, and we'll see what can be done.

Have fun!

Cheers,
Martin "Hertzliche Grüße" E.
Wheramist (ret.)
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Thu, 13 Aug 2020 14:03
Thanks for your efforts, Martin. I'll give it a try tonight and report back.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: vnangli on Thu, 13 Aug 2020 16:28
Just checked "Where am I umm"...Works perfectly...Thank you.

I am glad I spent the time this morning to explore this addon..

Thank you again

Just editing my previous comment. The .ini file was having 10749 as the port and the Preference in my PSX instructor shows 10747, but the html page was capturing the position well...Am I missing anything here??

Now can I use my iPad safari page to use "whereamium" ??
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Thu, 13 Aug 2020 17:57
Main server: 10747
Boost server: 10749

Whereamium uses the boost server.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: vnangli on Thu, 13 Aug 2020 17:59
Quote from: Hardy Heinlin on Thu, 13 Aug 2020 17:57

Whereamium uses the boost server.

Got it...Thanks
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Will on Fri, 14 Aug 2020 02:07
Hi martin, thanks for this update! I see an improvement.

Before Whereamium:

CPU: 22%
Memory: 36%
GPU: 11%

With Whereamium v.1 running, I get:

CPU: 92%
Memory: 44%
GPU: 79%, attributed to Google Chrome.

With Whereamium v.2 running, I get:

CPU: 59%
Memory: 39%
GPU: 78%, attributed to Google Chrome.

As you can see, GPU is about the same, but CPU is significantly lower. This translates into frame rates on PSX of about 42, which is acceptable for taxying around the airport.

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 14 Aug 2020 08:16
Quote from: vnangliNow can I use my iPad safari page to use "whereamium" ??
It "should" work as long as the Safari browser can access the Wheramium URL / web page and Bing (for the maps), i.e. no firewall etc. in the way. That web page includes a lot of Javascript, though, partly my scripts, and much more from Cesium. It still "should" work, but as we know, Apple is often a law unto itself, so they may have different ideas.
In any case, it's worth a try.

Good Luck!
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 14 Aug 2020 08:24
Quote from: WillI see an improvement.
Good news, thanks for the feedback, Will.

Quote from: WillGPU is about the same
Probably to be expected as that will be the rendering of the maps (Bing via Cesium), which has of course not changed at all in v.02. [emphasis added]

Quote from: Willframe rates on PSX of about 42, which is acceptable for taxying around the airport. (emphasis added)
As we know, 42 is the answer all right, but that statement can only come from someone who has not received his flightsim education starting with SubLogic FS1 ...  ;D

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: vnangli on Fri, 14 Aug 2020 15:40
Quote from: martin on Fri, 14 Aug 2020 08:16

In any case, it's worth a try.

Good Luck!
Martin

I can be your "TEST PILOT"  :D.

I used the URL "http://localhost:10314/PSX_Wheramium.html". And in the place of "localhost" in the URL I instead used my IP address of the machine running the PSX. Worked like a magic on my iPad. And I used SAFARI

BTW, I also have a Google Chrome browser on my iPad. It works seamlessly there as well....

Martin, this is very exciting...Thank you
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 14 Aug 2020 19:06
Excellent!
Thanks for testing and reporting!

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: David Palmer on Tue, 25 Aug 2020 07:29
Hi Martin,

Could this CPU and heating issue just be a consequence of using 'Cesium'?

I remember using an app on my last Android cell phone that used Cesium and the phone generated a ton of heat and the battery took a big hit after only a few minutes of app usage.

Regards,
David
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 25 Aug 2020 19:14
Hello David,

it's quite possible, Cesium is a bit of a monster (to this dragon non-slayer at least). But when Google let the Google Earth browser plug-in die, Cesium was the "nearest" (free) alternative I could find. By now, anything else (if it exists) would certainly require a re-write from scratch, and that seems too high a price (esp. as we have full-fledged scenery generators like X-Plane and FSX as alternatives).

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Mon, 28 Sep 2020 17:28
Hi,

i didn't re-read everything but, Martin, do you know what this is:

(http://www.hoppie.nl/forum/var/2020-09-28_16.26.29_AA_WH_error_msg.jpg)

Thanks,
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 28 Sep 2020 19:31
Hello Avi,

this is what I always fear most: an error deep within the Cesium code, and probably not reproducible (if it were a "reliable" bug, it would occur several times every second or so...)

The only related thing I can see in the Wheramium code is that "tick" function (last line in the error message), a sort of timer which calls the next animation frame for the Cesium map. But it's impossible to say why in this specific case it runs into an error of this kind. (I have never seen it myself in all the development and testing work with Cesium.)

How often does this happen? Is it a singular glitch or a regular occurrence?
If you get that error a lot, I would have to make and send you a special version which puts out some more info about the variables at that point, which may or may not help diagnosing the issue. 

And which Java version are you running? This tick() function uses the Date functions built into Java, but I can't imagine that has changed drastically between versions. (And again: if that were the reason, the error would happen many times per second.)

That's all I can currently think of, unfortunately...

Cheers,
Martin

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Mon, 28 Sep 2020 21:42
Hi,

The good news is that it works now but here is the full story.

First of all, in too many cases after I load the http://localhost... into Chrome it takes long time until Chrome reads the file (it can take good several minutes in the worst case), in other cases it is faster (all pre-conditions are met of course).

I did a flight yesterday and it was ok (except it kills PSX frame rate but this is a known thing) all the way until I parked and then few seconds latter it crashed and I got this error message.

Today it happened to me (both problems) anytime I tried to start it and at the end I gave up.
At some point I wish I had restarted my computer but it was too late at the time.
I did restart it now and checked it again and it works so I don't know what is going on.

Let wait and see

Cheers,

P.S. Just for the record I use Java 8 update 251 and run PSX_WH v02.

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 29 Sep 2020 12:01
Hello Avi,

Quote from: Avi...after I load the http://localhost... into Chrome it takes long time until Chrome reads the file
The Wheramium HTML page itself is of course on the local machine (and very simple), so that should load almost at once. The problem is probably fetching the map, which comes from the Cesium servers, so it's more of an Internet connection issue (I think).

Quote from: Aviit kills PSX frame rate but this is a known thing
But the Wheramium PSX client only reads the data sent out by the Boost server; that should not slow down the frame rate? Of course, an indirect effect is possible: fetching the animated Cesium map in the web browser can put quite some load on the computer (if it runs on the same machine as PSX).

Quote from: AviToday it happened to me (both problems) anytime I tried to start it
Now that is very strange, but I have no idea what the reason could be; I have so far never seen (or heard of) anything like this. And apparently it does not even hit you all the time...

Quote from: AviLet wait and see
Good idea! :D
Perhaps I should update my Java (I'm on 8, but an older version) and see, just in case, if I can then replicate the problem. It's if course also always possible that something has changed on the Cesium side; but if that is the reason, we should be hearing complaints from other Wheramium users, too, I suppose.

Cheers,
Martin


Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Tue, 29 Sep 2020 14:33
Quote from: martin on Tue, 29 Sep 2020 12:01
Quote from: Avi...after I load the http://localhost... into Chrome it takes long time until Chrome reads the file
The Wheramium HTML page itself is of course on the local machine (and very simple), so that should load almost at once. The problem is probably fetching the map, which comes from the Cesium servers, so it's more of an Internet connection issue (I think).

Maybe. I had Internet problems in the past few days.


Quote
Quote from: Aviit kills PSX frame rate but this is a known thing
But the Wheramium PSX client only reads the data sent out by the Boost server; that should not slow down the frame rate? Of course, an indirect effect is possible: fetching the animated Cesium map in the web browser can put quite some load on the computer (if it runs on the same machine as PSX).

I do run everythings on one machine.

Cheers,
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Jeroen Hoppenbrouwers on Tue, 29 Sep 2020 22:50
Quote from: martin on Tue, 29 Sep 2020 12:01
But the Wheramium PSX client only reads the data sent out by the Boost server; that should not slow down the frame rate?

It can. If it connects to PSX and reads a bit and then stops reading, it may cause PSX to temporarily halt because it cannot get rid of its data. There are buffers in the PSX transmitter but it remains TCP, there are only so many packets that it will buffer up before Whereamium needs to fetch and ack the first of the queue. Depending on how PSX has been written, such a blocked pipe may or may not affect the tight inner loops.

TCP can only be used if pipes do not block on the reading end (for more than a millisecond). UDP, a different kind of beast, would potentially be more appropriate for a sensitive realtime data stream like that of the Boost Server. Missing a boost packet here or there is not so important, as the receiving simulator can merely skip them and sync up when ready again. This trick saves the day for pretty much all streaming services out there.

However the basic problem isn't the sender, but the receiver, so there is something that locks it up. Possibly you can add a gimmick that senses that "something else" is stopping your receiver and then temporarily unblock the pipe and throw away data until it can be used again? Or implement a separate thread that only receives and fills a buffer, with an overwrite function that throws away data older than a second?

All low-level sorcery that you likely wanted to avoid, I know. The blessings of network programming.


Hoppie
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Thu, 1 Oct 2020 09:14
Quote from: HoppieIt can. If it connects to PSX and reads a bit and then stops reading, it may cause PSX to temporarily halt because it cannot get rid of its data.

Yes, some time ago we have discussed the issue, and I learnt that communication pipes can indeed be clogged up.
The practical result was Wheramium "version 02" (announcement here, documentation here),  now reading the PSX data as fast as it can, without pausing for any artificial "poll interval" (all of which may or may not be sufficient).

But could a pile-up in the comm.s pipe increase the load on the whole application to the point that even the frame rate suffers visibly?

Quote from: HoppieAll low-level sorcery that you likely wanted to avoid, I know.

I am still hoping I can: What's happening now is simply that the data are read and put into a variable "as is" (i.e. the whole string) and then read again and put into the variable and read... No brakes on that loop. End of story on the Java side/PSX client.

The Javascript side (web page) then fetches the value of that variable from the Java side/web server, and parses/processes it at its leisure, but the Java side/PSX client does not take any notice of that and is not affected by how fast or slow this happens.

Cheers,
Martin

PS (or possibly XP):
Quote from: HoppieUDP, a different kind of beast, would potentially be more appropriate for a sensitive realtime data stream like that of the Boost Server.
Fun fact: X-Plane 11 does use UDP to broadcast its data.

Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Thu, 1 Oct 2020 09:56
Background info: PSX runs five independent looped threads; each at a different frequency: 0.3 Hz, 1 Hz, 5 Hz, 20 Hz, and the highspeed loop which is limited at 74 Hz.

The frame rate indicator in PSX refers to the highspeed loop. The highspeed loop executes aerodynamics, autopilots, graphics, and the booster output. So, yes, a clogged booster output buffer can slow down the highspeed loop.

When PSX copies data to the output buffer 74 times per second, PSX doesn't start 74 new threads per second. Instead, the data from the simulation is directly written to the output buffer. PSX will close the output when a network error is detected. But a clogged buffer is not considered an error. So it just waits until the buffer is free again.


Cheers,

|-|ardy


I guess the Wheramium code should run a secondary, independent, looped thread that contains its own variables which it copies to Cesium (the copy is performed via TCP/IP probably, so the copy-confirm process may be paused sometimes). The primary loop reads data from PSX and copies its values to the variables of the secondary loop thread. When the secondary thread slows down (due to delayed Cesium confirmations) it won't affect the primary thread; the secondary thread will just miss some data updates.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Thu, 1 Oct 2020 17:17
Separation of threads was the other innovation in "version 02".
("2. Copying the PSX data over from the PSX client part to the web server part of Wheramium is now thread-safe (I hope).").
The communication to Cesium happens only on the Javascript side.

I just did a (rough and amateurish) test to time the speed at which Wheramium now reads the PSX data lines, and on  my box (i7-8700, 3.2GHz, 16GB RAM) the frequency is 73.8 lines per second which I think means practically as fast as they are sent from PSX,  with no risk of backlog or pile-up.

But I am still not seeing the Cesium problem reported by Avi, so no progress there.

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Avi on Thu, 1 Oct 2020 17:35
If a reboot solve it, maybe it was somthing on my side.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Fri, 2 Oct 2020 00:49
Quote from: martin on Thu,  1 Oct 2020 17:17
The communication to Cesium happens only on the Javascript side.

Does the Javascript code include a TCP/IP data transfer to Cesium?


Cheers,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 2 Oct 2020 08:39
Quote from: HardyDoes the Javascript code include a TCP/IP data transfer to Cesium?
Wheramium "just" uses Javascript functions from the Cesium library, but I don't know what protocol these then use behind the scenes.
I just had a look-around at doc.s, API, blogs, and so on, but nothing found so far, or they are not telling; it's all about the higher levels, i.e. Javascript and other web technologies.

However, it's Open Source, so I can and will dig around in the source code (or alternatively try and intercept the network traffic), but that will take more time. I'll update this post if I find anything relevant.

UPDATE: Now I've had a quick look at the main Cesium Javascript file (the ancient version I am using has only 156,600 lines) in the hope of finding some low-level communication stuff. No such luck, but what I saw looks as if HTTP requests are being used. Which naturally then begs the question what the HTTP protocol uses as the underlying layer.
To which the Hive Mind (a.k.a. Wikipedia) says: "Transmission Control Protocol (TCP) is commonly used. However, HTTP can be adapted to use unreliable protocols such as the User Datagram Protocol (UDP)."

Cheers,
Martin "Never look under the hood" E.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Hardy Heinlin on Fri, 2 Oct 2020 10:46
Quote from: martin on Thu,  1 Oct 2020 17:17
... the speed at which Wheramium now reads the PSX data lines, and on  my box (i7-8700, 3.2GHz, 16GB RAM) the frequency is 73.8 lines per second ...

That's actually a fine result; your primary loop thread seems to be unblocked now. Just to be sure it's not coincidence: Do you get 48 Hz when you set the PSX limit to 48? (Instructor > Preferences > Basics.)


Cheers,

|-|ardy
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Fri, 2 Oct 2020 18:41
Quote from: HardyJust to be sure it's not coincidence: Do you get 48 Hz when you set the PSX limit to 48?

Ahhh, always some subversive questions/suggestions...
(It is bad practice to try and improve or extend results which already fit perfectly.) ;D
But luckily, here it turns out indeed that the read frequency perfectly fits the settings in PSX for the boost record generation frequency.
Here is the full science:
   
For each "Frame rate limit" setting in PSX, 1,000 (A) and 10,000 (B) data reads, resp., were timed.
(For the "73" setting, also 50,000 reads (C).)
The A and B (and C) results are mostly identical to the first decimal, but did differ in the second and third, not shown here.  ;) ).


Results:

  FPS            reads/sec   
setting        A       B    C
  73         73.8    73.8  73.8 
60/2        30.2    30.3   --
48/2        24.4    24.4   --
60/3        20.1    20.2   --
48/3        16.3    16.3   --


Cheers,
Martin "ReadSpeeder" E.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Josip Gracin on Sun, 5 Dec 2021 09:40
Hi Martin,

I'm having some issues with setting host IP and port. The values I set in .ini file seem to be ignored and the app always tries to connect to localhost:10749. (I determined this by inspecting the network traffic.)

I couldn't find the source code for Whereamium so I suppose it's not published. Have you considered publishing it? I'm a Java developer myself and I'd be happy to contribute (or at least try).

Thanks.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Sun, 5 Dec 2021 17:22
Hello Josip,
Quote from: JosipHave you considered publishing [the source code]

Not really -- it is too much of an embarrassing mess intricately structured for that...  :-\

Besides, the problem you describe is a new one (i.e. I never heard about an issue like this before), so I have a hunch this is a network and setup question rather than an issue with the source code; I suggest that we pursue this line first. If need be, we can of course still dive into the source (about which I have forgotten all by now, so some archaeology will be required  ;D )

For starters, some additional information would help:

¤ As localhost apparently is not correct for you, you are probably trying to run things on more than one computer, but what exactly is the setup?

¤ Have you (just for a test) tried to run everything on the same machine with the default PSX ports, so that localhost:10749 "should" work?

¤ Moreover, are the ports in the *.ini file in agreement with what is set up in the PSX  Preferences/Network page?

¤ Is it possible that Wheramium is reading a wrong *.ini file from somewhere else (which still has the default entries instead of yours)?

(Sorry if these are very obvious questions, but experience (not least with myself...) advises that they still have to be asked.)

In any case, I'll dig out the source and have a look if/how non-localhost adresses are properly treated.

In the meantime, if anyone else is running PSX / Wheramium on more than one box, don't hesitate to let us know if/how it works for you.  ;)

Cheers,
Martin




Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Josip Gracin on Mon, 6 Dec 2021 16:59
Hey Martin,

Thanks for the response! I'll check everything you mentioned once again.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Mon, 6 Dec 2021 17:30
Hello Josip,

In the meantime, I did my homework and had a look at the code again. I found some possible issue, but it is complicated and needs further investigation, which will take time. I tried an experimental "fix", but so far have only managed to break the application completely...  >:(
(And in any case, if that is really a problem, it's strange that no one has discovered it long ago.)

However: Perhaps there is a work-around:
Can you not simply run the Wheramium application on the same computer as PSX, so that localhost:10749 will work?

The feature of running it on another computer than PSX is really just a left-over from the ancestors of Wheramium (PSX_Earth and PSX_Tellurium) which still had a GUI, and that was of course not always convenient on the same computer as PSX.

But Wheramium is "invisible" (no separate GUI window), so it does not disturb the PSX window in any way.

And it should then still be possible to run the web browser (with the map, and with what is now the Wheramium GUI) on another computer, if the URL in the browser just points to the PSX machine, i.e.
  h ttp://123.456.78.90:10314/PSX_Wheramium.html instead of h ttp://localhost:10314/PSX_Wheramium.html

Hope this helps, as they say.

Cheers,
Martin
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Tue, 7 Dec 2021 14:52
Hello again!

As it turns out, the IP address and port entries from the PSX_Wheramium.ini file were read all right, but were then ignored when making the connection to the computer with PSX... D'oh, as the ancient Greek poet Homer said.

The issue has now been fixed (or so I hope) in version 02.1 available here (http://www.saunalahti.fi/erdel/psxwher/PSX_Wheramium_v02_1.zip).
Only the JAR file needs to be replaced.

There are no other changes -- users who run PSX_Wheramium on the same computer as PSX anyway do thus not need this update at all.

Good Luck!

Cheers,
Martin "LocalHost" E.
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: Josip Gracin on Thu, 9 Dec 2021 17:13
Hi Martin, thanks!

In the meantime, I implemented a simple app that connects to the PSX main server and draws the airplane's position and heading on OpenStreetMap. It's here in Github: https://github.com/jgracin/psxtaxi (https://github.com/jgracin/psxtaxi)
Title: Re: NEW: PSX_Wheramium, a moving map
Post by: martin on Thu, 9 Dec 2021 20:18
Hello Josip,

Thanks! Very nice application, and easy on the resources.

Cheers,
Martin