Changing brightness of a background image???

[Egil]

Thanks Larry!

I only used the width to calculate the scalefactor. Because of the ratio between width and height in the map I presently use, the scale factor will be the  same as if I also calculated it using the height.

When thinking of the calibration file... the use of it it quite logical. The present map has a equidistant projection, but most other maps have other projections. The figures in the calibration file are used to somehow compensate for this.

Another matter is the present map. I only assume that the edges are 180W, 180E and the poles. But I do not know...
And with this map 1 degree  is 10 pixels wide and high, so it is not really needed to calculate the plane positions with a very high position. Degrees with one decimal would suffice. And my original plan was to stick to such a scheme just to learn how to do things properly for any improved resolution updates later.

But using maps covering just a small local area, the presision needed will be higher. But then it also be possible to use the program for plotting planes by decoding signals from the planes "secondary" radar transponders, which is what they use in the data collection for websites like FlightRadar24 and planefinder.net. I contribute to planefinder.net.

Now I expect some visitors to arrive any moment,  so I will not be able to check in here till tonight (now it is 0900). And finally, I have also been in Beaumont,TX, but did not remember until you mentioned it.  


Regards,
Egil

[Egil]

LarryMc:

Your great interest in my map viewing project came as a surprise to me. And since I not yet had prepared any written plan for  the program, you have been kept more or less in the dark. This has never been my intention, so finally, I' try to make a description:


HFDL - short description:
==========================

HFDL is what Arinc is calling their shortwave dalatink service, available to the international airline companies.
Via a number of Ground Stations, spread all over the world, and interconnected via internet, this datalink network covers the whole globe. And since she shortwave radio propagation is constantly changing, The Ground Stations each is assigned a certain muber of frequencies the can use, and they change between them as needed, when propagation changes.

Each frequency in use, is very strictly controlled by the Ground Station.
The communication is "timeshared" in cycles which are divided into 13 "slots". Each cycle takes approximately 33 seconds.

The first of these timeslots is the "Squitter Broadcast". Each Squitter Broadcast contains the Ground Station ID, plus frequencies presently in use. In addition it contains IDs and frequencies for two additional Ground Stations.This additional stations info changes for each broadcast, and in five minutes all the other Ground Stations info has been supplied. The broadcast also specify which timeslot(s) are used for "household" (acknowledgements and assignments of slots for planes to use etc.)

The IDs and frequencies are not transmitted in "plain text". Instead station and frequencies numbers are used. And for all transmitted tata, in all slots, bitstuffing is extensively used. As a result, the transmissionsvery becomes very compact and effective.

The receiving end is responsible for decoding these data, using a system table for conversion to plain text. So for pilots and traffic controllers the system more or less appears as plain text communications.



Background for making this program:
====================================

Most of the hobbyists that plot planes by decoding shortwave radio signals, use the shareware PC-HFDL for decoding HFDL radio transmissions.
There are several other such programs that also can be used, but the price tags are rather high.

PC-HFDL prints the decoded data on the screen in addition of writing it to a log file. It can also communicate with other applications using a DDE link, but Microsoft does not recomend this method used. Therefore, if the decoded data is to be used by other applications, reading the PC-HFDL logfiles is the best way to do it.

The shareware "PlanePlotter" can read those logfiles, and most ot the hobbyists use that program to plot the position data on a map. But PlanePlotter is an "all singing all dancing" program, covering many other aspects of the decoding hobby, and was first made for direct decoding of VHF ACARS transmissions. But the last few years it is has changed to to mainly cover the needs of the folks wanting to plot planes (mostly military) that are not transmitting transponder signals in "mode B" and use "mode C" instead, e.g. no position data transmitted. So they cooperate in groups, using a multilateration technique to determine the plane positions. To obtain this, they feed PlanePlotter from ADSB decoders, receiving the 1090MHz transponder signals.
This possibility have done the PlanePlotter software less useful for HFDL fans.
(For more details on PlanePlotter, check: www.coaa.co.uk/planeplotter.htm )

But what HFDL decoding enthusiasts like me really want, is a program that can plot plane positions on a world map, with the posibility to enlarge the map to see more details during periods of heavy traffic, making the plots overlap each other.
And have the possibility to view the received data in a kind of grid, either "live" or later.



Preliminary program requirements:
==================================

1 - Read decoded data from multiple PC-HFDL logfiles.
   (running multiple instances of PC-HFDL)


2 - Ability to receive data via TCP/IP, using UDP.


3 - Save received "raw" data in a new logfile


