flipperzero-firmware
flipperzero-firmware copied to clipboard
flipperdevices
Frequency Analyzer Request: Computed deviation value
Description of the feature you're suggesting.
Since the transceiver is configured with deviation, it would be nice if the frequency analyzer could also tell this to you. It seems many people are downloading the raw bin and using an external desktop utility to determine this, but it sounds like it would be relatively easy to compute.
Anything else?
No response
cc1101 is not SDR. it can only receive and decode a signal with pre-entered frequency and deviation values, rather than calculate them
I'm pretty sure I've seen videos online where the captured raw signal from the Flipper Zero is analyzed on desktop software to determine the deviation, and that inspired this feature request. If this can be done, it's not clear (to me) why any shortcoming in the radio could be responsible for it not being possible.
Let's look at these "videos" together. Carrier detection works as simply determining rssi at the current frequency, the minimum possible bw for this modem is 5 kHz, while this is a bandpass filter and it simply attenuates other frequencies not at this frequency, and does not completely block them. that is, in any case, it is not possible to scan the frequency range in less than 5 kHz increments. then switching the frequency takes about 3 ms and about 2 ms is determined by rssi, this is indecently long and in fact you can end up at that moment the transmitter was transmitting only 0 and the second frequency was missing. and many more restrictions...
I don't understand this response. If you record raw on a specific frequency, and then subsequently playback and the captured raw signal was sufficient to trigger the receiving device (the replay worked), why wouldn't the same captured raw data be sufficient to derive the deviation?
Also, don't assume I know what I'm talking about. =/ Good chance I don't. Feel free to point me to docs.
This is where the nuance is hidden, already demodulated data is recorded and reproduced, with a certain modulation, at a certain frequency, bit rate and deviation. not iq
If that's what Read Raw does, then why can't Read pick up the actual demodulated signal? I thought the difference between Read and Read Raw was that Read Raw doesn't demodulate? What is the meaning of "Raw" in that context? And how can I get a signal that I can clearly see in Read Raw, to be available under Read? I figured the answer to that question was to figure out how it was in fact modulated and to add that as a custom modulation. To that extent, I believe from the FCC data sheet, and the RTL433 project that it's using PWM FSK.
both ReadRaw and Read both demodulate the signal, with the selected frequency, modulation, bit rate and deviation (if the modulation is FSK), but Read tries to decode the received data using protocols that the flipper knows, and ReadRaw, just like the recorder records it
That's a great explanation. The obvious question would be then from the user's perspective that wants to learn and give back, how do they know if their work should be with demodulation or the protocol?
- If demodulation fails, what does that look like? Modulation can be picked from a list through the UI, and extended through custom modulations in the firmware. How can I be sure modulation is successful (that the one I picked is working), all I know for sure is that it's 313.85 mhz FSK (datasheet). It doesn't say if it's FM{15k, 95, 476, 238}?
- If demodulation succeeds, but the Flipper Zero isn't protocol aware, what does that look like?
Given my use case, the RTL_443 project implements the protocol as and calls it "FSK 8 byte Manchester encoded TPMS with CRC8 checksum." Since the Read menu doesn't identify the signal for me for me, and I can see the signal, do I assume modulation is successful and merely check that there is a valid implementation of that somewhere in subghz/protocols? Are they all tried?
And lastly, but related,
- Assuming the protocol isn't known but the demodulation is successful, is there not a way to see the encoded packets, or a hexdump of the signal on the Flipper itself?
- If the only difference between Read, and Raw Read is signal decoding, and if Raw Read can otherwise replay the signal, then why can't Read itself capture the signal -- as it does other signals -- and just make it visible to the user as "unable to decode", or the like?
(side note: I'm not sure of the audience but perhaps Read/Raw Read, would be better as "Demodulate", "Decode"?)
a lot of questions. which are completely unrelated to the current issues. read the docs, look at what binRaw is (exactly what you are asking for), TPMS will not demodulate correctly on standard presets, since this protocol has a high bit rate. it requires a custom preset. If there are no more questions regarding an open issue, please close it