-
Notifications
You must be signed in to change notification settings - Fork 37
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
Decoded byte 5 is not always 0x0E on my Sparsnäs #6
Comments
I think that data_[4]^0x0f might be some kind of power calculation mode flag.
|
You seem to be onto something. but for me data_[4]^0x0f is always 2. |
I was actually using a cc1101 chip connected to a raspberry with some code I developed a couple of years back(not the rtl dongle), but now I've also double checked it with this code and the rtl-sdr and could verify that it changes accordingly to the power calculations modes. Maybe there are different versions of the sensor? If I remember correctly it also counts from 0-3 or was it 1-3 when the batteries are put in. |
Must have been the last part then. I got really wierd numbers and I had just changed batteries in the sender. Now after the device been on for a while it does work with your code. made a PR with this code. here: #7 |
Applied the PR #7 and made few changes and now I can listen to two Sparsnäs without any errors. Thanks. |
I had to apply the PR #7 to be able to find my Sparsnäs at all, with --find-frequencies |
Line 179:
if (data_[0] != 0x11 || data_[1] != (SENSOR_ID & 0xFF) || data_[3] != 0x07 || data_[4] != 0x0E || rcv_sensor_id != SENSOR_ID) {
data_[4] toggles seemingly randomly between 0x0D and 0x0E on my Sparsnäs, generating a lot of illegal packets. Perhaps it is a flag?
The text was updated successfully, but these errors were encountered: