CC IAMs not being received.

[andygodber]

I Thought Id had a problem with range/location of my Nanode vs IAMs, as not all data was being received.
However, I now believe Im not receiving ANY data from CC IAMs, but EDF IAMs ok, as are CC Optismart and Clamps.

[JackKelly]

My hunch would be that this is a tuning issue (and hence probably not something that can be fixed in code but rather something that requires some tinkering with the aerial). I think the CC IAMs are especially sloppy in their RF tuning. But I'll experiment with my single CC IAM when I get a chance.

To be honest, if you want to receive data from CC IAMs then it's probably best to use an EnviR. The aim of my code is to handle an arbitrary number of EDF IAMs and a small number (say 0-3) CC whole-house TXs. I'm not using any CC IAMs in my setup (because of the RF collision issue). (EDF IAMs use a fundamentally different (and much more reliable) RF protocol to the CC IAMs).

[andygodber]

"My hunch would be that this is a tuning issue (and hence probably not something that can be fixed in code but rather something that requires some tinkering with the aerial). I think the CC IAMs are especially sloppy in their RF tuning"

...acknowledged, but query success of the CC Optismarts and Clamps - are you saying the actual IAM themselves are that bad? Ive got one that is 1 metre away from the Nanode; I would have expected something that close to be detected?

[JackKelly]

I don't know a huge amount amount the CC IAMs I'm afraid (and I'm afraid I'm unlikely to find much new info about the CC IAMs because I'm not using any IAMs in my setup). My comment above literally is just a hunch based on some brief tinkering I did when I had 30 IAMs. My recommendation would be to use an EnviR or fork the code and try to get it to perform better with CC IAMs.

Unfortunately my focus must be on building a logging system which fits the requirements of my PhD so I'm afraid I can't spend much time on features which aren't related to my PhD, I'm sorry (ultimately I'm funded by Imperial to do academic research and this data logging work, whilst absolutely necessary to get my research done, isn't the core of my research).

[andygodber]

Understood.

As we’ve discussed, Im keen to get my whole house monitored as well – the EnviR impose a maximum number of devices (which can be overcome by installing more, of course, but is unwieldly), and your research provides a neat way to overcome that.

If you do get time to test with your CC IAM that would be great, if not, let me know if you’ve got a cheap source for EDF IAMs!

From: Jack Kelly [mailto:notifications@github.com]
Sent: 12 October 2012 11:00
To: JackKelly/rfm_edf_ecomanager
Cc: Andy Godber
Subject: Re: [rfm_edf_ecomanager] CC IAMs not being received. (#13)

I don't know a huge amount amount the CC IAMs I'm afraid (and I'm afraid I'm unlikely to find much new info about the CC IAMs because I'm not using any IAMs in my setup). My comment above literally is just a hunch based on some brief tinkering I did when I had 30 IAMs. My recommendation would be to use an EnviR or fork the code and try to get it to perform better with CC IAMs.

Unfortunately my focus must be on building a logging system which fits the requirements of my PhD so I'm afraid I can't spend much time on features which aren't related to my PhD, I'm sorry (ultimately I'm funded by Imperial to do academic research and this data logging work, whilst absolutely necessary to get my research done, isn't the core of my research).

—
Reply to this email directly or view it on GitHub #13 (comment) .

https://github.com/notifications/beacon/J6T91GIPIyhU-8ti4GCGP3zHdpiKx6GZ9tnUE3HBSwcHMjfU-QT3lMWQSMn78fAr.gif

[JackKelly]

Just to confirm: are CC IAMs never received; or are they just received less frequently than you'd expect?

[JackKelly]

Also, please can you describe your aerial setup? Are you using, for example, a quarter wave whip with ground plain? (as I'm sure you know, the aerial needs to be carefully measured and the ground plain is important if using a quarter wave whip)

[andygodber]

Confirming IAMs never received. I may want to qualify that - there are some 'random' UIDs received over the course of several hours observation of the output. However, the Watts output (s0) is never what I know the load to be, so Im anticipating these random ones could be a) neighbours (unlikely due to distance to their houses) or b) 'interference' or c) other things transmitting in the frequency, such as other EMON Tx's.

The aerial is a single core quarter wave, being 'about' 160mm, directly attached to a Nanode 5 on a breakout board.

[andygodber]

(closed by accident)

[JackKelly]

Thanks for the details.

Are you using the latest code? I haven't done anything today that should affect RF performance but the latest code gives you much more control over the verbosity of the output. The default is to display all valid packets. If you fire up the code send a single character 'b' to the code then it'll display all received packets, including "broken" packets (ones where the de-manchesterisation failed). I'm working on the wiki now to start making a user manual.

Also, I'd highly recommend using an aerial trimmed as accurately as possible and, even more importantly, a ground plain (I just put my Nanode on top of the box for my PC which should act as a ground plain given that the Nanode is powered from the PC!)

[andygodber]

I'll try better aerial management tomorrow, latest code now seems to not report EDF IAMs - trace attached for both old and new releases - do I need to 'enable' / pair the EDF in the latest code?

VERSION 6EB*****
0 INFO: EDF EcoManager Receiver
0 INFO: Starting rf12_initialize_edf()
2000 INFO: RFM12b finished power-up reset. Starting init...
2001 INFO: attaching interrupt
2503 INFO: Next expected CC_TX has ID=895, ETA=4294967295
2504 INFO: Finished init
3567 INFO: Unknown CC_TX ID:
3568 {id: 1506, t: 3536, s2: 18082} <---------unknown
6000 INFO: Polling CC TRX 1427111939
6081 {id: 1427111939, t: 6059, s0: 8} <------------ EDF IAM (correct, low 8 watts)
8029 INFO: Unknown CC_TX ID:
8029 {id: 3289, t: 7998, s0: 0} <------------------- CC Optismart PV (correct 0 8 Watts on solar PV)
9010 INFO: Unknown CC_TX ID:
9011 {id: 3386, t: 8979, s0: 4436} <--------------- CC Optismart whole house (correct Watts)
12000 INFO: Polling CC TRX 1427111939
12080 {id: 1427111939, t: 12057, s0: 7}
14453 INFO: Unknown CC_TX ID:
14453 {id: 3386, t: 14422, s0: 4425}
18000 INFO: Polling CC TRX 1427111939
18081 {id: 1427111939, t: 18059, s0: 7}
19303 INFO: Unknown CC_TX ID:
19303 {id: 2196, t: 19272, s2: 32453} <---------------unknown, unrecognisable S2

VERSION 4122**** <------ no EDF's
ACK print all
{id: 3386, t: 4075, s0: 1872} <-------- good
{id: 3289, t: 7329, s0: 0} <------- good
{id: 3386, t: 9611, s0: 1853}
{id: 2196, t: 12967, s2: 32518} <------- unknown
C FF 80 0 0 0 0 0
{id: 3386, t: 20558, s0: 1913}
{id: 3289, t: 24179, s0: 0}
{id: 3386, t: 26032, s0: 2071}
{id: 3386, t: 31506, s0: 1900}
{id: 3289, t: 35454, s0: 0}
{id: 3386, t: 37042, s0: 1806}
{id: 2196, t: 41093, s2: 32523}
{id: 1506, t: 42546, s2: 18386}
{id: 3289, t: 46731, s0: 0}
{id: 3386, t: 48019, s0: 1862}
{id: 3289, t: 52304, s0: 0}

[JackKelly]

Great! (It's quite exciting seeing the code running on someone else's system!)

Yes, you're right, you'll need to pair the system with your EDF IAM in order for the system to poll your EDF IAMs. Details on our brand-spanking new user manual (!): https://github.com/JackKelly/rfm_edf_ecomanager/wiki

[JackKelly]

My suggestion described in Issue #19 is a possible fix for this issue (i used a separate issue because that's a very specific thing to try which may or may not be related to receiving cc IAMs.

[JackKelly]

Hi Andy,

I've done some tinkering.

First off, the good news: you reported getting some crazy readings like "19303 {id: 2196, t: 19272, s2: 32453} (unrecognisable S2)". It turns out my de-manchesterisation code wasn't doing a great job of spotting dud packets. It should now do a better job of spotting dud packets and hence crazy readings should be very unlikely.

I have also spent a while tinkering with aerials. Preliminary results suggest that a quarter-wave whip with a ground plane does better than without a ground plane. I plan to tinker with a half-wave aerial too. Details at issue #33

I've also tried to get my code to hear CC IAMs but I can't and I've run out of ideas! Here are the things I've tried:

• changing the RF frequency from 433.97MHz (default for EDF EcoManager) to 433.90 MHz (default for EnviR). This just results in absolutely no packets being received from any sensors. I have however found that CC TXs like a slightly different freq to CC TRXs so I've modified my code to switch freq depending on which type of receiver it's expecting.
• expanding the afc frequency offset range from +3/-4 (default on EcoManager) to +15/-16 (default on EnviR). This doesn't appear to change things much. Looking at the status word from the RFM12b, it looks like the offset is only ever set about +3/-3 away from the centre freq.
• decreasing the data quality detector threshold from from 4 to 2. This appears to be beneficial all-round so I'm sticking with this setting.

The only thing I can suggest is trying to figure out exactly what frequency the CC IAMs transmit at (using something like a good radio scanner) and then maybe we can figure out what's going on. I am going to give up on trying to get my code to hear CC IAMs now (I'm afraid I don't plan to use CC IAMs in my setup so can't justify spending a huge amount of time trying to get this to work.)

[andygodber]

Thanks for the updates and continued hard work Jack.

Im out of the country at the moment, so no chance to test yet.

Before i left, i did get chance to play with a Software Defined Radio as suggested by one of the other blog readers - i could see stuff in 433 and 868 bands, so may indeed be a good way to detect exact freqs of CC IAMS - will update on my return.

Date: Fri, 26 Oct 2012 09:56:21 -0700
From: notifications@github.com
To: rfm_edf_ecomanager@noreply.github.com
CC: andy_godber@hotmail.com
Subject: Re: [rfm_edf_ecomanager] CC IAMs not being received. (#13)

Hi Andy,

I've done some tinkering.

First off, the good news: you reported getting some crazy readings like "19303 {id: 2196, t: 19272, s2: 32453} (unrecognisable S2)". It turns out my de-manchesterisation code wasn't doing a great job of spotting dud packets. It should now do a better job of spotting dud packets and hence crazy readings should be very unlikely.

I have also spent a while tinkering with aerials. Preliminary results suggest that a quarter-wave whip with a ground plane does better than without a ground plane. I plan to tinker with a half-wave aerial too. Details at issue #33

I've also tried to get my code to hear CC IAMs but I can't and I've run out of ideas! Here are the things I've tried:

changing the RF frequency from 433.97MHz (default for EDF EcoManager) to 433.90 MHz (default for EnviR). This just results in absolutely no packets being received from any sensors. I have however found that CC TXs like a slightly different freq to CC TRXs so I've modified my code to switch freq depending on which type of receiver it's expecting.

expanding the afc frequency offset range from +3/-4 (default on EcoManager) to +15/-16 (default on EnviR). This doesn't appear to change things much. Looking at the status word from the RFM12b, it looks like the offset is only ever set about +3/-3 away from the centre freq.

decreasing the data quality detector threshold from from 4 to 2. This appears to be beneficial all-round so I'm sticking with this setting.

The only thing I can suggest is trying to figure out exactly what frequency the CC IAMs transmit at (using something like a good radio scanner) and then maybe we can figure out what's going on. I am going to give up on trying to get my code to hear CC IAMs now (I'm afraid I don't plan to use CC IAMs in my setup so can't justify spending a huge amount of time trying to get this to work.)

          —

          Reply to this email directly or view it on GitHub.

[andygodber]

Some potentially good news - CC IAMs working.
On my return from holidays, I had a nice new Nanode Gateway waiting for me. http://www.nanode.eu/news/new-product-announcement-the-nanode-gateway/

As a quick test, I loaded up the latest of Jack's sketches - amazingly, I saw a lot more devices being reported than previously - on closer inspection, these seemed to be my CC IAMs.

I loaded up the code on my old Nanode5, and the same results obtained - so good work Jack, looks like this resolved as well.

I'll do some proper testing over the next few days to confirm.

[JackKelly]

Thanks loads for the update, Andy. I must admit I'm pleasantly surprised that the code can receive packets from your CC IAMs. Even the most recent code doesn't manage to receive packets from my single CC IAM (but I suppose there's a slim chance that my CC IAM is broken!).

[infoGenius]

Hi Jack

I don't know if you still keep up on this project but I have now managed to successfully receive from several CC iAMS, a few CC whole house clamps and GasSmart.

Cheers for all the work you put in to this

Mark

[JackKelly]

That's great news, thanks for the update!
On 14 Feb 2014 20:18, "infoGenius" notifications@github.com wrote:

Hi Jack

I don't know if you still keep up on this project but I have now managed
to successfully receive from several CC iAMS, a few CC whole house clamps
and GasSmart.

Cheers for all the work you put in to this

Mark

Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-35120755
.