[no_ticket] Bandwidth, Datarate and Macnhester Enable decoding configuration

[X-Stuff]

What's new

• [SubGhz]

  • [Receiver] Special preset AM* introduced. This preset allows to modify Bandwidth, Datarate and Macnhester decoding parameters of CC1101 chip. This PR also allows to get information about these fields from default (or other custom) modulation presets

• [unit_tests]

  • Minor improvement to unit_tests app - allows to set desired log level before running unit_tests

Abstract

Some transmitters may have non-standard transmission params. So in order to get pulses more accurate you might need to have options to adjust some CC1101 settings manually.

This PR also could be a basement for other configurable parameters of CC1101 chip editing.

Verification

• Open SubGHz App and enter read raw mode:
• Select modulation preset AM*

  Please note: default preset AM650 will show invalid Bandwidth, Datarate and Manchester decoding params because this preset was initialized with NULL as it CC1101's registers data

• Setup desired configuration and test it
• Recorded RAW file will contain CC1101 registers configuration according to your setup
• Loading this RAW file should setup exact configuration

  Please note: CUSTOM presets also allowed to be modified, so once you load your RAW file, you may change the advanced configuration of custom preset for RAW file

Checklist (For Reviewer)

• [ ] PR has description of feature/bug or link to Confluence/Jira task
• [ ] Description contains actions to verify feature/bugfix
• [ ] I've built this code, uploaded it to the device and verified feature/bugfix

[Skorpionm]

what is the real application of this refinement? Now such cc1101 settings are used, that for it it doesn’t matter what encoding, transmission rate, and so on, the signal goes. it displays the durations on the GO0 pin in real time. the inclusion of Manchester decoding directly in the chip itself leads to the fact that you need to fine-tune the reception, in particular, the preamble, synchronization words, bit rate, and so on.

[X-Stuff]

You're right. Manchester enc/dec setting is useless since chip is working in async serial mode ( datasheet 27.1 ) Datarate is not completely useless but likely never be changed. Modulator sample rate depends on it in TX mode.

However bandwidth finetuning might be useful.

Well, I'm not sure what could be the real application of these changes. The reason I made them - is just attempt to get correct readings from my car key, by finetuning anything. The problem is CC1101 is not SDR and we cannot just save just unmodulated signal to analyze it. So best you can try - change something, read data, analyze if it became better, repeat.

My problem was - captured pulses from single transmission (open button) were not the same. They look alike but still differs. So one click on button should emit 3 burst with same data. Since my car opens with that key, I've concluded this is not transmitter problem. Since the results .sub file is already demodulated pulses and they have some kind of error I've decided to try to configure every configurable MDM setting in CC1101 chip to check if it helps to reduce that error.

Well... long story short this didn't really help, and I've just decided to order an SDR dongle. What did really help - it's custom manchester encoded pulses normalization script written in python which does something like this: -70 250 -90 135 -85 110 ... --> -100 210 -100 110 -100 110 ... ( assuming target pulse width is 100 us ) But the initial idea was somehow change modem configuration of cc1101 in order to get these pulses already correct. There are also AGCCTRL registers that might affect RX and demodulation in AM mode, but I didn't really dive into datasheet about them yet...

And according to the changes in this review. I've created it just to share my work with you, if you might find it helpful. I can push changes which will remove from UI manchester and datarate setting, or you could decline the PR at all. It's all up to you.

[skotopes]

That is some very complex topic that you've picked up. In its current form this PR brings a lot of confusion on how things works in real life.

Yes, many registers in async mode don't do anything and there are some really tricky connections between analog domain configuration params.

Ping me on discord and we'll try to figure out if this PR can be transformed into something meaningful.

[timelf123]

What did really help - it's custom manchester encoded pulses normalization script written in python which does something like this: -70 250 -90 135 -85 110 ... --> -100 210 -100 110 -100 110 ... ( assuming target pulse width is 100 us )

Where can I find something like this

[skotopes]

I'm going to close this PR: idea is good, but implementation is incomplete.