HL Status Sys Status

[Kethku]

I've purchased and mounted two dwm1000 modules onto breakout boards which I have wired up to some raspberry pi picos as a first test for an indoor positioning system I'm working on. I was able to get the dw1000_id.rs example working and got correct id values back, but when I built one of my picos for tx and one for rx, I never receive a message on the rx programmed device.

After some searching I found https://decaforum.decawave.com/t/i-can-not-receive/838 which seems similar to my issue (no received messages) and the decawave folks suggest inspecting (or printing out) the sys_status register to see if the receiving module changes that register at all when a message is expected.

I then started digging through the dw1000 module code to see if there was a way I could access that information from the high level api, but it seems like its only available through flags in the low level api.

TLDR: is there a way to access the sys_status flags in the high level api and or how would you recommend debugging a lack of receiving (or sending) messages ?

[Kethku]

I would also be happy to build a wrapper over the lower level registers. I was digging into the user manual for the dw1000 and there seems to be very details descriptions of what each flag does. Even just having a GetStatus function which returns a struct with well documented booleans would be a reasonable enough approach that imho would be approachable, but I don't know if thats the correct abstraction to build.

As a side note, I'm very excited that this library exists! I was somewhat dreading the prospects of writing my own, and was even considering dropping down into an arduino wrapper in c. Having this available though means I can stay in comy cozy rust land which is a huge boost to my productivity. Super happy about this

[hannobraun]

Hi @Kethku, thanks for opening this issue!

is there a way to access the sys_status flags in the high level api

I think the only way to check those flags is through the low-level interface. This is not intentional, just something that no one bothered to implement so far.

how would you recommend debugging a lack of receiving (or sending) messages ?

It's been a while since I seriously worked with this library (initial development was back in 2019), and my working knowledge regarding debugging these kinds of issues has deteriorated. I remember there was lots of reading the user manual, figuring out which status flags I can check. You're on the right way with SYS_STATUS, but there might be more relevant registers.

I think I've built some of the examples (like dw1000_only_rx) specifically for debugging, so maybe that can help you. A simple program like that might receive much more reliably than a less trivial one. It's quite easy to introduce timing problems, e.g. by doing something else while you should be receiving. My memory is hazy, but I remember having lots of problems before I got the examples to work reliably.

It's also possible that something broke, due to updated Rust versions or updated dependencies. Again, my memory is hazy, but I remember there being some mysterious cases of breakage that I had to fix. I'll try to confirm that the examples currently work with up-to-date versions of everything, but it might take a few days until I can get to it (just got back from vacation and started working through the backlog).

I would also be happy to build a wrapper over the lower level registers. I was digging into the user manual for the dw1000 and there seems to be very details descriptions of what each flag does. Even just having a GetStatus function which returns a struct with well documented booleans would be a reasonable enough approach that imho would be approachable, but I don't know if thats the correct abstraction to build.

That would be a very welcome addition! And the approach you describe sounds reasonable. Don't worry too much about the correct abstraction. I'll merge anything that is an improvement over the current state. We can always refine stuff later, as we figure out better ways to do things.

Please note that there's a pending pull request (#134, see #133 for context) that I haven't had a chance to look at. It includes lots of improvements and might already add what you need. In any case, any work you do should probably be based on that branch, to prevent merge conflicts.

As a side note, I'm very excited that this library exists! I was somewhat dreading the prospects of writing my own, and was even considering dropping down into an arduino wrapper in c. Having this available though means I can stay in comy cozy rust land which is a huge boost to my productivity. Super happy about this

Glad you like it!

[hannobraun]

@Kethku I can confirm that the various RX/TX examples are not working for me. Something seems to be wrong. I've opened #140.

[Kethku]

Good I'm not crazy hahaha