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

Decoded byte 5 is not always 0x0E on my Sparsnäs #6

Open
Kiwawa opened this issue Dec 30, 2017 · 6 comments
Open

Decoded byte 5 is not always 0x0E on my Sparsnäs #6

Kiwawa opened this issue Dec 30, 2017 · 6 comments

Comments

@Kiwawa
Copy link

Kiwawa commented Dec 30, 2017

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?

@saterdal
Copy link

saterdal commented Jan 3, 2018

I think that data_[4]^0x0f might be some kind of power calculation mode flag.

if(data_[4]^0x0f == 1) power = (float)((3600000 / P_P_KWH) * 1024) / (power_raw); if(data_[4]^0x0f == 2) power = power_raw * 24;

@JohanLeirnes
Copy link

You seem to be onto something. but for me data_[4]^0x0f is always 2.
at some powerrates the power_raw * 24 matches the reported power from the display. And at certain powerrates the "(float)((3600000 / P_P_KWH) * 1024) / (power_raw)" seems to be correct.

@saterdal
Copy link

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.

@JohanLeirnes
Copy link

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

@vincic
Copy link

vincic commented Apr 13, 2018

Applied the PR #7 and made few changes and now I can listen to two Sparsnäs without any errors. Thanks.

@lobbin
Copy link

lobbin commented May 4, 2018

I had to apply the PR #7 to be able to find my Sparsnäs at all, with --find-frequencies

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

5 participants