SW-23. Adjust BLE TX frequency based on 802.15.4 RX frequency #20
Conversation
[ll] Adding temperature sensor Python code (plotting, taking readings)
| app_vars.IF_offset_prev = app_vars.IF_offset; | ||
| app_vars.IF_offset = radio_get_IF_estimate(); | ||
|
|
||
| diff = app_vars.IF_offset / 12; // empirically tuned |
There was a problem hiding this comment.
Hi @tryuan99 could you explain how this 12 is obtained? You said it's empirically tuned. Is there a theoretical number you are referring to start the tuning?
There was a problem hiding this comment.
The original value was 20. The reason for this is that a fine code corresponds to around 100kHz in the LO frequency. In 100us, this corresponds to a difference of 20 zero-crossings. Therefore, I adjust the LC frequency code for every IF offset of 20.
However, while testing in the temperature chamber with a ramp rate of 1.5C/min and updating the IF estimate every 800ms, I found 12 to work a bit better (it overshot once and then returned back to its correct value).
| app_vars.IF_offset = radio_get_IF_estimate(); | ||
|
|
||
| diff = app_vars.IF_offset / 12; // empirically tuned | ||
| app_vars.rx_fine += diff; |
There was a problem hiding this comment.
This only assumes the LC oscillator drifts within a range that only need to tune the fine code, right? When it is not, such as a large temperature change, mid code calibration may need.
There was a problem hiding this comment.
Yes, but since the LC frequency code is not monotonic, I think in order to support a large temperature range, it's probably best to find the coarse/mid codes for different ranges of temperature and then do this "local" fine code calibration with the previously found coarse/mid code in this temperature range.
| signed short cdr_tau_history[11] = {0}; | ||
| #define FILTER_WINDOWS_LEN 11 | ||
|
|
||
| uint8_t FIR_coeff[FILTER_WINDOWS_LEN] = {4,16,37,64,87,96,87,64,37,16,4}; |
There was a problem hiding this comment.
How does the value of each elements in the coeff arrary come?
There was a problem hiding this comment.
Hmm, I used the same filter that Brad used to have for his radio_housekeeping() function. I can email him.
This PR builds on top of #17. SCuM is continuously listening for 802.15.4 packets being transmitted from an external OpenMote and broadcasts them as BLE packets. In the meantime, however, it tunes the BLE TX frequency based on the 802.15.4 RX frequency.
This code contains two applications
ble_tx_154_rx_track_ifandble_tx_154_rx_track_meanthat allow ScuM to adjust the BLE TX frequency tuning code based on the 802.15.4 RX frequency tuning code.For
ble_tx_154_rx_track_if, SCuM records the IF estimate of the received 802.15.4 packets and filters them all of the IF estimates to get an estimated IF estimate. The IF estimate counts how many zero crossings there are in the last 100us, so at the nominal IF frequency of 2.5MHz, there should be 500 zero crossings. Tune the RX fine code until IF estimate is closest to 500 and adjust the TX fine code by the same amount.For
ble_tx_154_rx_track_mean, every few seconds, SCuM stops and listens for packets from the Openmote within +-2 of the current fine code for 800ms each. It then finds the weighted average of the fine codes of all packets received. Find the difference between the current fine code and the average of the received packets and adjust the RX and TX fine codes by that difference.It also fixes reading the LQI and IF estimate when a 802.15.4 packet is received.