4 - Parse new data and use the "Air IDs" to retreive:
   Flight ID    
   ICAO number
   Plane Callsign

   (Air ID is a unique number assigned to a plane each time
    it logs onto a new Ground Station, and is used on all
    transmissions tgo and from that Ground Station after a
    logon is acknowledged)


5 - Plotting decoded data to a world map.
   (Showing the whole world, and have ability to enlarge a
    specified area for more detail)


6 - Make some kind of temporary storage to register the time
   a plane was detected, and "delete" it from the plot if no
   transmissions are detected after a specified delay.


7 - List ID data with time stamps in some kind of grid.
   (Maybe this best is obtained by a second programme,
    using data from the new logfile)


8 - Update the grid whenever a new ID element is detected
   (see point 4 above)


9 - Possibility for sharing the data "live", using TCP/IP.
   (Not really needed, but can be added later)




EDIT: Almost forgot the next steps:
=========================


10 - Plot the ground stations in a different color than the planes.


11 - Retrieve Ground Station names and active frequencies from
     the squitter broadcasts.


12 - Show Ground Station names and frequencies by pressing a key
     when cursor is over it. Remove text when releasing key.


13 - Show plane ID's by pressing a key when cursor is over it.
     Remove text when releasing key.


( By changing  to an "ordinary" menu instead of the context menu,
  a mouse button can be used for steps 12 and 13)





Hope I don't sound too confused...


Regards,
Egil

[LarryMc]

Got the graphics code so the ground station symbol and name is displayed. See attached.  I haven't attempted to build the database for the routine to update from. Do you want it to update directly from the System Table.txt you sent me a copy of?
I can make steps 10,11, and 12 happen from that if you like. Question: When you click a base station do you want the freq to overprint directly on the globe(harder) or do you want the info to show in a popup window(easiest).?

In the attached src file I added a men at the top of the app. with it you can turn the planes on/off, ground stations on/off, and what I think is the user's home station on/off from displaying. By adding a setup option later it will make it a lot easier to add all the options for colors and such and save then to an ini file.

And am I remembering correctly that the March28.txt file you gave me is typical of your source of information for plane position and that is what I need to decode and glean for position info? How often will you be getting these files and processing them?

[Egil]

Great Larry!

Exactly what I meant. The pictures look great, only hope Bev McEvan (author of PlanePlotter)  don't go bananas when he sees that we are  using the same symbol and colors as in his program....
BTW, I had a look in the PlanePlotter directory, and see that Bev uses the FeeImage library.

The log file I sent you is the output of PC-HFDL whithout any modifications. So that's what we have to deal with.
I almost feel ashamed of calling the program "LA2PJ's HFDL Viewer" since now you have done most of the hard  work. But I don't mind. Especially now when I have problems  with typing.
Have to give you all the credits in the User Guide.

I hope to rearrange some of my UDP routines tomorrow, making them ready to include in the program.


Egil


PS:
The Ground Stations can easily be loaded from a file, using the Menu choise shown in the picture.

[LarryMc]

sketch me symbol(s) and scan them that you want to use and I'll make it happen.
All I was doing was building a code structure

[LarryMc]

changed the symbol, color and text location for ground station
changed the symbol and color for home station

[LarryMc]

I was giving some thought to these two items:

12 - Show Ground Station names and frequencies by pressing a key
     when cursor is over it. Remove text when releasing key.

13 - Show plane ID's by pressing a key when cursor is over it.
     Remove text when releasing key.

Previously I had been thinking of extracting the lat and long info from your log files and storing it as it as

UA0101  LAT 55 27 32  N  LON 6 17 3  W

or more precisely

UA0101  55 27 32  N  6 17 3  W 127

Then when it is time to update the display I would read this internal data file(maybe a linked list) and feed the coordinates to the calc to get the x,y point to display. The 127 value shown above is the calculated heading based upon two consecutive locations so the pointer on the plane symbol can be positioned properly.

In order to click on a point on a screen and see if it is a plane or a ground station we'd have to reverse the process.
Take the x,y point, send it to a calc that converts it to a lat/long format and then go thru all the planes and ground stations looking for a close match.  In my opinion with rounding errors and such that would be hit and miss and extremely slow.

What I propose is that when extracting the info from the log file the conversion to the x,y coord be done at that time.
Then that would be stored as

192, 204, UA0101  55 27 32  N  6 17 3  W 127

Then when it is time to display the only adj that needs to be made is for scaling.
And when single clicking a quick initial proximity search for close 'x' saved to a linked-list followed by a search of that linked-list for close 'y' gives you a match if there is one. (that thought process needs to be optimized).

I think this scheme would pretty much lock you in to these images though.  Let me know your thoughts before I spend time on the code.

