Filetype: Flipper SubGhz RAW File
Frequency: 433920000 ==> Frequency in Hz
Preset: FuriHalSubGhzPresetOok270Async ==> modulation and deviation settings. Here OOK with 270KHz RX filter bandwitdh
Protocol: RAW ==> un-decoded file containing duration of pulses in µs
RAW_Data: -1038 487 -1044 511 -1010 1011 [remaining pulses omitted, 512 pulses are present for each line…]
RAW_Data: -1044 517 -1010 517 -521 [remaining pulses omitted, 512 pulses are present for each line…]
In the above file, we can see:
- some low pulses (negative duration) and high pulses (positive duration)
- low (negative) pulses: 521µs or 1038µs, 1044µs, 1010µs
- high (positive) pulses: 487µs, 511µs, 517µs, 1011µs
- all pulses are either around 500µs or 1000µs, so the minimum pulse width is 500µs, which equals to a 2000 bits/s data rate
So the data converted to a binary stream with a minimum bit length of 500µs (data rate= 2000 bits/s) is:
but creating big files, combining multiple lines and playing around with timing you can trick a lot of devices who can process data a lot faster, so you can often turn 5 minutes into 1,5-2 minutes and it will still trigger with stupid devices. You can take out 10-30% of time on most devices and they do not even notice you are a bit more enthusiastic then an average remote. Also fuzzing a couple of specific bits makes it nice to create annoying files that are really fast.
The key is just hex/bin over time with amount of bits?
The - values/pause bits or 0’s and high values for 1 for example in AM OOK/ASK , its how you define the 0-1 or *2 in fm/fsk options for example ,compatible to the modulation type where am/ask/ook is more like a rough “beat counter” versus checking differences in amplitude or comparing multiple of them in the signal.
Also why stupid AM ask/ook devices are not to picky about the signal or waveform and “close enough” usually works, where in other modulation types you have a bit more logic in being sure on what is being transmitted and getting rid of noise more easy.
so even if the key is a bit more then the single 30 bits, and the remote transmits the same thing in repetitions, you could capture, 1,5 or 3 times the data in binraw where you just got a bit more but since the modulation type and receiver just recognize something that looks sorta familiar, so good enough,so even if you got some extra data, if the needed key is in there even if it is only a part of the signal you transmit , especially for AM ASK/OOK applications, having a couple of bits less or more here and there are ignored more easy to prevent interference problems, so if the needed sequence is somewhere in-between, it is also fine.
But bin-raw is actual binary converted to hex, i think? but the read raw function where you get the entire waveform, you get the multiple options , where it is just modulated/demodulated but not decoded, so you can get a lot of extra data with it not 100% relevant to what you expect to capture. and if you have the modulation specifics you do not need the difference in time high or low pulses, cause you expect default modulation specs so you usually get a different result in data without filtering.
So sorting out raw captures, visualizing them and interpreting them as audio files makes it somewhat more easy to see differences. At least for AM ASK/OOK , then you can just count peak’s where in other modulation types it becomes a bit more specific but for this is should give some clarity.
But in brute-forcing stupid devices, after the preamble some keep listing for seconds to get a valid command, and if you lets say for example, brute-force the entire 16bit keyspace after it in seconds, a lot cheap devices fall for stupid stuff like this , so you could reduce time to trigger all max annoyance in files to a fraction of the size and time for tons of devices.
Sorry if i am rambling trash, i should not reply as much when not being sober