segmentation fault on 64-bit os with height above terrain equal to 0m

[Rabijns]

When using splat! on a 64-bit Linux version, I sometimes get a segmentation error. The error only seems to occur when I place the receiver at 0m above terrain. The same receiver placed at 0.1m does work perfectly. The segmentation fault error is given just after the tool prints: Site analysis report written to: "tx-site_report.txt"

example files

rx.qth rx 51.7411627351 -1.1538047412 0m

tx.lrp 15.000 ; Earth Dielectric Constant (Relative permittivity) (15 = average ground) 0.005 ; Earth Conductivity (Siemens per meter) (0.005 = average ground) 301 ; Atmospheric Bending Constant (N-units) (301 typical uk value) 1275 ; Frequency in MHz 6 ; Radio Climate (6 = Maritime Temperate, over land (UK and west coasts of US & EU)) 1 ; Polarization (0 = Horizontal, 1 = Vertical) 0.50 ; Fraction of situations (50% of locations) 0.90 ; Fraction of time (90% of the time)

tx.qth tx 50.9 -4.6 26m

command used splat -t /home/test/tx.qth -r /home/test/rx.qth -d /home/test/terrain -m 1.333 -metric -gpsav -f 1275 -H /home/test/output/link.png

software version issues occurs ubuntu 14.04 LTS 64 bit with splat 1.4.0 and also on mint 15.2 64 bit with splat 1.4.0. It doe not happen on my mint 32 bit system (also with splat! 1.4.0).

[jsr38]

This is a git mirror of the source tarball release at the official page: http://www.qsl.net/kd2bd/splat.html

I do have some improvements and modifications that I plan to make to my fork of this repository but at that point it will be a fork of John Maglicane's original work.

I may get around to fixing what you observe but I suggest getting in touch with the original author until I get up to speed with the codebase.

[Rabijns]

Thanks for the Feedback. I'll contact John Maglicane directly.

Best regards,

Daan

Op 10/10/2015 om 11:37 schreef jsr38:

This is a git mirror of the source tarball release at the official page: http://www.qsl.net/kd2bd/splat.html

I do have some improvements and modifications that I plan to make to my fork of this repository but at that point it will be a fork of John Maglicane's original work.

I may get around to fixing what you observe but I suggest getting in touch with the original author until I get up to speed with the codebase.

— Reply to this email directly or view it on GitHub https://github.com/jmcmellen/splat/issues/2#issuecomment-147069477.

[hoche]

You ran into a bug with Sid's 2-ray calculation addition in hzns2(), where he does a divide-by-zero when trying to figure out the reflection point. If the receiver height is 0, the reflection point is infinitely close to it. If the receiver height is just small, it's just really really really close.

The site study will put out a "error number: 4 Warning: Some parameters are out of range." message if either antenna height is less than 0.5m (and a gripe about it if it's less than 1.0m) but it'll go ahead and try to do the calculation anyway and of course in your case it crashes before it gets around to emitting the message.

I fixed it in my branch, but this does bring up the point that if you're trying to do a study of a location that's below sea level (Death Valley, parts of the Netherlands, parts of Israel, Lake Eyre, etc) this code will likely spooge its noodles.

[Rabijns]

thanks for the feedback. The visibility calculation with 0m receiver height was actually a trick. What I needed to know was from which height on an object at a known lat/lon would be illuminated by my transmitter. I noticed that if one sets a very low height for the receiver, the tool does say in its output how many meters I would have to raise the receiver to get visibility. Which is why I placed my receiver at 0m AGL. I understand from you explanation that it would be better if I used 1m or more. (which would not be a problem for my application as far as I can see right now.) There is however something I would have to check somewhat more into detail. I actually do not use splat directly, but call it from with a python program. if I very quickly check the python code I use, it seems I avoid the error by setting 0.0, instead of 0 as height. But based on your explanation, this should also fail (or perhaps result in numerically unstable results).

[Rabijns]

I checked my code again, and apparently I was not looking to the latest version. In the latest version, I did indeed set a value different from 0 or 0.0. (value used is 0.01)