[Egil]

What I propose is that when extracting the info from the log file the conversion to the x,y coord be done at that time.
Then that would be stored as

192, 204, UA0101  55 27 32  N  6 17 3  W 127

Then when it is time to display the only adj that needs to be made is for scaling.
And when single clicking a quick initial proximity search for close 'x' saved to a linked-list followed by a search of that linked-list for close 'y' gives you a match if there is one. (that thought process needs to be optimized).

I think this scheme would pretty much lock you in to these images though.  Let me know your thoughts before I spend time on the code.

That is a very good idea, and I like the idea of a linked list. I have no experience with such a list myself, only read about it. But reckon using a linked list wil be ideal for showing a chronological log in a grid.
And the map we use right now is ideal for this application. Why not just go ahead and get some experience with using this program, and think of possible changes when and if we ever think of other applications.

I can see several other applications where this sceme fits right in. I am always thinking amateurradio, so a program for satellite tracking (which ignited this idea), and a program for showing callsign areas, antenna beam directions, distance calculation and showing greyline. (Graham made such a program several years ago using CB)
And I am sure other can think of many other applications....


Having pc problems here today, if a compile displays warnings or errors, I am not allowed to  doubleclick them to inspect the line in question.  Instead a line saying Access denied. In addition I noticed that when trying to  run the LogFix program (posted in another  topic the other day), which I plan to incorporate in MapView, it does not write to the new logfile. And though I do not  get any error messages, I think that is part of the same problem. The LogFix program and four instances of the PC-HFDL decoder program have been running in the background for hours every day on this pc, just to be sure that all work ok, so do not undeerstand why this is happening now. So today there will be a lot of head scratching here...


Egil

[LarryMc]

I guess it seems I'm trying to take over your project but I'm really not.
I'm just trying to help you set up a framework for you to be able to do what you want to do.

Since I feel you will need an ini file to hold your configuration information I'm going to add those supporting subroutines.
That means I am going to change the basic structure of your program over to a "project".
In the long run it will make your program more modular and it will help you convert it to the other uses you mentioned later on.

So, I will proceed with the structure I described above which begins with reading and extracting aircraft info from the March28.txt file you gave me.

[Egil]

I guess it seems I'm trying to take over your project but I'm really not.
I'm just trying to help you set up a framework for you to be able to do what you want to do.

I have no such thoughts, Larry, and is grateful for all help I can get. Especcially now, with only one hand to do the typing. (In fact most of the time is spent correcting all the typos I do.... )

Since I feel you will need an ini file to hold your configuration information I'm going to add those supporting subroutines.
That means I am going to change the basic structure of your program over to a "project".
In the long run it will make your program more modular and it will help you convert it to the other uses you mentioned later on.

You are most probably right. And I get a nice example on how to work with projects. The few former attempts to do that, have resulted in working with everything in one file because of all  the definitions I do wrong. I have read the tutorial you did on projects some months ago, but still I've not got it  right.


Here, I found my computer full of all sorts of crap. Seems it has been like that since wednesday morning. All my work on this pc since then have been reading and answering email, and using IWB. And found all the files I have used IWB to modify are more or less corrupt. So was several files in the IWB bin directory.
I had to uninstall IWB, and then do a proper cleanup on the computer, using JRT And WiseCare365. Then I chose a restore point from monday last. And after a cold restart of the computer, I found nothing wrong. So later tonight I will reinstall IWB. Last backup was made monday, and thereafter the latest restore point was made. So If I don't get things right now, I'll use the backup to restore the pc.

Probably got the malware when visiting some radio pages wednesday morning.m Followed some links that turned out to be bad when visiting a site on the qsl.net. And if I ever am lucky to meet a person making this cap, you know what I'm going to do...


Egil

[Egil]

Reinstalled IWB, and now it appears to work ok. But I still get the "No Access" message when trying to click on compiler warnings on the files made by LarryMc. Do not understand why.
Had to discard the UDP and LogFix routines I had modified for instertion in the MapView program. But that is no deal, as I still have the original files.

These two will be imported onto the project Larry is setting up. And in that connection I have one question: Can I use the global variables in these two files locally in each module, and only define as global those that have to be called from  or shared with the other modules? Or will there be a clash with variables using the same name?


Egil

[LarryMc]

if they are in different modules(source files) and haven't been made global then there should be no problem.
I'll be happy to help you merge the pieces into the "project" I am building(at this very moment) for you.

BTW, I sent you an email you need to respond to.

[LarryMc]

