Closed ryan-summers closed 2 months ago
@jordens Upon reviewing the code, it looks like the RF channel transform slopes are largely dependent on the input signal frequency, while the offset is governed by the attenuator characteristics (which is likely more hardware-specific).
Given this information, I'm more inclined to not use the RF channel EEPROM and instead just leave it in main-board flash. What are your thoughts on this?
Edit: Here's a reference to the default transform calculations: https://github.com/quartiq/booster/blob/main/src/settings/eeprom/rf_channel.rs#L98
Slope will likely depend on PVT as much as the offset.
But on balance I agree that the benefit of making the transforms (physically) portable with the modules is small and the complexity is high. Let's just drop the per-channel configuration in EEPROM and move everything in to the CPU flash as in the other projects. Also make the save
functionality match stabilizer et al.
It was noted that certain settings, such as the power transformations, make the most sense existing on the physical RF channel memory. This would ensure that the transforms would move if the RF channel was installed in a separate device.
We should update the settings
save
feature to save the RF transforms to RF channel EEPROMs instead of the main board flash.