Announcement

Collapse
No announcement yet.

DUMP1090 on Windows: no map display in browser

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DUMP1090 on Windows: no map display in browser

    Hello all, and merry Xmas.

    I tried to visualize the planes spotted by my station using the web interface of DUMP1090 (Malcolm Robb's version). Unfortunately I don't succeed.
    As I understand this should actually be simple:
    1) running "dump1090.exe --interactive --net" in a DOS box (works perfectly )
    2) start browser and choose URL http://localhost:8080 (problem: no map and no clocks are displayed)
    Config: Notebook, Windows Vista, Dongle RTL2832U directly connected to notebook, internet is online, firewall deactivated (to ensure the firewall does not cause the problem)
    Using DUMP1090-package: https://github.com/MalcolmRobb/dump1...10.3010.14.zip
    Here a screenshot of my problem:
    ScrShot.gif

    Your help would be very much appreciated - thank you, -Wolli-
    Last edited by Wolli; 2014-12-26, 15:50.

  • #2
    firstly have you installed the drivers for the dongle? These arent the ones that came with the dongle.

    http://www.flightradar24.com/dvbt-stick The fr24 guide to the tv sticks it uses rtl1090 but describes the driver installation process.

    secondly what's the exact output from dump1090 do you see data on screen? when you start it and also a screen shot of what ever isn't right would help.

    I have just quickly tried on a windows machine haven't ever done it in windows before and i get a blank map is this what you are seeing?

    i Think it may be permissions thing that dump1090 isn't able to see the internet to get the map data.



    Failing that if dump1090 is working use adsbscope and start dump1090 with the --net-beast and set adsbscope to connect to port 30005 on local host and it will work.
    Last edited by SpaxmoidJAm; 2014-12-27, 10:13.
    T-EGLF8

    Comment


    • #3
      @SpaxmoidJAm: Thank you for your reply.

      Originally posted by SpaxmoidJAm View Post
      firstly have you installed the drivers for the dongle? ...
      Zadig, yes sure. No problem, dongle is running perfectly and dump1090 produces plane data output, as I wrote in my 1st posting.

      Originally posted by SpaxmoidJAm View Post
      secondly what's the exact output from dump1090 do you see data on screen? when you start it and also a screen shot of what ever isn't right would help.
      Please see the screenshot in my 1st posting. A momentum output of dump1090 can be seen in the black window in the screenshot's left lower corner (black part, DOS box). Some planes are displayed, as you can see there. The screenshot's white-colored part is the browser window with URL "http://localhost:8080": No map, no clocks, just a little bit "fixed" text in the upper right corner. And this is the problem.

      Originally posted by SpaxmoidJAm View Post
      Failing that if dump1090 is working use adsbscope and start dump1090 with the --net-beast and set adsbscope to connect to port 30005 on local host and it will work.
      I will try using "adsbscope" (which I still don't know as a newbee), although my feeling is, that the browser output should/could actually work also without "adsbscope". However: thank you again. -Wolli-
      Last edited by Wolli; 2014-12-27, 18:12.

      Comment


      • #4
        i was still a little blurry eyed when i started that post and didn't spot the screen shot.

        You are correct the map output should work, i too when i tried in windows had the same problem, no map (haven't resolved it yet).

        Another good program to try is Virtual radar server it does what your looking for and more.
        T-EGLF8

        Comment


        • #5
          or you could just install VirtualBox and install a linux OS on it? I've never used the Windows version of Dump1090, only the Linux (which worked well) version. Virtual Radar Server is good but of late, it has ceased logging aircraft into the reports (requiring a reboot of the program, so something to watch for).
          F-YSWG1 and T-YSWG2

          Comment


          • #6
            I have the same problem with win7, it used to work, but following the last update I no longer get the map,
            Ben.
            Nb VRS server will take the feed from dump1090 and map it fine.
            Last edited by F-EGLF1; 2014-12-28, 12:06.
            FR24 F-EGLF1, Blitzortung station 878, OGN Aldersht2, PilotAware PWAldersht, PlanePlotter M7.

            Comment


            • #7
              Thank you all for your replies.

              I think at first I will give VRS a try. As a newbee in spotting I'm still discovering the available tools, suitable antenna and it's position, and and and... Quite exciting this all.

              Thank you again and good luck, -Wolli-

              Comment


              • #8
                Originally posted by Wolli View Post
                1) running "dump1090.exe --interactive --net" in a DOS box (works perfectly )
                2) start browser and choose URL http://localhost:8080 (problem: no map and no clocks are displayed)
                Add "--http-port 8080" to your start string without the quotes
                Michael
                Palmerston North,
                New Zealand
                ex-FR24 Feeder

                Comment


                • #9
                  Originally posted by nzradar View Post
                  Add "--http-port 8080" to your start string without the quotes
                  Just tried that, dump1090 won't run with that added to the string, the correct syntax is "--net-http-port 8080" but even with that added the map is still not displayed (dump1090 should default to that setting anyway)
                  Ben.
                  FR24 F-EGLF1, Blitzortung station 878, OGN Aldersht2, PilotAware PWAldersht, PlanePlotter M7.

                  Comment


                  • #10
                    Any javascript errors? It just looks like the javascript that drives the web map is broken for some reason.

                    Comment


                    • #11
                      @F-EGLF1: Ben, you're right. I tried this already, also "--net-http-port 8081" and then in the browser "http://localhost:8081". Same result.

                      @obj: A good idea, thank you very much indeed. I looked up in FireFox's Web Console and found this (please see Screenshot):
                      JS-ERROR.gif
                      Definitely JS errors, as you can see. In my experience: the more errors occur, the more simple is the reason for the error - at least in most cases. BTW: JS is, of course, enabled in the browser.
                      It seems to me, that the error displayed at the bottom ("initialize is not defined") may lead to a solution. Maybe I can fix it, but I'm not too optimistic though...
                      Last edited by Wolli; 2014-12-29, 14:40.

                      Comment


                      • #12
                        Have you made any modifications to config.js? If you introduced a syntax error there, that would explain most of those errors.

                        Comment


                        • #13
                          Originally posted by obj View Post
                          Have you made any modifications to config.js? If you introduced a syntax error there, that would explain most of those errors.
                          No modifications. All files are original, taken out of the zipfile I mentioned in my 1st posting.

                          However, I'm watching an interesting effect, that I've never seen before:
                          When I see the "white window" (which you can see in the screenshot of my 1st posting), I displayed - just for interest - the source code by "right click->show source code" (in German "Seitenquelltext anzeigen") of the "white window". What I see is - as expected - the same source code as it can be seen when opening the file "gmap.html" (this is the only html-file contained in the zip). BUT: at the end of the file additional code is added, which is identical to the last lines of the source code.

                          To make it more clear, see the following screen shot of FireFox's "display source code":
                          SourceCodeDisplay.gif
                          Note, that the last four lines appear twice (!), and the first of the repeated 4 lines appears as a fragment! This happens not just to the html file, but also to all (!) JS-files contained in the zipfile. No wonder, that they produce errors!
                          To make it clear: but when I open the file(s) with a plain text editor, I do *not* see the additional four lines. Strange, eh?

                          I've never seen such an effect before. But I will perform more investigations concerning this effect and will make a further posting about the results.
                          Last edited by Wolli; 2014-12-29, 20:47.

                          Comment


                          • #14
                            Problem solved: now running!

                            I have found the reason for that "bug", described in my 1st posting: I have now converted all files in the subdirectory "public-html" and its subdirectory "coolclock" from the DOS text format into the UNIX text format and now it's running as supposed to be, look here:
                            NowRunning.gif

                            An open question for me is now, why the files contained in the zipfile were originally - obviously - in the DOS text format. I downloaded the zipfile from Malcolm Robb's website straight into a new folder on my local HD drive and extracted the files using the Windows built-in ZIP tool. This was obviously the BIG mistake. Had I used WinZip for extracing, I would have had probably absolutely no problems.

                            However: thank you all for your friendly support. Kind regards, and have Happy New Year, -Wolli-

                            Comment


                            • #15
                              Yeah, sounds like some serious weirdness in dump1090's internal webserver, I really don't trust that code at all.

                              From a quick skim the only way I can see this happening is if stat() is returning a too-large size for the file on disk. dump1090 doesn't actually check the return value of read() so a short read won't be noticed and you'll get whatever happens to be hanging around at the end of the buffer from last time. No idea why stat() would be returning a different value. I wonder if Windows is doing some mangling in read() that ends up reading fewer bytes than stat reports. Silly idea of "text mode" files strikes again? Workaround would be to convert all the files to have LF endings, not CRLF.

                              (I'd get you a build with a bugfix, except I have no Windows development/test environment and frankly no desire to set one up!)

                              edit: snap, I see you worked it out yourself

                              Comment

                              Working...
                              X