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

set_modem_config 4 changes applied and 2 failed #12

Closed
wurst44 opened this issue Aug 29, 2021 · 6 comments
Closed

set_modem_config 4 changes applied and 2 failed #12

wurst44 opened this issue Aug 29, 2021 · 6 comments

Comments

@wurst44
Copy link

wurst44 commented Aug 29, 2021

Hi, when I try to set the modem config for an ESP32 (az-delivery-devkit-v4) + CC1101 (2 different models) it does not set them all:

RFQuack(/dev/ttyUSB1)> q.radioA.set_modem_config(
                  ...: ^Imodulation="OOK",
                  ...: ^IcarrierFreq=433.92,
                  ...: ^IbitRate=3.41296,
                  ...: ^IuseCRC=False,
                  ...: ^IsyncWords=b"",
                  ...: ^IrxBandwidth=58)
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO modulation = OOK
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO carrierFreq = 433.92
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO bitRate = 3.41296
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO useCRC = False
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO syncWords = b''
2021-08-29 22:52:57 efafcdc64da0 rfquack.core[1] INFO rxBandwidth = 58
2021-08-29 22:52:57 efafcdc64da0 rfquack.transport[1] DEBUG b'RFQUACK/in/set/radioA/rfquack_ModemConfig/set_modem_config' (21 bytes)
2021-08-29 22:52:57 efafcdc64da0 rfquack.transport[1] DEBUG Writing packet = b'>RFQUACK/in/set/radioA/rfquack_ModemConfig/set_modem_config~DcP12EMiADgBQABN8G1aQFUAAGhC\x00'

RFQuack(/dev/ttyUSB1)> 2021-08-29 22:52:57 efafcdc64da0 rfquack.transport[1] DEBUG 44 bytes received on topic: "b'RFQUACK/out/set/radioA/rfquack_CmdReply/set_modem_config'" = "b'08ffffffffffffffffff01121f34206368616e676573206170706c69656420616e642032206661696c65642e'"
2021-08-29 22:52:57 efafcdc64da0 rfquack.transport[1] DEBUG Message from module "b'radioA'"

result = -1
message = 4 changes applied and 2 failed.

it seems when I do not set frequency and modulation it throws no error.

I also had to add a stub in RFQCC1101.h or else it throws "not implementet" during startup:

    int16_t setFrequencyDeviation(float freqDev) override {
      freqDev = CC1101::setFrequencyDeviation(freqDev);
      return ERR_NONE;
    }

Pls help, thank you.

@barsuna
Copy link

barsuna commented Sep 4, 2021

I had similar issue (also with esp32 + cc1101), the 2 parameters that failed were modulation and frequency.

In the same vein like you did for frequency deviation i have also added a wrapper function for the frequency (in my case i put them into RFQCC1101.h file (since this is where the rest of the similar wrappers were)

int16_t setFrequency(float carrierFreq) override {
    return CC1101::setFrequency(carrierFreq);
}

The modulation is a weird one - i didn't quite get to the root of it, but it seems that it is a wrongly defined GPB or something like that... because setting modulation to FSK actually works, just OOK doesn't work. Also in the guessing module there is a code that explicitly sets OOK and it works. So it is just not working via command - it calls setModulation with wrong argument

One can make a crude fix by changing setModulation in RFQCC1101 to something like below

int16_t setModulation(rfquack_Modulation modulation) override {
  if (modulation == rfquack_Modulation_FSK2) {
    return CC1101::setOOK(false);
  }
  return CC1101::setOOK(true);
}

This will always set OOK unless FSK is specified... Hopefully someone who understands better how commands are processed can make proper fix to this.

As a workaround - one can start a guessing module with q.guessing.start() - it changes modulation to OOK.

Yet another option is to set the register 0x12 directly, but it takes away from the spirit of abstracting some of the radio chip programming away :)

It is cool project, kudos to the authors, i'm hoping to return to it on the next rainy weekend :)

@wurst44
Copy link
Author

wurst44 commented Sep 5, 2021

Wow, thank you very much. I will have a look at that. I hope the authors will find some time to improve the features of this awesome project 😊

@phretor
Copy link
Contributor

phretor commented Sep 6, 2021

Thanks for the encouraging words @wurst44 and @barsuna! Unluckily, my time is extremely limited.

Check #2 out: this long (now closed) issue has many insights on how to debug cases like yours.

@wurst44
Copy link
Author

wurst44 commented Sep 21, 2021

Very tricky setup. I am receiving a lot of noise in RX mode. I do not get any results with the guessing module.
I gave up, but I got very nice results using EvilCrowRF ❤️

@barsuna
Copy link

barsuna commented Oct 1, 2021

Yeps. What attracted me in RFQ was this abstraction of hardware + iPython - one has a lot of control and flexibiliy: can poke stuff into the registers when needed. Crow has UI which is useful in portable setting, but it doesn't allow same flexibility as RFQ.

So far however, i have most success with URH + rtl-sdr :) I ventured into HW-based radios with the hope to save some time figuring out the modulation, take advantage of HW filters and circuitry to decode noisy stuff etc, but so far i've just found it is simple different set of challenges (isn't it always?).

Still there is something to this RFQ notion of fast loop and slow loop working together - i like this concept much. To @wurst44 point, i hope perhaps its possible to add RSSI based filtering to the fast-loop - i have to agree there is quite a bit of noise (with liberal radio settings at least - especially with no preamble or syncWord etc) - it would be good to be able to set ceiling for how weak a signal we would want to accept... i'm still not at the level to be able to add this myself yet...

@phretor
Copy link
Contributor

phretor commented Aug 27, 2022

This is a nice discussion, especially from @barsuna about advantage of the HW/SW modularity of RFQ compared with others.

I'm going to close this issue as there seems not much to be resolved. There is some activity in the Discussions section as well as in the project's Slack.

@phretor phretor closed this as completed Aug 27, 2022
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