search

Decawave / mynewt-dw1000-core

[DEPRECATED] Use https://github.com/Decawave/uwb-core for new designs.
Apache License 2.0
57 stars 34 forks source link

Auto-FCS Transmission is not handled #31

Closed Beetix closed 4 years ago

Beetix commented 4 years ago

The function dw1000_write_tx does not handle auto-FCS transmission. In the current implementation TX frame length does not include the length of the CRC from auto-FCS transmission. I suppose the use case of suppressing auto-FCS transmission is not common so the quickest fix would be to add the length of the CRC from auto-FCS transmission (2 bytes) as in dw1000_write_tx_fctrl. If handling Auto-FCS Transmission suppression really has an application a check of the SFCST field from the System Control Register is required.

ncasaril commented 4 years ago

You don't actually need to write the two FCS bytes to the device. As long as they're included in the frame length programmed by dw1000_write_tx_fctrl they will be calculated and sent.

Beetix commented 4 years ago

What I meant with this issue is that the suppression of Auto-FCS transmission is not handled. An example would be if a user wants to compute his own CRC and doesn't want the one from the transceiver.

ncasaril commented 4 years ago

Ok, I see what you mean. The workaround is that the caller can add the 2 bytes to the length of the frame to write the additional FCS bytes using uwb_write_tx.

I've not yet seen an application where the FCS bytes are not computed by the device. Do you know of one? The closest I can think of is lossy streaming, where you deliberately don't use the auto-FCS because you're writing the data after start_tx has been issued and only want the frame to be considered valid if you manage to finish writing the frame before the device reads the last bytes in the buffer.

Beetix commented 3 years ago

I currently don't have a use case for suppressing the auto-FCS transmission. I just wanted to point it out to be clear.