Open araichev opened 6 years ago
Hi, is there any update on this?
Is this likely to be due to the changes in void LoadPAT(char *filename) ?
You got bit by two peculiarities in the code's operation.
The first was that you specified an antenna elevation file that just had the beam tilt specified and no actual radiation profile values. What happens is that the code then assigns a value of 0 to all the elevation angles. When it's building up the array of antenna_pattern[azi][el], it multiplies the azi and el values together to arrive at the total value for that particular spot. In this case it meant that it was arriving at a value of 0 for everything. Had you not specified an elevation file it would have arrived at a value of 1 for all the the vertical elements of the first two radials of the azimuth, which was probably what you intended for your test case. Alternatively you could have fully specified the values in the elev file and it would've multiplied them out properly. So in one regard that was a user error, but quite frankly the code should have caught that your elev file wasn't properly formed and errored out with a gripe.
The second issue is that when the code is applying the antenna_pattern to the final loss value, it considers the value of 0 to mean "don't incorporate the antenna loss into this point". So all those values of 0 you entered on the radials just mean "ignore the antenna for this radial". On the other hand, a 1 is interpreted as full strength or rather no loss or gain, i.e. "ignore the antenna for this radial".
So, in summary, if you move your el file out of the way and fill your .az files with something like 0.0001 instead of just 0 for the radials you want to block, it'll do the right thing.
The bug is that the code should detect that az and el files have the right number of values and should make sure those values are >0 and <=1. This should be done in LoadPAT(). I will fix this in my fork of SPLAT!.
BTW, thanks for the nice bug report and inclusion of your files.
Ok, it's harder to fix than it initially looked...primarily because it's OK to have a missing azimuth radial or elevation angle. For both, the code will try to interpolate the value if it's missing. The best I can do is have it gripe if there're fewer than two values in each file, as it needs a minimum of two to do the interpolation. In my fork, I made it so that it gripes if there're less than entries in either the az or el file. I also fixed things up a bit so that you can add 0 in those files to mean your antenna does not radiate in that direction at all.
Hi there,
I'm running SPLAT! v1.4.0-2 on Linux Mint 18.3 and am encountering the following weirdness.
My azimuth file seems to have no effect.
Here are the details.
I created two transmitters, tx_1 and tx_2, and put them at the same location near sea level in Whangarei, New Zealand; map at http://geojson.io/#id=gist:anonymous/2f06cbb3cef490acd7af05fcba889905&map=8/-35.876/174.444 . The only difference in the transmitters is their azimuth files: tx_1 has a 2 degree beam width and tx_1 has a 360 degree beam width.
I then used SPLAT! to generate coverage reports via the command
splat -t tx_1 -L 8 -dbm -db -110 -metric -ngs -o ../splat_output/tx_1.ppm
and the analogous command for tx_2.SPLAT output apparently identical PPM files (smaller PNG versions attached) showing 360 degree coverage, but i expected the tx_1 signal to cover only a ~2 degree sector.
Is this a bug, or am i doing/interpreting something wrong?
My SPLAT! input and output data, including the necessary S36E174 SRTM3 elevation file, can be found at https://mega.nz/#!ht4XGBjC!30sO95y7Ugo2ANwegrPhLlWRG8qsAd7UOH5v4VsVT4I . Couldn't attach the files here, because Github does not like their extensions.