Hello, I share the project
just watch out for the sdk routes
regards
Thank you!
What sdk routes do you mean?
Hi Fdiaz,
thank you for your help to the community.
I was looking into your solution, however I canāt get any position.
I keep to receive:
Any ideas?
This is pretty cool customization!
Is there a way to see the number of anchors responded? Is it the rows parameter in optimise function?
I want to replace the quality number with number of anchors responded.
Thanks ahead
Hi seabubbles,
Iām glad to hear that you are using my contribution.
Make sure you have at least 3 anchors available with their positions correctly configured.
have you downloaded the drive project?
you can increase maxIteration> 100
increase the precision value> 0.5
try and tell me your results.
regards
Hi rchan,
Iām glad to hear that you are using my contribution.
Of course, meas_cnt indicates the number of anchors, although by firmware design it can only be 3 or 4.
It is also possible to replace the quality parameter with some data that suits us.
extern signed int trilat_solve (const double * an_pos, double * meas, unsigned int meas_cnt, double * prev_pos_est, uint8_t * quality)
regards
Hi FDiaz, first of all thank you for your time.
Yes, at least 3 anchors available
Yes, now.
Actually in my previous post I didnāt. I just integrate your code with battery stripping into another app.
Anyway, after having downloaded the drive project and built it, I still received
Pos: N/A p_vbatt:3672
p_vbatt is a nice add, but doesnāt help for position thoughā¦ 
[quote]
ā¦
you can increase maxIteration> 100
increase the precision value> 0.5
[\quote]
I did it, but no output change. Position is still N/A.
Any further ideas?
Hey @seabubbles as you may have seen I had the same NaN problem as you do right now. To figure out what the problem is, I took some sample data (based on real world scenarios) and let @Fdiaz algorithm approximate the position on my PC (not on the DWM1001). There, it worked pretty fine while the DWM1001 istelf always fails to approximate it. I still could not figure out what the problem is, but I have a suggestion:
As I read in other topics of this forum it might be worth a shot to position anchors at different height levels in order to avoid GDOP. Have a look here.
https://forum.qorvo.com/t/dwm-1001-anchor-placement/4303
I myself havenāt tested that solution yet. Instead I rewrote the custom LE in java which works when I receive only distance data from the DWM1001. Yet I still suffer from positioning errors when my tagās Z coordinate is high 
Let me know if youāre interested in my java solution.
Regards,
Max
Hey @Fdiaz,
I went through your custom LE algorithm and understood everything quite well except that last function which you called āgauss34ā. In my opinion, a Gauss-Newton method has already been finished by that point but then you call that function whose purpose I honestly donāt understand. If youāve got some time to provide some more detail on it, Iād be glad to hear it!
In genereal, how many anchors and tags do you have in your RTLS? And where did you position the anchors? Are they all on the same height level? And do you only use your Gauss-Newton solution to calculate the tagās position or do you make use of something else, too (Kalman, Levenberg-Marquardt etc.)?
Regards,
Max
Even if you do position the anchors at the same height it may be worth entering them as being at very slightly different heights (just a cm or two).
If the heights are all exactly the same it opens up the possibility for all sorts of divide by zero type issues in the position calculation. In theory the code should be written to cope with this but if in doubt it makes sense to avoid the issue altogether.
Okay, Iāll try that out. Do you know if the internal LE can cope with this?
Hi, sorry for the delay
Forget to comment that the solution is focused on improving the calculation in z, so it requires that the anchors are not coplanar.
can you share the location of your anchors?
An example of anchor placement is as follows:
a0 (0,0,1.2)
a1 (5,0,1.5)
a3 (5,5,1.2)
a4 (0.5,1.5)
You can also change the float to double, in my case it required a quick calculation, but if the time does not affect you, you can change to double and you will get a better result (sacrificing time and iterations)
gauss34 is the solution for a system of 3 unknowns 3 equations and the solution vector, in this case it always has the same size, it doesnāt matter if you have 3 or 4 anchors.
you can easily adapt this algorithm to Levenberg-Marquardt, in my case it also required a quick solution, Gauss-Newton is faster than Levenberg-Marquardt but it is more crude.
regards
Hi @Fdiaz, thanks for that information. My 4 anchors were all at 2.35m altitude. Iām gonna lower 2 of them significantly to see if things change.
The coordinates of my anchors so far are (in meters):
Initiator (0.02, 0.3, 2.35)
Anchor 1 (0.02, 3.41, 2.35)
Anchor 2 (3.75, 3.41, 2.35)
Anchor 3 (3.75, 0.1, 2.35)
My plan would be to lower Anchor 1 and Anchor 3 to 1m altitude.
Regarding āgauss34ā thanks for the clarification. So ultimately it is a necessary step for computing accurate positions. Because I had some torubles with it, I just commented it and surprisingly sometimes (like 50% of measurements) got pretty good results, too. Thatās why I was wondering what āgauss34ā is actually doing.
Last but not least, for your use-case you only use one positioning algorithm (Levenberg-Marquardt it seems) and no Kalman Filter or anything else. Am I right with that?
Thanks again,
Max
If youāre only interested in unfiltered distance data, just grab the distances measured by the tag and do whatever you want with them. To save energy, you can turn off the internal Locaiton engine.
Thank you for sharing this.
However, I am still stuck on the step on how to disable the prebuilt LE? Any help would be much appreciated.
Hello, it is a pleasure to know that this information is of interest to someone.
just compile the file as indicated in the post. Method overwriting replaces the internal engine logic with the proposed logic.
regards
1 Like
Alright. Thank you! 
Hello, first congratulations on your study. I have a question, would it somehow be possible to calculate the location with more than 4 anchors in this method? I understand not because of the firmware, but I donāt know if Iām wrong and if you think there is some way to do it.
A greeting
Hello, itās nice that you like it, if possible by modifying the function that calls the location calculation, for this you have to check if it is a dynamic or static memory reserve. In principle the firmware is limited to 4 anchors to reduce the calculation time and memory space. I am going to check if I can modify the amount of reference anchors.
regards
1 Like
Hello, I would be very grateful if you could share that with us.
Thanks!
Regards