search

LSatan / SmartRC-CC1101-Driver-Lib

This driver library can be used for many libraries that use a simple RF ASK module, with the advantages of the cc1101 module. It offers many direct setting options as in SmartRF Studio and calculates settings such as MHz directly.
Other
444 stars 99 forks source link

Confusing setGDO behaviour #79

Open dwarning opened 3 years ago

dwarning commented 3 years ago

Hello, we are using your superb library in a complex project with switching CC1101 between RX and TX: https://github.com/Rodemfr/MicronetToNMEA.

The teensy 3.6 board is used with his standard SPI interface and GDO0 connected to pin 24. GDO2 is not wired: gRfReceiver.setGDO(24, 25); // Practical, GDO2 pin isn't used. You don't need to wire it

In this configuration everything works fine. But if I set the second parameter of setGDO to 0 the transmission dies. Removing the entire command let the program work again.

So it is not really a bug, but a bit confusing. Can you enlight me please.

LSatan commented 3 years ago

hi, the set gdo function was changed to work with a different library. But I think I'll change it again. since it seems pointless to me to set the gdo2 as the exit. it should be an input. gdo2 does not have to be wired either. gdo0 can serve as input and output (rx / tx). for most of the examples here in the library, gdo0 serves as tx and gdo2 as rx. As I said, I will adjust it in the next update. Regards

dwarning commented 3 years ago

Thank you.

dwarning commented 3 years ago

Sorry - but I am still confused. In the new version we have a contradiction: void ELECHOUSE_CC1101::GDO_Set (void) { pinMode(GDO0, OUTPUT); pinMode(GDO2, INPUT); } but void ELECHOUSE_CC1101::GDO0_Set (void) { pinMode(GDO0, INPUT); } From datasheet I see GDO0 can be Input / Output and GDO2 can be only output. Maybe the question is stupid: Which pinMode is meant - the pinMode of the CC1101 or of the controller? I want generate an interrupt for the esp32 if the CC receives data. So I trigger on gdo0 pin which should be then an output of the CC.

LSatan commented 3 years ago

gdo0 can be input output. gdo2 is just output. this actually means the pins of the cc1101. for example: cc1101 gdo2 output -> input microcontroller. the option with set gdo0 gdo2 is suitable for serial transmission. set gdo0 for the internals with fifos. With the internal transmission functions, gdo0 is only set to 1 when something is received or sent so that the microcontroller knows when the transmission has ended.

dwarning commented 3 years ago

Yes, but you see in your code above pinMode(GDO2, INPUT);. I think this is wrong in any case. So if I want use GDO0 as input I have to use setGDO0(gdo0_pin). Did you check the examples? Look for cc1101_Receive_advanced.ino. With the new setGDO0() it is that to input. Correct? I think Simon Monk want that the LED of the esp is blinking in rx mode of the CC. If I want use it as output (in my case) I have to use setGDO(gdo0_pin, gdo2_pin). What should I give for gdo2 if I didn't use it? Thanks for the pin meaning clarification.

LSatan commented 3 years ago

input is correct for gdo2. it is for the asynchronous serial mode. that means the cc1101 does not process the signals but the microcontroller. there is gdo0 to send. microcontroller output -> cc1101 gdo0 input. gdo2 is to receive microcontroller input <- cc1101 gdo2 output. this can be used for example for rc switch. however, you use the internal transfer functions that means you only need gdo0. gdo0 is then an output on the cc1101 and must then be an input on the microcontroller. You don't even need to connect gdo2 or define it on the microcontroller. For the internal transmission functions, gdo0 must be defined for send and receive as an input on the microcontroller. the cc1101 does not output any data to the gdo0 but only a 1 signal for now something is being received and a 1 signal for sending is still running. setting the gdo pins in the lib applies to the microcontroller. the original bibliotehk by simon k is nowhere near as mature. I hope that I could explain it reasonably understandably.

