Go Down

Topic: RCSwitch to receive Blueline power meter (Read 121 times) previous topic - next topic

bkenobi

Mar 21, 2015, 05:54 pm Last Edit: Mar 21, 2015, 05:55 pm by bkenobi
In short, I'm trying to convert the code that CapnBry provided into a RCSwitch based code so I can use the same Arduino to receive more than one RF signal.  I have written protocol4 based on the provided protocol3 and it receives sometimes, though I haven't figured out why sometimes and not others.  I was hoping for a review to see if I've done something silly.  I'm not currently decoding, I'm just trying to get the data reliably first.

For a basic understanding of the protocol, scruss has done an excellent job of documentation with the added input from others in this blog entry:
http://scruss.com/blog/tag/blueline/  (second post has best comments)

Basically, there is a string of OOK bits defined by 0.5ms high and 0.5ms low ('1' bit) or 1.0ms low ('0' bit).  There is a preamble of 8 bits (FE) and 25 high pulses thereafter representing 24 bits (32 total).  There are 3 repeats of the packet, but the 3rd is not always the same.  The 3rd packet is a repeat of the first 2 for 4 sets in a row.  The 5th instance contains temperature data and the 6th contains total power used.  Then, the sequence repeats.  There is a ~30 second delay between transmissions.

My new protocol seems to detect data, but reports only receiving 31 bits, only displays once every few minutes, and the data doesn't make sense.  After running for over 30 minutes, this is what the serial window shows:

Code: [Select]
Received 2115858335 / 31bit Protocol: 4
Received 2125327919 / 31bit Protocol: 4
Received 2127632114 / 31bit Protocol: 4
Received 2128418318 / 31bit Protocol: 4
Received 2127632114 / 31bit Protocol: 4
Received 2127131256 / 31bit Protocol: 4
Received 2128441979 / 31bit Protocol: 4
Received 2125296258 / 31bit Protocol: 4
Received 2116143184 / 31bit Protocol: 4
Received 2122673915 / 31bit Protocol: 4
Received 2125824227 / 31bit Protocol: 4
Received 2121397991 / 31bit Protocol: 4
Received 2121397991 / 31bit Protocol: 4
Received 2128418318 / 31bit Protocol: 4


Upon review, I have no idea what that data is since it doesn't match valid power monitor data (e.g., FE0D3EAB).  The preamble must be 'FE' but obviously the "decoded" data is '21'.  The data posts at approximately the same time as I see the LED flash when it posts, so I assumed that it must be the desired transmission.

I have attached the modified RCSwitch files that I'm using as well as CapnBry's library.

I posted a thread a few weeks back focused on just receiving data on a 433MHz superheterodyne module.  I didn't think it was focused on my goal, so I started a new topic.  Hopefully that won't offend anyone.   8)
http://forum.arduino.cc/index.php?topic=306240

bkenobi

#1
Mar 21, 2015, 07:55 pm Last Edit: Mar 21, 2015, 07:56 pm by bkenobi
I modified the sketch to output the time for each hi/lo pulse.  It shows pretty clearly that there is an issue with the received data.  It looks to me like the data starts to record before anything valid comes in.  The best data had gibberish for the first ~20 bits and then valid data.  But, the rest were mostly garbage.


bkenobi

I switched the Arduino Uno for a Nano since I plan on using that in the long run currently, but now nothing is received with Powermon433.  This leads me to believe that the method for interrupts being used by the code makes a big difference in functionality/performance.  RCSwitch uses the attachInterrupt method which provided the results in the OP.  When using Powermon433, valid data is seen nearly every time.  The primary difference is that Powermon433 uses ISR to trigger interrupts instead.

So, I'm thinking 2 things are happening.
  • The Uno and Nano must have interrupts set up differntly somehow even though they both use the same ATMEGA328P chip (though one is surface mount and the other DIP)
  • ISR seems to work better than attachInterrupt at least for this basic example.


My only thought currently is to try converting the RCSwitch library over to ISR functions and use the Uno for now.  Other thoughts from anyone who's traveled a similar road already?

bkenobi

#3
Mar 28, 2015, 06:55 am Last Edit: Mar 28, 2015, 07:43 am by bkenobi
I modified/simplified the Powermon433 code to it's most basic receiving core.  All the sketch includes is the interrupt code and a write of the pulse time to serial.  The result is that both the Uno and Nano output *some* data.  But, there is a significant difference between the two.  The Uno shows 3 primary times of interest (500, 1000, 1500us which are defined by Powermon433 as the pulses we are looking for).  But, the Nano shows no really useful pulse length trends (900, 1900, 2900, 3900).  Attached are the raw times and plots for visualization.  I think this pretty clearly shows there's an issue with the Nano for some reason.

bkenobi

Although it appears noone is reading this thread, I'm going to continue for the time being just in case someone new comes across it and takes pitty on me.   ;)


I've continued tinkering and googling and have come up with a new approach that still uses RCSwitch, but it uses more of a finite state machine approach.  I found a fork of ookdecoder that splits each protocol into a different .h file making it easier to add new devices potentially.  The problem is, I can't get it to output anything.   :smiley-eek:

https://github.com/Cactusbone/ookDecoder

I think the primary issue is just setting up the hardware.  It appears that the code is setup for either JeeNode or Uno.  I'm using Uno, so it appears I should connect the data pin to interrupt 1 which is digital pin 3.  I've tried pin 2, pin 3, analog pin 1 (the author used that with his JeeNodes module) and nothing seems to produce results.  I MUST be missing something, but I haven't figured it out yet.  I'll keep banging my head at it, but if anyone has a shortcut for me, I'd love to hear it.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy