Possibly wrong use (or definition) of RF212_DATA_MODE_DEFAULT

[miri-in]

Hi,

in experiments with different PHY modes of the AT86RF212
is stumbled across a possible bug regarding the activation of BPSK-20.

If one sets RF212_TRX_CTRL_2_VALUE to RF212_DATA_MODE_BPSK_20 (==0x00),
analogously to tos/platforms/ucprotonb/RadioConfig.h (line 136),
then register RF212_TRX_CTRL_2 is not changed from its
actual default value 0x24, which is not BPSK-20, see [1, page 95].
This is because,
in tinyos-main/tos/chips/rf212/RF212DriverLayerP.nc (lines 249, 250 as well as 279, 280),
the register RF212_TRX_CTRL_2 is written only if
RF212_TRX_CTRL_2_VALUE != RF212_DATA_MODE_DEFAULT
and in tinyos-main/tos/chips/rf212/RF212DriverLayer.h (line 147)
RF212_DATA_MODE_DEFAULT is set to 0x00.

In summary, I think the value of RF212_DATA_MODE_DEFAULT
should be changed to 0x24 if it is used as in RF212DriverLayerP.nc.

Best regards,
Michael

[1] www.atmel.com/images/doc8168.pdf

[cire831]

any reason you closed this?

misunderstanding? not really an issue?

[miri-in]

I was asked to submit a pull request for this problem.
However, I'm not very familiar with the conventions regarding pull requests and issues and thought that a pull request and an open issue for the same problem would be a kind of unnecessary duplicate
--- sorry if this was wrong.

[cire831]

no, not unnecessary duplication.

the issue tracks well the issue. What is being fixed.

A pull request against an open issue says here is the code that fixes this
problem and here is where it is.

then we merge the snippet of code over into the mainline from the pull
request.

that make sense?

On Mon, Sep 7, 2015 at 8:19 AM, miri-in [email protected] wrote:

I was asked to submit a pull request for this problem.
However, I'm not very familiar with the conventions regarding pull
requests and issues and thought that a pull request and an open issue for
the same problem would be a kind of unnecessary duplicate
--- sorry if this was wrong.

—
Reply to this email directly or view it on GitHub
#348 (comment).

Eric B. Decker
Senior (over 50 :-) Researcher

[miri-in]

That makes perfectly sense, so I reopen the issue, see #350.