Hello gentlemen, developers.
Can you please tell me where in the code I can programmatically correct the center frequency of the channel by adjusting the error of the reference frequency of the quartz resonator?
The situation is as follows:
I bought a new TTGO v2 board for the 433MHz range. EU433 regulation requires setting the frequency to 433.175 MHz. (I can see this in the code for the RadioInterface.cpp) Due to the spread of the clock frequency of the quartz resonator, I see the actual center of the signal frequency in the spectrum - 433.575 MHz.
I probably found a partial reason for working on a different channel. This is an automatic reconfiguration of the board through empty channels. With a rigid installation of the board’s operation on channel 1, the frequency is set correctly. But still, the frequency is not exactly in the center of the round number. So, the question of correcting the center of frequency is still relevant.
Hmm. We could pretty easily add a “frequencyOffset” parameter (for use by very advanced users only ). Can you create a bug on GitHub and from that bug link to this thread so we don’t forget?
HPDTeK HDP13A (SX1276) and HPD14A (SX1278 ) (in use by TTGO LoRa series) have regular crystal resonator with average deviation of ± 4 kHz at room temperature. However, few HPD13A modules may need correction of up to 10-12 kHz:
Certain new TTGO T-Beam boards are using HPD16A (SX1262 based) module with built-in TCXO. So the frequency adjustment is typically not required there.
I want to highlight an important point. The vast majority of LoRa units do not have built-in TCXO, especially for 433 MHz modules. 99% of the modules are bought on Aliexpress/Bangood/etc., where the Chinese masters of PCB do not think about technical nuances. Only a very small number of proprietary “Meshtastics modules” worldwide boast a TCXO…
I assume that those who plan to deploy a network in their area are very likely already experienced people and/or are radio amateurs. There is a possibility that many have on hand or have the desire/opportunity to buy a RTL-SDR V3 receiver to control their position on the frequency. And I think this is very important.
Therefore, the ability to manually correct the center frequency is very important too!
There is no secret that most of RF devices on Chinese market are not CE/FCC/… compliant.
It is definetly not an issue that Open Source firmware developers need to take care about - instead, it is responsibility of the final customer to operate the device in compliance with the local law.
Best the developers can do in order to follow the regulations are to:
use dedicated (world region specific) channels only ;
apply appropriate transmit power limit ;
limit bandwidth of transmit signals spectrum within allowed boundaries ;
keep center of carrier frequency close to assigned value.
As an example, in deployed binaries of SoftRF firmware, we intentially do not allow a user for apply frequency correction of more than ±30 kHz:
There is a risk of violation of a local law by intentional or non-intentonal action otherwise.
Want more than 30 kHz ? - build yourself the firmware from the source code, then be responsible for every law violation by yourself.
Mr. Linar, allow me a little ethical criticism. I am not rude, I am friendly.
I understand your carelessness as a free developer in the phrase “It is definetly not an issue that Open Source firmware developers need to take care about…”.
But as a final manufacturer, I consider this statement to be irresponsible! Do you understand that the majority of users of your “product” could potentially violate the law due to the lack of high production standards by the Chinese?
You understand, but at the same time, you do not give a tool to fix the problem. You unsubscribed: this is not a developer’s problem … IMHO - this is wrong from an ethical point of view.
). Can you create a bug on GitHub and from that bug link to this thread so we don’t forget?