Skip to content
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

Closed
NorthernMan54 opened this issue Jan 22, 2021 · 12 comments
Closed

Changing frequencies while receiving - Nothing Received #65

NorthernMan54 opened this issue Jan 22, 2021 · 12 comments

Comments

@NorthernMan54
Copy link

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?

@LSatan
Copy link
Owner

LSatan commented Jan 22, 2021

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.

@LSatan
Copy link
Owner

LSatan commented Jan 22, 2021

You could include the following in the program code.

For general variables:
bool rxstate = 0;

When executing the command:
{"value":1150,"protocol":6,"length":12,"delay":450,"repeat":8,"mhz":303.732}

include the following:

if (rxstate == 0){
SetRx();
rxstate = 1;
}
setMhz(frequency);

wherever setTx is set, put them rxstate = 0; .

In this way you prevent the module from being unnecessarily set to sidle mode.

@Legion2
Copy link

Legion2 commented Jan 22, 2021

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).

So it would be possible to call setRx(mhz) without knowing the current state of the CC1101 module?

@LSatan
Copy link
Owner

LSatan commented Jan 22, 2021

yes i will adjust it. the library will know and then just change the frequency.

@NorthernMan54
Copy link
Author

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.

If any frequency programming register is altered when the frequency synthesizer is running, the synthesizer may give an undesired response. Hence, the frequency programming should only be updated when the radio is in the IDLE state.

@LSatan
Copy link
Owner

LSatan commented Jan 22, 2021

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.

@NorthernMan54
Copy link
Author

NorthernMan54 commented Jan 22, 2021 via email

@LSatan
Copy link
Owner

LSatan commented Jan 22, 2021

#47 (comment)

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.

@NorthernMan54
Copy link
Author

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 )
2 - SetRx(303.732), and tried 303.732 Mhz Remote ( Signal, this was expected )
3 - SetRx(302.732), and tried 303.732 Mhz Remote ( No Signal, this was expected )
4 - SetRx(303.732), and tried 303.732 Mhz Remote ( Signal, this was expected )
5 - SetRx(315.026), and tried 315.026 Mhz Remote ( No Signal, Issue )
6 - SetRx(303.732), and tried 303.732 Mhz Remote ( Signal, this was expected )
7 - SetRx(315.026), and tried 315.026 Mhz Remote ( No Signal, Issue )
8 - SetTx(315.026), and transmitted a signal via CC1101 ( Signal was received by 315.026 Fan )
9 - Tried 315.026 Mhz Remote ( Signal, this was expected )
10 - SetRx(303.732), and tried 303.732 Mhz Remote ( No Signal, Issue )
11 - SetTx(303.732), and transmitted a signal via CC1101 ( Signal was received by 303.732 Fan )
12 - Tried 303.732 Mhz Remote ( 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.

@LSatan
Copy link
Owner

LSatan commented Jan 23, 2021

ok, please test the following cpp. if everything works out I will release a new version. Regards

test.zip

@NorthernMan54
Copy link
Author

Two thumbs up with this version

Thank you very much

@NorthernMan54
Copy link
Author

Tks very much

Just tested the release build and everything works

1technophile/OpenMQTTGateway#850

1technophile pushed a commit to 1technophile/OpenMQTTGateway that referenced this issue Jan 26, 2021
1technophile pushed a commit to 1technophile/OpenMQTTGateway that referenced this issue May 29, 2021
* 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>
h2zero pushed a commit to h2zero/OpenMQTTGateway that referenced this issue May 30, 2021
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants