-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing frequencies while receiving - Nothing Received #65
Comments
Hi, I don't know if I understood the question correctly. But it is so that the cc1101 module does not have to be reset for the frequency change. the init (); command may only be executed once in the entire program sequence. Otherwise problems can arise. When changing from tx to rx, the module must be set to sidle status once. otherwise not. The option SetRx (frequency); it was intended to go from Tx to Rx with a different frequency. To change the frequency when the module is already in the rx, this option is currently rather unsuitable. (I will adjust it in the next update). I recommend the option SetRx (); to use to switch to receiving mode. The last frequency is retained here! To change the frequency on the fly you should setMhz (Frequency); use. Then everything should work fine. I am happy to answer any further questions. |
You could include the following in the program code. For general variables: When executing the command: include the following: if (rxstate == 0){
SetRx();
rxstate = 1;
}
setMhz(frequency); wherever setTx is set, put them In this way you prevent the module from being unnecessarily set to sidle mode. |
So it would be possible to call |
yes i will adjust it. the library will know and then just change the frequency. |
Was reviewing the CC1101 Datasheet and saw this on page 57, which would explain the behaviour I saw and show that my workaround of setting the receiver to idle was the right approach.
|
hi i have now released update 2.5.3. Everything has been tested and works without problems. You can now easily use SetRx (mhz); use. Whatever is in the data sheet. the reality is different. |
Tks very much, will test it tonight
… On Jan 22, 2021, at 3:11 PM, LSatan ***@***.***> wrote:
hi i have now released update 2.5.3. Everything has been tested and works without problems. You can now easily use SetRx (mhz); use. Whatever is in the data sheet. the reality is different.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
take a look at the frequency scanner. here the frequency is changed in rx mode for microseconds. it works perfectly! even without sidle! but here I used setMhz (freq). I made a test setup with the help of rc switch. to test the new version. a module as a transmitter. a button sends on 433mhz with SetTx (433.00); the other on SetTx (432.00) ;. The second module changes the frequency in the Rx if, for example, something was received on 433 MHz to 432 and vice versa. Here I only have SetRx (433); and SetRx (432); uses. All without problems. The change works great. the problem will be that setrx is set multiple times. but that has now been resolved.Give me feedback, I can also adjust things if necessary. |
I was testing this and am still able to recreate the issue. But at the same time I was successful with your example. What I found was that when making a small frequency change ~1 MHz worked, but with a large frequency change ( 303 to 315Mhz ) I was not able to receive a signal. I tested the following ( I have a 303.732 MHz and 315.026 Mhz remotes in my setup ) Complied OMG ( with idle/workaround removed and SmartRC-CC1101-Driver-Lib@2.5.3 ) with default frequency set to 302.732 MHz: 1 - Tried 303.732 Mhz Remote ( No signal, this was expected ) I think it is working after transmitting, as the oscillator is set to idle as part of transmitting. I also tried going from 303.732 MHz to 315.026 in 1 MHz steps and no luck either. I had thought about using channels, and that wouldn't work in my scenario as I'm going from 303Mhz to 433 MHz, which is beyond the maximum channel range. |
ok, please test the following cpp. if everything works out I will release a new version. Regards |
Two thumbs up with this version Thank you very much |
Tks very much Just tested the release build and everything works |
…from #847 (#851) Tks to @LSatan workaround no longer needed LSatan/SmartRC-CC1101-Driver-Lib#65
* Update to SmartRC-CC1101-Driver-Lib@^2.5.4 and removal of workaround from #847 Tks to @LSatan workaround no longer needed LSatan/SmartRC-CC1101-Driver-Lib#65 * Default to value as subject for rtl_433 and receiver switching * Default to not publishing unparsed signals * Fix for missing String for uint64_t * Fix is only required when value a subject is defined and not PiLight Co-authored-by: Northern Man <sgracey@Heisenberg.local>
* Update to SmartRC-CC1101-Driver-Lib@^2.5.4 and removal of workaround from 1technophile#847 Tks to @LSatan workaround no longer needed LSatan/SmartRC-CC1101-Driver-Lib#65 * Default to value as subject for rtl_433 and receiver switching * Default to not publishing unparsed signals * Fix for missing String for uint64_t * Fix is only required when value a subject is defined and not PiLight Co-authored-by: Northern Man <sgracey@Heisenberg.local>
While working on this Pull Request for OpenMqttGateway to add support for switching receive and transmit frequencies, found that when switching receive frequencies nothing would be received. But if you transmitted on the new receive frequency then signals were received. When I'm changing frequencies, I have been testing between 303 MHz and 315 MHz ( not sure if this matters ).
After reviewing the CC1101 data sheet and the differences between the receive and transmit flow deduced that setting the receiver idle as part of the frequency change was needed. Does this make sense?
The text was updated successfully, but these errors were encountered: