-
Notifications
You must be signed in to change notification settings - Fork 12
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
Device ID = 0x0000 Problem #2
Comments
Well that does make sense then, that there are 4 types of packets that are indicated in that byte. I don't have my test setup any longer, but it would be in data[0] correct? So the new code would look like this (OOK_PACKET_TXID is 0):
|
Thanks for the reply (and the great code), Bryan.
Yes, the low order two bits for data[0] would be '00' and every power/temp frame would have a valid CRC,
when the Tx ID was zero.
I guess I'm a bit late to this game, but with recent electricity rates so high in Ontario, Canada, I thought I'd try to document
what I find/do in case others jump in - via GitHub, if possible.
Next step: To port your code to the Adafruit Feather M0 433 - it's so compact and has the RFM69 built-in.
Just a few pin changes, I hope.
Thanks again
Steve
From: Bryan Mayland [mailto:notifications@github.com]
Sent: May 24, 2017 7:09 AM
To: CapnBry/Powermon433 <Powermon433@noreply.github.com>
Cc: wolfer649 <steve.fowler@rogers.com>; Author <author@noreply.github.com>
Subject: Re: [CapnBry/Powermon433] Device ID = 0x0000 Problem (#2)
Well that does make sense then, that there are 4 types of packets that are indicated in that byte. I don't have my test setup any longer, but it would be in data[0] correct? So the new code would look like this (OOK_PACKET_TXID is 0):
if (g_DiscoverPeriod &&
(decoder.data.raw[0] & 3) == OOK_PACKET_TXID &&
crc8(decoder.data.raw, 3) == 0)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#2 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/Aa5lAlXVVKuu-FDtbXs6TtSkSs_Zbclyks5r9A-vgaJpZM4NkTSm> .
|
Great! Changes pushed to github for the TXID packet type thing, but I am not sure how to validate the CRC if it is saying all the packets pass due to it being 0. It should be able to just run directly on the Adafruit, it is just SPI bus and I believe the !CS line is the standard. You'll just need to bring out that OOK data line, which no off-the-shelf module has attached. Good luck with your build, I recently switched from using this to getting an EmonTx because I got a solar system so there was no way to tell how much was being used by the house if just measuring at the meter. Hydro is crazy expensive in Ontario. My friend out in Bourget pays over $100 just for service out at her farm and then time of use power at peak time is like costing a loonie just to microwave a cup of tea! |
I guess, if the CRC is OK and the LSB lower two-bits are not zero, then the frame could be passed on as OK
for decoding, since the ID subtraction should work - I think. (TBD)
Since the Adafruit Feather M0 uses a Cortex M0 processor, the AVR "atomic.h" doesn't apply.
Aside from the pin changes (Digital 8 is hardwired to the RFM NSS on the Feather M0, so Digital 10 could connect to RFM DIO2)
there are some differences in interrupt processing between the Arduino Uno and Feather M0 (TBD again.)
Though I can only work on this very occassionally, I'll let you know when/if the port to the Feather M0 433 is done.
P.S. I just heard that in Northern Ontario (the frozen few) pay almost $400 per month for lecky. Yikes!
From: Bryan Mayland [mailto:notifications@github.com]
Sent: May 24, 2017 5:52 PM
To: CapnBry/Powermon433 <Powermon433@noreply.github.com>
Cc: wolfer649 <steve.fowler@rogers.com>; Author <author@noreply.github.com>
Subject: Re: [CapnBry/Powermon433] Device ID = 0x0000 Problem (#2)
Great! Changes pushed to github for the TXID packet type thing, but I am not sure how to validate the CRC if it is saying all the packets pass due to it being 0.
It should be able to just run directly on the Adafruit, it is just SPI bus and I believe the !CS line is the standard. You'll just need to bring out that OOK data line, which no off-the-shelf module has attached. Good luck with your build, I recently switched from using this to getting an EmonTx because I got a solar system so there was no way to tell how much was being used by the house if just measuring at the meter.
Hydro is crazy expensive in Ontario. My friend out in Bourget pays over $100 just for service out at her farm and then time of use power at peak time is like costing a loonie just to microwave a cup of tea!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#2 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/Aa5lAlzXo-ppb8JIjIzrq61r2RSoDyPTks5r9KZ1gaJpZM4NkTSm> .
|
Oh my bad I didn't realized you said a Feather M0. Yeah that's a whole different ball of wax when it comes to timing pulses. Good luck! |
It turns out that if the Device ID = 0x0000, every frame is treated as an ID frame because the CRC is good for all of them. In fact, a valid ID frame also has '00" for the low order two bits of the LSB.
(My March, 2017 Blueline sensor's out-of-box Device ID was 0x0000, naturally.)
The easy workaround is to hold the sensor's reset button for 10-ish seconds to force it to assume a new ID.
The text was updated successfully, but these errors were encountered: