Archived Forum

Corrupted radio transmission. I get them all the time. Some radios perform better than others. I had to stop using my RM69PI as the node IDs were corrupted more often than not.

Thanks but...

I do not understand: is the radio tx disturbed?

What shall I do ? Better dongle? diiferent router position?

I hope you did not mean you cannot use  the emonpi...

tx

Tell us more - what makes up your system? We cannot read your mind. So far, all we know is you have an emonPi (and you did not say that in your first post, so Bra1n was only guessing when he replied).

@Dvbit,

Some trace logs are needed to get further with your issue. This thread  has instructions on grabbing the data.

You are right sorry. I am going to grab some traces

emonhub.log does not show any reference to other nodes...

2015-10-25 12:53:51,763 INFO     RFM2Pi     Publishing: emonhub/rx/5/values 1271,-936,335,238.2,0,0,0,0,0,0,0
2015-10-25 12:53:51,764 DEBUG    RFM2Pi     725 adding frame to buffer => [1445774031, 5, 1271, -936, 335, 238.20000000000002, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:53:51,765 DEBUG    RFM2Pi     725 Sent to channel' : ToEmonCMS
2015-10-25 12:53:56,692 DEBUG    RFM2Pi     726 NEW FRAME : OK 5 2 5 93 252 95 1 249 92 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2015-10-25 12:53:56,694 DEBUG    RFM2Pi     726 Timestamp : 1445774036.69
2015-10-25 12:53:56,695 DEBUG    RFM2Pi     726 From Node : 5
2015-10-25 12:53:56,695 DEBUG    RFM2Pi     726    Values : [1282, -931, 351, 238.01, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:53:56,696 INFO     RFM2Pi     Publishing: emonhub/rx/5/values 1282,-931,351,238.01,0,0,0,0,0,0,0
2015-10-25 12:53:56,698 DEBUG    RFM2Pi     726 adding frame to buffer => [1445774036, 5, 1282, -931, 351, 238.01, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:53:56,699 DEBUG    RFM2Pi     726 Sent to channel' : ToEmonCMS
2015-10-25 12:54:01,765 DEBUG    RFM2Pi     727 NEW FRAME : OK 5 1 5 100 252 101 1 229 92 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2015-10-25 12:54:01,768 DEBUG    RFM2Pi     727 Timestamp : 1445774041.77
2015-10-25 12:54:01,769 DEBUG    RFM2Pi     727 From Node : 5
2015-10-25 12:54:01,769 DEBUG    RFM2Pi     727    Values : [1281, -924, 357, 237.81, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:54:01,770 INFO     RFM2Pi     Publishing: emonhub/rx/5/values 1281,-924,357,237.81,0,0,0,0,0,0,0
2015-10-25 12:54:01,772 DEBUG    RFM2Pi     727 adding frame to buffer => [1445774041, 5, 1281, -924, 357, 237.81, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:54:01,772 DEBUG    RFM2Pi     727 Sent to channel' : ToEmonCMS
2015-10-25 12:54:06,722 DEBUG    RFM2Pi     728 NEW FRAME : OK 5 250 4 103 252 97 1 245 92 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2015-10-25 12:54:06,724 DEBUG    RFM2Pi     728 Timestamp : 1445774046.72
2015-10-25 12:54:06,725 DEBUG    RFM2Pi     728 From Node : 5
2015-10-25 12:54:06,726 DEBUG    RFM2Pi     728    Values : [1274, -921, 353, 237.97, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:54:06,726 INFO     RFM2Pi     Publishing: emonhub/rx/5/values 1274,-921,353,237.97,0,0,0,0,0,0,0
2015-10-25 12:54:06,745 DEBUG    RFM2Pi     728 adding frame to buffer => [1445774046, 5, 1274, -921, 353, 237.97, 0, 0, 0, 0, 0, 0, 0]
2015-10-25 12:54:06,746 DEBUG    RFM2Pi     728 Sent to channel' : ToEmonCMS
2015-10-25 12:54:11,703 DEBUG    RFM2Pi     729 NEW FRAME : OK 5 252 4 97 252 93 1 23 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)

Those strings of nulls at the end of the packet stretch the ability of the receiver bit slicer synch. This could scramble the CRC bytes that follow (but are not shown in the trace).  This just could allow a noise packet to decode with a "correct" CRC, but the probability is low. From the timestamps, that would imply a huge number of junk packets (which are supressed in this trace).

A quick check would be to load the very latest release and retry - this effectively replaces the trailing nulls with some "out of range" data.

first of all: I have to apologize for the time you might have wasted trying to help me.

second: it was simply some nodes definitions in the emonhub config.

Sorry again

The node 5 data you see is from the "emonPi" add-on board directly, don't let the "OK" and the "(-0)" mislead you. Those frames of data come from the serially connected AVR and do not pass through any of the RF stuff. The long run of zero's will only tie up the serial port and perhaps slowdown the looping but cannot effect the crc (as far as I know). emjay is right the emonTx firmware has been updated to give out of range values for unused temp sensor, but that won't effect you unless you are running an emonTx as well.

The script emjay refers to in the other thread won't work with the emonPi currently as it only passes what it considers good packets, the bad packets are discarded and not available using a non-quiet mode,

However, emonHub will only pass frames that are concidered "OK" anyway so at this point anything you are seeing in emoncms MUST be in emonhub.log, if it's not it didn't come from emonhub.

The term "new in-active" has thrown me a little, do you mean they are in-active by the time you notice them or they are inactive when they appear? what are their node id's? do they have values attached? are they always the same node id's? do they always have the same number of inputs or values? How soon after deleting them do they reappear? Are they "new" or are they the same ones again and again?

Is this just on the emonPi hosted emoncms or on emoncms.org? nodes page or inputs page?

Are you deleting the unused nodes on the nodes page on emonpi/emoncms without deleting them in emonhub.conf? if so they will reappear almost immediately.

Paul

EDIT - Darn it! Your post wasn't there when I started writing! if only I could type faster :-)