Transmitted frequency is occasionally 2 MHz off about sub-iot-stack HOT 3 CLOSED

Hi

Thanks for letting us know.
Some deviation could be caused by the Xtal offset, but not this huge indeed.

I have also send this reply to our mailing list [email protected]:[email protected], since this is a better way of communicating.

First of all, it could be wise to move to the draft branch (it is implementing the spec which is normally going to be voted upon by the end of the year).
Small changed are still going to be done in the protocol, but most of the developing effort and also fixing bugs is done in this branch.
It also uses a filesystem so checkout the comments in the headers of the example to adapt your linker script. (you also change the settings in d7aoss.h) not in the platform.h file anymore).

Can you compare the RF registers related to autocalibration. Maybe there is an error?

Maarten

From: rith87 [mailto:[email protected]]
Sent: 03 December 2014 07:57
To: CoSys-Lab/dash7-ap-open-source-stack
Subject: [dash7-ap-open-source-stack] Transmitted frequency is occasionally 2 MHz off (#16)

Hello folks,

I have a custom board that uses the Dash 7 stack on the master branch. The board works most of the time and TX/RX is fine. However, there are occasions where the TX frequency is ~435 MHz instead of 433 MHz and hence my receiver is unable to pick up the transmission. I was thinking that it was a hardware issue but I don't hit this problem with the sample 433 MHz configuration in the Smart RF studio. I tried replicating some of the registers (replicating the full set caused a hang somehow... my guess is because of the rising/falling edges in the interrupt handler) from the Smart RF studio but the transmitted frequency was still 435 MHz (http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/228/7888.no_5F00_rx.png).

Has anyone else hit this issue? I really hope that I won't have to switch to Simpliciti :(

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16.

from sub-iot-stack.

Thanks for the quick response!

Xtal offset? I assume you are referring to the PPM value on the crystal? I'm using a +/-10 ppm crystal so you're right, it shouldn't be such a large deviation.

Re autocalibration, that was my suspicion as well. However, I set MCSM0.FS_AUTOCAL to 1, which should recalibrate upon waking up from an idle state.

I'll take a quick look at the draft tomorrow and see if that's the direction we should be heading.

On Tuesday, December 2, 2014 11:58:31 PM UTC-8, Weyn Maarten wrote:

Hi

 

Thanks for letting us know.

Some deviation could be caused by the Xtal offset, but not this huge indeed.

 

I have also send this reply to our mailing list
[email protected], since this is a better way of communicating.

 

First of all, it could be wise to move to the draft branch (it is implementing the spec which is normally going to be voted upon by the end of the year).

Small changed are still going to be done in the protocol, but most of the developing effort and also fixing bugs is done in this branch.

It also uses a filesystem so checkout the comments in the headers of the example to adapt your linker script. (you also change the settings in d7aoss.h) not
in the platform.h file anymore).

 

 

Can you compare the RF registers related to autocalibration. Maybe there is an error?

 

Maarten

 

 

 

From: rith87 [mailto:[email protected]]

Sent: 03 December 2014 07:57

To: CoSys-Lab/dash7-ap-open-source-stack

Subject: [dash7-ap-open-source-stack] Transmitted frequency is occasionally 2 MHz off (#16)

 

Hello folks,

I have a custom board that uses the Dash 7 stack on the master branch. The board works most of the time and TX/RX is fine. However, there are occasions where the TX frequency is ~435 MHz instead of 433 MHz and hence my receiver is unable to pick up the transmission.
I was thinking that it was a hardware issue but I don't hit this problem with the sample 433 MHz configuration in the Smart RF studio. I tried replicating some of the registers (replicating the full set caused a hang somehow... my guess is because of the rising/falling
edges in the interrupt handler) from the Smart RF studio but the transmitted frequency was still 435 MHz (http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/228/7888.no_5F00_rx.png).

Has anyone else hit this issue? I really hope that I won't have to switch to Simpliciti :(

—

Reply to this email directly or
view it on GitHub.

from sub-iot-stack.

There have been major changes to the open source stack in the meantime, and no comments on this issue. Assuming this is fixed for now. If this issue is not fixed, do not hesitate to re-open the issue.

from sub-iot-stack.