Attached is exe file where I've made the zoom in double of what it was. Let me know what you think.
With this level of zoom it will spread things out a little more but it slows scrolling down some.
you have 3 choices.
1. leave it like this
2. leave it like it was
3. give the user a menu option to switch to which to which ever one they like  

[Egil]

If it is not too much work, I kind of like option 3.

But I noticed a small snag, The positions are plotted a little south and west of their actual positions, and the error grows the further east on the map the positions are. I guess this comes  from rounding errors in the scaling of the pictures. This is ssomething we need to look into.

For the original size of the map (3600 x 1800 pixels) one degree is ten pixels wide both in N-S direction E-W. This means that degrees with one decimal is the highest resolution we can obtain when plotting.
So do you think converting the positions to degrees with one decimal before plotting will decrease update plot time?

Its over midnight here now, and I always wake up at five, so now I need some sleep.


Egil

[Bill-Bo]

LarryMc,

Mapview3 does not run for me. It cannot find the devil.dll.

Bill

[LarryMc]

LarryMc,

Mapview3 does not run for me. It cannot find the devil.dll.

Bill

you'll have to download one of the earliest zips in the thread that I posted to get all the other supporting files you need.
Or, if you had previously downloaded and compiled mapview just plug this exe file into that folder.

[LarryMc]

If it is not too much work, I kind of like option 3.

But I noticed a small snag, The positions are plotted a little south and west of their actual positions, and the error grows the further east on the map the positions are. I guess this comes  from rounding errors in the scaling of the pictures. This is ssomething we need to look into.

I like option 3 also and had already decided I was going to put it in and let you take it out if you didn't like it.

I'll look into the position error and see what I can find.

[LarryMc]

But I noticed a small snag, The positions are plotted a little south and west of their actual positions, and the error grows the further east on the map the positions are.

Duh!
I never finish my conversion subroutine!!!

I haven't added the adjustment for minutes and secs yet.  Let me get that in there and see how close we are.

[Egil]

Larry:

As mentioned earlier, we have no guarantee  that the map edges are accurate. But we have to use this one, as long as none of the web map servers allow us to download a calibrated map showing the whole world. I guess this is one of the reasons why the "professionals" use zero longitude and the Equator as a reference. Possible errors near the edges are then half of the amount compared to using 180W 90N as reference.
But this is something we can somehow adjust ourselves when the program is completed. It is an easy task to adjust a pixel ot three by stretching or crimping height and width of the drawing and keeping the picture dimentions same as before. PlanePlotter uses another approach for this. They use a manual calibration routine, where the plotted items all are dragged around with the mouse, and when the user is satified, the program makes a new calibration file.

Anyway this application is not meant for navigation, so we must somehow accept some offset.


Egil

[LarryMc]

After finishing calc subroutine it looks spot on to me right now.

give me a couple of points you want to check and I'll plot them and post a screenshot.

I'm in he middle of building the 'project' and adding some features so it isn't a good time to send you the code.

[Brian]

I am most interested in this project, seeing as I run Flightradar24 most days, but I am finding
that this technical talk is going right above my head, and probably at cruising height!

Brian

[Bill-Bo]

LarryMc,

Okay, I'm straight now. There's one thing though. Why does a second window (black) behind and to the upper left?

Bill

[LarryMc]

that's my trouble shooting console window.  when I need to see what a value is I just print it to that console window.
It won't be there in the finished product.

[LarryMc]

I am most interested in this project, seeing as I run Flightradar24 most days, but I am finding
that this technical talk is going right above my head, and probably at cruising height!

Brian

above my head to but I'm faking it.

[Egil]

Brian:

As a good englishman you should rather support and use a british project instead of FlightRadar24. There are a couple of clever young guys in the Southampton area running a competing website: planefinder.net.
They are really nice guys, and as far as I know, they do programming for a living. And the plots from central parts of Norway and to some extent Sweden, are decoded and shared with them by yours truly. I have a small vertical antenna just outside my upstairs bedroom window, to feed the decoder which is just another fast AD converter plus some smart pc software, all british made. And for your information, all such kind of coding/decoding (HFDL, ADSB, AIS etc) rely heavily on bitstuffing.

I there is any interrest, I can post an EB console example I made several years ago, demonstrating what a 14 byte long NMEA-0183 sentence from an AIS-decoder really meant when converted to plain language. That was an eye opener to me, and showed how much information that really can be losslessly compressed into a small sentence just by manipulating bits.


Larry:

My smartphone GPS gives my location like this:

63 06.2700 N
007 39.0300 E

Converted to the format similar to what the planes use:

63 06 16 N
007 39 02 E

I have indicated my position with a red dot on the map below, so you can test it yourself when you get around to it. Done the same with the position of Oslo.


Egil