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?
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: [color=#008000]/[/color] [color=#008000]The[/color] [color=#008000]solution[/color] [color=#008000]is[/color] [color=#008000]invalid,[/color] [color=#008000]square[/color] [color=#008000]root[/color] [color=#008000]of[/color] [color=#008000]negative[/color] [color=#008000]number[/color] [color=#008000]/. [/color][color=#000080][color=#000080]ERR_TRIL_SQRTNEGNUMB. [/color][/color][color=#333333]You suggest it just an example but, I’m not sure how I would go about altering the math for z = r1r1 - xx - 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
[color=#333333]On another note I’m only seeing a range of ~55m on a paved parking lot surface not anywhere close to 290m.[/color]
In the “deadzones” are the individual tag-anchor ranges accurate (what is the error)?
What TREK mode are you using? Why do you think you should be able to reach 290m?