Direction arrow seems incorrect

I can’t understand the code, so if you do please propose a fix at the GitHub issue posted earlier in this thread. I got an email reply today from the author mentioned at the top of file Screen.h. He says “It looks like my contact is there because they borrowed that file from a project of mine, but I’m not related to the meshtastic project… sorry.” So it appears this is a forever defect unless someone can understand and fix the borrowed code.

Could you PM the email received to me here? I’ll rework that header so they don’t get contacted again.

Done, and thanks for your meshtastic work.

I don’t think there is a defect. without a compass on the device it is an estimate that is most accurate while in motion, sitting on a table will probably never be real accurate.

Thanks mate. What happened was someone used published sample code.

I’ll take care of the header. Thanks for pointing it out!

This was already addressed garth. There is a defect. Please justify your opinion by explaining what you disagree with from this earlier post:

Motion is not necessary to tell the direction from one GPS location to another. For example in the test case I gave:
Latitude 47.626 (friend) is a little less than 47.636 (me) so is South .
Longitude -117.392 (friend) is a little less than -117.366 (me) so is West .
My friend is southwest of me. There is no need to be moving, and GPS receivers do not have to be moving to provide accurate latitude and longitude. (Motion is necessary to get the “N” pointed in the up direction on the display, but that not the issue here. The issue is that the direction of the arrow relative to the “N” is incorrect.)

You can read more about how works here, I think you are expecting a level of accuracy that is not available without a compass.

Screen will not show direction arrow - #6 by geeksville?

Not to gang up on Garth here, but the direction arrows on my devices are usually wrong too. Distance is correct but the arrows seem to be pretty random, certainly not correct

I looked and that doesn’t apply. You can do a Google search on “distance and heading from two points” to see it only takes two latitudes and two longitudes. Stationary GPS receivers provide that. It is nothing to do with motion. Here is one of may sites that will do the math for you. Again, this thread is nothing to do with the location of the “N” on the display. What is wrong is that the arrow relative to the N is incorrect.

1 Like

I looked into it and we can’t remove the copyright notice. It’s correct being there.

The screen.h was initially from another project which is covered by gpl3. Gpl3 indicates that any copyright notices can’t be removed.

That was a bit of fun research :slight_smile:

Yes and the N comes from the dead-reckoning based on your movement.

There is a thread here from when the feature was developed, it clearly is using movement Alpha tester thread (1.1.8 device code ready for alpha testing) 🙂 - #134 by CycloMies

If you see a bug in the code that can be corrected pull requests are welcome.

I see that today garth closed Meshtastic defect #1194 that corresponds to this message thread. I’ve explained the defect multiple times and have given replication instructions. I am a retired software Quality Assurance engineer with masters degrees in electrical engineering and computer science. You can trust me. #1194 is a defect. My posts in this message thread explain it.

Garth: Motion of the radio is required to get the “N” indicator in the display pointing correctly. No motion is required to get the direction arrow pointing correctly relative to the “N” and that is what is wrong.

1 Like

The code is working as expected, and requires motion to produce the N marker on the device.

Pull requests are welcome if you have a better solution in mind, but the code is doing what is expected right now and is motion dependent.

Garth please put defect 1194 back in open status and let someone that understands the problem and the code fix the code. All you are doing is stopping progress on this. It is a defect. The code is not doing what is required by users and is possible. Code pull requests and fixes are the responsibility of the code support people, not those submitting defects.

Please read this slowly and be sure you understand – When you are not moving, the location of the N can be anywhere on the circle. It doesn’t matter where it is. That is not the problem. There is no problem with locating the N on the circle. But once the N is drawn somewhere (anywhere) the arrow indicates the direction of the other radio relative to the N. For example, see my initial post where the N is up-left. No problem. I am not moving and the N can be anywhere. But relative to that N being North the arrow is pointing southwest and should be pointing southeast.

1 Like

The feature is very clearly based on being in motion, the developer who wrote this code has stated this several times. This feature is not going to be accurate sitting on a table.

1 Like

The feature

Which feature? I would agree that since the device has no compass, you are right that it must be in motion to display “N” correctly. This is one feature. This seems to be, as you say, “working as expected.” Nobody in this thread has argued that it isn’t.

Rick is reporting a defect on a different feature. It is the ARROW drawn within the “compass” circle, and whether it is pointing in the correct direction. Regardless of where the “N” is on the compass (, the arrow ought to be able to display correctly in relation to the “N,” since as Rick pointed out, it is a simple math problem to determine the precise bearing between two known GPS points.

If this is NOT a distinct feature, please correct me. I do not grok code and so I can only bumble my way through the code and read what is written in the docs to try to make my own devices work and be an effective bug reporter.

edit: haven’t figured out this forum’s markup language yet but this was meant to be in reply to Garth’s most recent post in this thread.

1 Like

The two features are connected. Where are people getting the idea that motion is not necessary? The feature as written works as expected once you walk about 20 meters.

@garth

@Rick314 is trying to say that, relative to “N” on the user interface, the direction to the other user is wrong.

Let me try to explain it with crude drawings:

The left part is the ideal case, where the direction of the other node relative to the North is determined correctly. The right part is the buggy case, where the direction of the other node relative to North is determined incorrectly.

Rick is not even talking about “N” being pointed correctly with regards to the device’s physical orientation. That part works well. What he is saying, is that the other node’s relative direction to the “N” on the UI itself is wrong.

Two GPS co-ords are enough to determine the direction between them. The orientation of the device towards North is irrelevant to the issue.

2 Likes

Looks to me like there’s a bug on line 680, where it’s figuring bearingToOther: it passes the two sets of coordinates to GeoCoord::bearing() in the wrong order, so instead of figuring the bearing from you to the other node it really figures the bearing from them to you. So the arrow points backwards from what it should do.

Seems like this would explain the behaviour described by Mihai, which I also am seeing (tbeam firmware version 1.2.52).

Seems unlikely as it would always be wrong if the coordinates were passed in backwards, it would also not include the original issue reported which is essentially that sometimes the bearing is off by ~90 degrees. I don’t have tbeams with screens currently, but I have never seen this work improperly when motion is used and have tested it several times. They code is years old. Put a tbeam at a known heading and then walk 20m or so holding the other device, in my experience it will point where you expect. Put them on a table and they are not going to point in the right direction relative to each other.