Dear Members, To protect the forum from spam, all new members initial posts will require approval before they are published. Please do not create a duplicate thread. If you do not see the thread then it has been queued for review.  If in any doubt, please contact us through DM Regards Decawave

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
X, Y, Z intermittent
#1
Hi all,
I was wondering if anyone else has had trouble with the TREK1000 system giving intermittent tag location data? I have my anchors positioned ~30m apart and even though I am receiving range values for all three anchors on the tag(and in QT RTLS) the X, Y, Z data is not consistent. Any thoughts? 

Also I'm using the auto-positioning feature, could this be affecting this?

Thanks,

Chris
Reply
#2
If there is no x, y, z then the solver cannot solve the location of the tag. You should check that the anchor-anchor distance is correct/accurate (anchor coordinates) and also chech tag-anchor distances are accurate.

If you are still having issues, then you can add debug to the location engine code to see where it is failing. The TREK location engine is quite basic, it is just an example, you may need to add improvements to improve it.
Reply
#3
(07-12-2018, 08:00 AM)zoran skrba Wrote: If there is no x, y, z then the solver cannot solve the location of the tag. You should check that the anchor-anchor distance is correct/accurate (anchor coordinates) and also chech tag-anchor distances are accurate.

If you are still having issues, then you can add debug to the location engine code to see where it is failing. The TREK location engine is quite basic, it is just an example, you may need to add improvements to improve it.

Thank you Zoran,

I tested with exact coordinates and no auto-positioning feature as well as making sure all anchors are the same height and I saw better results. There were a few "deadzones" where I didnt X,Y,Z data again and the error I saw occur: /* The solution is invalid, square root of negative number */. ERR_TRIL_SQRTNEGNUMB.  You suggest it just an example but, I'm not sure how I would go about altering the math for z = r1*r1 - x*x - y*y; to provide a positive value that makes sense for a "better" solution. What do you suggest to try to fix this deadzone issue. Thanks


On another note I'm only seeing a range of ~55m on a paved parking lot surface not anywhere close to 290m.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)