LSatan commented 3 years ago

Look this for more Information:

https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/issues/31#issuecomment-624279213

dwarning commented 3 years ago

Hi,

we have to stay with the version 2.5.6:

A functional teensy - cc1100 combination (only gdo0 wired) works with old version 2.5.6 and following line

  gRfReceiver.setGDO(GDO0_PIN, GDO2_PIN); // Practicaly, GDO2 pin isn't used. You don't need to wire it

Using version 2.5.7 rx and tx operation disappear.

Am 02.08.21 um 18:26 schrieb LSatan:

input is correct for gdo2. it is for the asynchronous serial mode. that means the cc1101 does not process the signals but the microcontroller. there is gdo0 to send. microcontroller output -> cc1101 gdo0 input. gdo2 is to receive microcontroller input <- cc1101 gdo2 output. this can be used for example for rc switch. however, you use the internal transfer functions that means you only need gdo0. gdo0 is then an output on the cc1101 and must then be an input on the microcontroller. You don't even need to connect gdo2 or define it on the microcontroller. For the internal transmission functions, gdo0 must be defined for send and receive as an input on the microcontroller. the cc1101 does not output any data to the gdo0 but only a 1 signal for now something is being received and a 1 signal for sending is still running. setting the gdo pins in the lib applies to the microcontroller. the original bibliotehk by simon k is nowhere near as mature. I hope that I could explain it reasonably understandably.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/issues/79#issuecomment-891161255, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMWNTD2ZIRW6L7IIBYSBZLT23BLRANCNFSM5AHKTVLA.

LSatan commented 3 years ago

now I don't have Teensy there. i will test everything again and give you feedback.

dwarning commented 3 years ago

I think it has nothing todo with the controller - if you use an esp the gdo0 signal will dissappear too with the mentioned setGDO() command.

Am 03.08.2021 um 10:24 schrieb LSatan @.***>:

 now I don't have tensy there. i will test everything again and give you feedback.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

dwarning commented 3 years ago

gdo0 can be input output. gdo2 is just output. this actually means the pins of the cc1101. for example: cc1101 gdo2 output -> input microcontroller. the option with set gdo0 gdo2 is suitable for serial transmission. set gdo0 for the internals with fifos. With the internal transmission functions, gdo0 is only set to 1 when something is received or sent so that the microcontroller knows when the transmission has ended.

I think the problem is my (or our) misunderstanding of usage the setGDO function. In my opinion e.g. setGDO(14,17) will set pin 14 of the uC as input for GDO0 in the old version of SmartRC because of pinMode(14, input). In the actual version stands pinMode(14, output) and the interrupt can't asserted.

Also if not used: The initial reported problem with the old version was for GDO2 with pinMode(17, output). From CC1101 the GDO2 can be only output and so the uC pin 17 must be an input.

Did you made some progress with evaluation of this issue?

LSatan commented 3 years ago

well I tested everything again and it worked perfectly right away. Make sure you are using setGdo0 and not set gdo. as it is written in the new examples. You can ignore the normal set Gdo function. Regards

dwarning commented 3 years ago

I know that setGdo0() works because it is controller input.. But what make it for sense if the old setGdo() is available but not working anymore because you change input to output on controller side,

It would be consistent if both function set the pin to input as default. And you create a special set function in case GDO0 should be output on controller side what is possible according the CC1101 spec for the seldom used case in TX (page 63, ch 27.1).

E.g. setGdo0(pin, direction), where direction specified input/output.

Kind Regards.

Am 14.08.21 um 19:38 schrieb LSatan:

well I tested everything again and it worked perfectly right away. Make sure you are using setGdo0 and not set gdo. as it is written in the new examples. You can ignore the normal set Gdo function. Regards

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/issues/79#issuecomment-898935252, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMWNTEWX2R2X6TALLTFE4DT42SZBANCNFSM5AHKTVLA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.