Archived Forum

Hi Greg, Happy New Year to you !

At first glance I would say there was an issue in the rfm receiver firmware or at least a misunderstanding between it and emonhub. I can tell you are using the emon-pi variant of emonhub from the logs but cannot tell what hardware that is on, I assume a Pi but is it an emonPi or do you have a RFM2Pi board attached?

Did you use a pre-built image, use a guide to roll your own or do your own thing? Have you run any updates etc?

Looking at your log (in future please try and either attach a file so the line endings are in-tact or cut & paste with the lines wrapped to make reading easier) they are neither all "unreliable content" or all "rssi: -2147483648" in fact none of the sample you attached have that rssi so for the moment I think the "In the Nodes view all three report as" maybe a red herring and it was just coincidental at that time they happened to be the same, perhaps you can confirm that for us as that may signify another issue if the rssi's are being shared etc.

The rssi's are definitely wrong and as far as I can tell appear to be arriving that way. The "unreliable content" however is probably a little noise, the "?" is the indicator for it to be discarded as it failed crc checks, these are not uncommon so can be ignored for the moment until the rssi issue is resolved.

What sort of range are your devices working over? would you expect them to be similar and or strong/weak etc?

Looking at the rssi numbers last 2 bytes (rather than what appears to be a unsigned Long with a "-" prefixed or a Signed LongLong) they are 32, 75, 29, 76, 31 and 30 for each of the 6 packets shown below, the 2nd and 4th are considerably higher numbers (weaker signals) so do seem to be based on the correct values although somewhat distorted. 

2016-01-02 09:28:46,140 DEBUG RFM2Pi 2968 From Node : 11 
2016-01-02 09:28:46,154 DEBUG RFM2Pi 2968 Values : [0, 0, 0, 0, 236.64000000000001] 
2016-01-02 09:28:46,161 DEBUG RFM2Pi 2968 RSSI : -4281139232 
2016-01-02 09:28:46,169 INFO RFM2Pi Publishing: emonhub/rx/11/values 0,0,0,0,236.64 
2016-01-02 09:28:46,183 INFO RFM2Pi Publishing: emonhub/rx/11/rssi -4281139232 
2016-01-02 09:28:46,193 DEBUG RFM2Pi 2968 adding frame to buffer => [1451726926, 11, 0, 0, 0, 0, 236.64000000000001, -4281139232L] 
2016-01-02 09:28:46,196 DEBUG RFM2Pi 2968 Sent to channel' : ToEmonCMS

​2016-01-02 09:28:46,317 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 12 167 129 24 0 100 191 123 251 25 246 249 203 125 132 219 69 148 45 129 219 (-4281139275) 

2016-01-02 09:28:46,629 DEBUG RFM2Pi 2969 NEW FRAME : OK 12 0 0 0 0 0 0 0 0 56 90 (-4281139229) 
2016-01-02 09:28:46,635 DEBUG RFM2Pi 2969 Timestamp : 1451726926.63 
2016-01-02 09:28:46,637 DEBUG RFM2Pi 2969 From Node : 12 
2016-01-02 09:28:46,641 DEBUG RFM2Pi 2969 Values : [0, 0, 0, 0, 230.96] 
2016-01-02 09:28:46,643 DEBUG RFM2Pi 2969 RSSI : -4281139229 
2016-01-02 09:28:46,647 INFO RFM2Pi Publishing: emonhub/rx/12/values 0,0,0,0,230.96 
2016-01-02 09:28:46,652 INFO RFM2Pi Publishing: emonhub/rx/12/rssi -4281139229 
2016-01-02 09:28:46,658 DEBUG RFM2Pi 2969 adding frame to buffer => [1451726926, 12, 0, 0, 0, 0, 230.96, -4281139229L] 
2016-01-02 09:28:46,660 DEBUG RFM2Pi 2969 Sent to channel' : ToEmonCMS 

2016-01-02 09:28:52,023 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 4 116 163 124 12 180 245 17 3 230 79 12 193 122 63 84 14 65 45 6 144 (-4281139276) 

2016-01-02 09:28:52,135 DEBUG RFM2Pi 2970 NEW FRAME : OK 11 0 0 0 0 0 0 0 0 146 92 (-4281139231) 
2016-01-02 09:28:52,141 DEBUG RFM2Pi 2970 Timestamp : 1451726932.13 
2016-01-02 09:28:52,144 DEBUG RFM2Pi 2970 From Node : 11 
2016-01-02 09:28:52,146 DEBUG RFM2Pi 2970 Values : [0, 0, 0, 0, 236.98000000000002] 
2016-01-02 09:28:52,149 DEBUG RFM2Pi 2970 RSSI : -4281139231 
2016-01-02 09:28:52,152 INFO RFM2Pi Publishing: emonhub/rx/11/values 0,0,0,0,236.98 
2016-01-02 09:28:52,157 INFO RFM2Pi Publishing: emonhub/rx/11/rssi -4281139231 
2016-01-02 09:28:52,163 DEBUG RFM2Pi 2970 adding frame to buffer => [1451726932, 11, 0, 0, 0, 0, 236.98000000000002, -4281139231L] 2016-01-02 09:28:52,166 DEBUG RFM2Pi 2970 Sent to channel' : ToEmonCMS 

2016-01-02 09:28:52,499 DEBUG RFM2Pi 2971 NEW FRAME : OK 12 0 0 0 0 0 0 0 0 77 90 (-4281139230)

Let us know what hardware/firmware you are using so we can look at the code.

Paul

Hi Paul,

Thanks for your reply. Understood about the pasting the logs.

Apologies for not posting my emonbase hardware which is a Rpi Rev2 Model B. It has the RFM69Pi ­ base fron the shop.

I'm using the v9 image "emonSD-18Dec2015.img" , Its showing "Emoncms Version low-write 9.2 | 2015.12.10".

I ran the update from (http://emonpi/emoncms/admin/view)...but i guess that does not update the RFM69pi firmware....

With the RSSI value, in the Nodes view (http://emonpi/emoncms/nodes/view) all three do report the same value..." -2147483648" - even after a reboot of the Rpi...so i guess this value is not originating from any data from the radio??

The EmonTX is already commissioned in my powerbox, which is probably over 10m away from the EmonBase, but the two emonTXshields are only about 1200cm away from the base.

Thanks again for your help ;-)

Edit: Over the past week ive never seen a valid value for RSSI. I wasnt worried about it at that time, only getting good data for power/voltage.

Are you able to use a serial console like minicom or similar to get a sample of data direct from the serial port?

The RFM69Pi firmware has been around a while and there have been no similar reports so that casts some doubt on the packets arriving "distorted" but doesn't absolutely rule it out.

The nodes all sharing a fixed rssi is probably a different issue, but as the "publishing rssi" code is a relatively new addition I do not know how tried and tested it is or how it would react to the value being so far out of scope, it maybe coincidental but the binary for "-2147483648" is 10000000 00000000 00000000 00000000 and since the leading bit is usually the sign I wonder if it is attempting a "-0" representation as used by the emonPi?

Paul

@gregl,

For what it's worth, -2147483648 is a slightly confused mapping of 4 empty bytes to decimal.

Oops, crossed with Paul's more erudite email.

Also curious is the pseudo precision of for example 236.98000000000002 when 236.98 is an exact mapping...

@emjay, Happy New Year to you,

I was also intrigued by the additional "0.00000000000002", I assume it is a quirk of using float due to this line in emonhub.

​val = decoded[i] * float(x)

where val is the result of multiplying (usually) an Int or Long by the float "scale" of (usually) 0.01 or 0.1, (I'm not a fan of floats and they always seem broken to me) I guess a "rounding" of the result to the same number of decimal places as the "scale" may be in order since it can never actually (accurately?) be to a higher precision.

Perhaps change this line

decoded[i] = float(val)

to decoded[i] = round(float(val),len(x)-x.rfind(".")-1)

Since x (the "scale") has been read from the conf it is a string, we can minus the index of the "." character from the length ( and -1 correction for the zero index) to find the decimal places for round().

Paul

Thanks again for your help gents. Here is the output from minicom.

 ? 174 108 167 152 100 112 168 6 5 184 132 238 99 133 205 250 200 13 119 52 108 (-4281139279)
 ? 171 130 243 142 45 204 175 210 253 (-4281139275)
OK 12 0 0 0 0 0 0 0 0 77 90 (-4281139236)
OK 11 0 0 0 0 0 0 0 0 119 92 (-4281139237)
OK 12 0 0 0 0 0 0 0 0 71 90 (-4281139236)
 ? 133 187 53 237 221 131 (-4281139278)
OK 11 0 0 0 0 0 0 0 0 134 92 (-4281139235)
 ? 161 88 243 22 154 162 20 93 79 59 137 133 228 252 77 157 150 61 42 14 50 (-4281139275)
OK 12 0 0 0 0 0 0 0 0 74 90 (-4281139242)
OK 11 0 0 0 0 0 0 0 0 130 92 (-4281139238)
 ? 137 147 235 254 136 200 249 59 236 190 48 117 128 53 164 155 163 162 15 230 25 (-4281139277)
OK 12 0 0 0 0 0 0 0 0 116 90 (-4281139234)
 ? 32 97 28 206 54 157 185 88 167 185 157 231 70 4 36 88 26 58 (-4281139277)
 ? 11 0 0 0 0 0 0 0 126 92 222 (-4281139234)
OK 8 4 0 56 1 196 1 0 0 202 92 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-4281139266)
 ? 178 78 157 189 87 191 242 201 33 243 188 45 7 57 229 208 239 103 12 191 178 (-4281139276)
 ? 143 213 197 129 112 19 122 142 99 127 89 178 183 213 134 35 128 158 29 151 51 (-4281139273)
OK 11 0 0 0 0 0 0 0 0 131 92 (-4281139234)
 ? 142 27 77 200 66 104 236 151 220 243 236 92 90 238 207 210 81 100 233 109 222 (-4281139278)
OK 12 0 0 0 0 0 0 0 0 94 90 (-4281139235)
 ? 63 192 156 108 118 210 152 44 16 131 167 158 111 225 96 89 143 227 115 244 197 (-4281139276)
 ? 11 0 0 0 0 0 0 0 46 92 226 (-4281139249)
 ? 181 195 229 80 104 126 110 221 5 152 215 209 135 46 126 27 16 239 20 138 18 (-4281139277)
 ? 142 116 203 35 143 253 46 230 239 238 227 82 146 63 94 175 90 37 5 82 98 (-4281139275)
 ? 3 199 29 85 138 110 76 203 50 58 67 188 206 124 132 22 137 236 191 78 62 (-4281139276)
 ? 11 0 0 0 0 0 0 0 0 128 92 (-4281139236)
OK 8 2 0 57 1 194 1 0 0 193 92 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-4281139267)
OK 12 0 0 0 0 0 0 0 0 101 90 (-4281139236)
 ? 11 0 0 0 0 0 0 0 134 92 157 (-4281139236)
OK 12 0 0 0 0 0 0 0 0 117 90 (-4281139236)
 ? 44 208 70 30 14 245 79 158 175 226 255 134 20 149 91 125 132 34 143 54 174 (-4281139276)
OK 11 0 0 0 0 0 0 0 0 108 92 (-4281139237)
OK 12 0 0 0 0 0 0 0 0 57 90 (-4281139237)
OK 11 0 0 0 0 0 0 0 0 112 92 (-4281139234)
OK 12 0 0 0 0 0 0 0 0 84 90 (-4281139236)
 ? 11 0 0 0 0 0 0 0 124 92 223 (-4281139234)
OK 12 0 0 0 0 0 0 0 0 101 90 (-4281139235)

is there a way i can see what version of firmware has been loaded onto th RFM69PI?

If you look in emonhub.log back to when it was started last or just restart emonhub it is logged at start-up.

Or if you still have minicom connected you can just send a "?" which will result in a help text being printed which will include the version.

Paul

Here is emonhub.log from a fresh reboot.

2016-01-03 06:40:09,567 INFO     MainThread EmonHub emonHub 'emon-pi' variant v1.1
2016-01-03 06:40:09,593 INFO     MainThread Opening hub...
2016-01-03 06:40:09,596 INFO     MainThread Logging level set to DEBUG
2016-01-03 06:40:09,621 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2016-01-03 06:40:09,664 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-01-03 06:40:11,707 INFO     MainThread RFM2Pi device firmware version: [RF12demo.12]
2016-01-03 06:40:11,716 INFO     MainThread RFM2Pi device current settings:  @ i0 g210 @ 433 MHz
2016-01-03 06:40:11,731 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2016-01-03 06:40:12,735 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2016-01-03 06:40:13,739 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2016-01-03 06:40:14,743 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2016-01-03 06:40:14,747 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2016-01-03 06:40:14,770 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2016-01-03 06:40:14,774 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2016-01-03 06:40:14,788 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT' 
2016-01-03 06:40:14,803 INFO     MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883 mqtt_user= 
2016-01-03 06:40:14,821 DEBUG    RFM2Pi     acknowledged command: > 0q
2016-01-03 06:40:14,842 DEBUG    MainThread MQTT Subscribed to channel' : ToEmonCMS
2016-01-03 06:40:14,857 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 
2016-01-03 06:40:14,868 DEBUG    MainThread emoncmsorg Subscribed to channel' : ToEmonCMS
2016-01-03 06:40:14,973 INFO     MQTT       Connecting to MQTT Server
2016-01-03 06:40:15,040 INFO     MQTT       connection status: Connection successful
2016-01-03 06:40:15,054 DEBUG    MQTT       CONACK => Return code: 0
2016-01-03 06:40:15,051 DEBUG    RFM2Pi     acknowledged command: > 5i
2016-01-03 06:40:15,183 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2016-01-03 06:40:15,202 INFO     MQTT       on_subscribe
2016-01-03 06:40:15,322 DEBUG    RFM2Pi     2 NEW FRAME : OK 12 0 0 0 0 0 0 0 0 7 90 (-4281139233)
2016-01-03 06:40:15,377 DEBUG    RFM2Pi     2 Timestamp : 1451803215.32
2016-01-03 06:40:15,410 DEBUG    RFM2Pi     2 From Node : 12
2016-01-03 06:40:15,413 DEBUG    RFM2Pi     2    Values : [0, 0, 0, 0, 230.47]
2016-01-03 06:40:15,415 DEBUG    RFM2Pi     2      RSSI : -4281139233
2016-01-03 06:40:15,419 INFO     RFM2Pi     Publishing: emonhub/rx/12/values 0,0,0,0,230.47
2016-01-03 06:40:15,491 INFO     RFM2Pi     Publishing: emonhub/rx/12/rssi -4281139233
2016-01-03 06:40:15,496 DEBUG    RFM2Pi     2 adding frame to buffer => [1451803215, 12, 0, 0, 0, 0, 230.47, -4281139233L]
2016-01-03 06:40:15,498 DEBUG    RFM2Pi     2 Sent to channel' : ToEmonCMS
2016-01-03 06:40:15,632 DEBUG    RFM2Pi     acknowledged command: > 1p
2016-01-03 06:40:15,976 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..30)
2016-01-03 06:40:16,099 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2016-01-03 06:40:16,287 DEBUG    RFM2Pi     acknowledged command: <nnnn> o   - change frequency offset within the band (default 1600)
2016-01-03 06:40:16,604 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2016-01-03 06:40:16,717 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2016-01-03 06:40:16,982 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2016-01-03 06:40:17,108 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2016-01-03 06:40:17,246 DEBUG    RFM2Pi     acknowledged command: <n> q      - set quiet mode (1 = don't report bad packets)
2016-01-03 06:40:17,392 DEBUG    RFM2Pi     acknowledged command: <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2016-01-03 06:40:17,800 DEBUG    RFM2Pi     acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
2016-01-03 06:40:17,928 DEBUG    RFM2Pi     acknowledged command: <addr>,<dev>,<on> k              - KAKU command (433 MHz)
2016-01-03 06:40:18,180 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2016-01-03 06:40:18,438 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 58 136 117 143 244 31 108 243 33 227 199 240 70 215 11 175 120 160 144 79 245 (-4281139276)
2016-01-03 06:40:18,607 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 153 249 142 174 218 249 244 30 183 149 156 164 81 101 237 236 16 99 152 18 240 (-4281139274)
2016-01-03 06:40:18,776 DEBUG    RFM2Pi     9 NEW FRAME : OK 11 0 0 0 0 0 0 0 0 46 92 (-4281139247)
2016-01-03 06:40:18,823 DEBUG    RFM2Pi     9 Timestamp : 1451803218.78
2016-01-03 06:40:18,826 DEBUG    RFM2Pi     9 From Node : 11
2016-01-03 06:40:18,828 DEBUG    RFM2Pi     9    Values : [0, 0, 0, 0, 235.98000000000002]
2016-01-03 06:40:18,861 DEBUG    RFM2Pi     9      RSSI : -4281139247
2016-01-03 06:40:18,864 INFO     RFM2Pi     Publishing: emonhub/rx/11/values 0,0,0,0,235.98
2016-01-03 06:40:18,898 INFO     RFM2Pi     Publishing: emonhub/rx/11/rssi -4281139247
2016-01-03 06:40:18,910 DEBUG    RFM2Pi     9 adding frame to buffer => [1451803218, 11, 0, 0, 0, 0, 235.98000000000002, -4281139247L]
2016-01-03 06:40:18,913 DEBUG    RFM2Pi     9 Sent to channel' : ToEmonCMS
2016-01-03 06:40:19,034 DEBUG    RFM2Pi     10 NEW FRAME : OK 12 0 0 0 0 0 0 0 0 19 90 (-4281139239)
2016-01-03 06:40:19,048 DEBUG    RFM2Pi     10 Timestamp : 1451803219.03
2016-01-03 06:40:19,050 DEBUG    RFM2Pi     10 From Node : 12
2016-01-03 06:40:19,053 DEBUG    RFM2Pi     10    Values : [0, 0, 0, 0, 230.59]
2016-01-03 06:40:19,072 DEBUG    RFM2Pi     10      RSSI : -4281139239
2016-01-03 06:40:19,075 INFO     RFM2Pi     Publishing: emonhub/rx/12/values 0,0,0,0,230.59
2016-01-03 06:40:19,113 INFO     RFM2Pi     Publishing: emonhub/rx/12/rssi -4281139239
2016-01-03 06:40:19,144 DEBUG    RFM2Pi     10 adding frame to buffer => [1451803219, 12, 0, 0, 0, 0, 230.59, -4281139239L]
2016-01-03 06:40:19,146 DEBUG    RFM2Pi     10 Sent to channel' : ToEmonCMS
2016-01-03 06:40:19,330 DEBUG    RFM2Pi     11 NEW FRAME : OK 8 1 0 144 1 189 1 0 0 119 92 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-4281139266)
2016-01-03 06:40:19,341 DEBUG    RFM2Pi     11 Timestamp : 1451803219.32
2016-01-03 06:40:19,343 DEBUG    RFM2Pi     11 From Node : 8
2016-01-03 06:40:19,345 DEBUG    RFM2Pi     11    Values : [1, 400, 445, 0, 236.71, 300, 300, 300, 300, 300, 300, 1]
2016-01-03 06:40:19,348 DEBUG    RFM2Pi     11      RSSI : -4281139266
2016-01-03 06:40:19,371 INFO     RFM2Pi     Publishing: emonhub/rx/8/values 1,400,445,0,236.71,300,300,300,300,300,300,1
2016-01-03 06:40:19,376 INFO     RFM2Pi     Publishing: emonhub/rx/8/rssi -4281139266
2016-01-03 06:40:19,432 DEBUG    RFM2Pi     11 adding frame to buffer => [1451803219, 8, 1, 400, 445, 0, 236.71, 300, 300, 300, 300, 300, 300, 1, -4281139266L]
2016-01-03 06:40:19,442 DEBUG    RFM2Pi     11 Sent to channel' : ToEmonCMS
2016-01-03 06:40:19,617 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 59 125 188 176 239 137 127 155 206 95 30 251 111 119 143 162 214 103 71 143 219 (-4281139275)
2016-01-03 06:40:19,942 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 3 50 47 135 141 11 194 17 254 6 63 68 40 197 190 247 231 2 231 229 121 (-4281139276)
2016-01-03 06:40:20,058 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 11 0 0 0 0 0 0 0 8 92 248 (-4281139248)
2016-01-03 06:40:20,275 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 21 190 125 244 211 116 125 101 120 142 74 238 11 186 74 249 249 135 117 120 223 (-4281139276)
2016-01-03 06:40:20,457 DEBUG    RFM2Pi     12 NEW FRAME : OK 12 0 0 0 0 0 0 0 0 3 90 (-4281139239)
2016-01-03 06:40:20,474 DEBUG    RFM2Pi     12 Timestamp : 1451803220.46
2016-01-03 06:40:20,476 DEBUG    RFM2Pi     12 From Node : 12
2016-01-03 06:40:20,509 DEBUG    RFM2Pi     12    Values : [0, 0, 0, 0, 230.43]
2016-01-03 06:40:20,512 DEBUG    RFM2Pi     12      RSSI : -4281139239

Line six of your log says the rfm69pi is running firmware "RF12demo.12", that was expected, however there have been some revisions in that version so it doesn't pin it down exactly and as this issue is almost definitely caused by the rfm69pi it may turn out best to load a known good firmware if no other progress is made.

Line 7 is odd, it logs the current settings of the rfm69pi and reveals the current nodeid (baseid) as 0, I think this is likely to be the device forgetting who it is at boot and the zero signifies an absent nodeid rather than it being set as zero since 0 is not a valid nodeid.

Line 8 is setting quiet mode to off and is the reason you can see the "unreliable content" marked for discarding with a "?", since these are not of interest right now and only clutter the logs you could set "quiet = true" in the [[RFM2Pi]] settings in emonhub.conf. It is really a lost packet debugging tool and can be enabled again later if you wish.

Line 9 is setting the rfm69pi baseid to node 5, the emonPi nodeid, whilst it isn't stricktly "right" it causes no problem. You can change to "baseid = 15" in [[RFM2Pi]] in emonhub.conf it you prefer.

Line 10 should not be there, it is the method used to set the emonPi for "USA" voltages, it is not used by the rfm2pi, rfm69pi or any "Jee" devices, at best it causes a lot of unnecessary serial traffic and log entries. The "acknowledged commands" from line 36 are the direct result of this setting as valid commands are returned prefixed with a ">" there are many other lines that will have been silently discarded as they did not contain the ">" char. To fix this just delete the "calibration = " line from [[RFM2Pi]] in emonhub.conf.

So none of this tells us why the rssi is wrong and it does highlight a potential firmware issue with the nodeid, You could try the settings I've mentioned above and see if a fresh "power down" reboot helps the rfm69pi. it will at least tidy the logs so any other anomalies may be easier to spot. But I think it's heading towards a firmware update.

Paul

Something to come back to when RSSI reporting starts to behave itself. In the previous trace, there are several nodeid 11 packets of adequate strength that are failing with bit synch slip (the known issue with runs of null bytes in the packet).

Its working!

In the end it appears to be the firmware!

I made the changes to emonhub.conf as you suggested Paul, including a full powered down restart, but no cigar....

So i then tried updating the firmware and bam...RSSI data now looks good... The EmonTX i have inside my galvanised steel powerbox reports ~ -61 , -63 or so...

The emonShields are reporting - 32 pr so....

Happy days!

Thanks for your help again ;-)

FWIW, i ordered my bits at teh start of December...im guessing the RFM69pi I received was an older firmware version ??

That's good news, I do wish we had more details on the how and why the rssi issue was happening eg an exact version or build date, but the main thing is you are up and running. Would you confirm which firmware you have installed?

Further to emjay's comments both your shields appear to have no ct's connected, hopefully that is just a temporary thing, if you are not using the shields for power the sketches could do with modifying to avoid the long runs of zeros, as this is known to cause packet loss due to the receiver not being able to use the bits to manage the timing, eg a long run of 16 0's is no different to 15 or 17 0's except for duration they span and the longer the run the more prone to discrepancies the payload is. the 4 unused power values are 32 0's.

The run of 300's you see is the fix for unused temp sensors rather than use 0 for unused circuits, an out of scope 300 is used. unfortunately the emonTx devices test for CT's at boot and the unused channels remain fixed at 0 for a better looking packet  I tend to remove that code so that all the channels are monitored and the "noise" of 1 or 2 watts then prevents any unnecessary packet loss.

Try to break up the unused channels eg If you plan to just use just 2 channels on each then use 1 and 3. If you do not intend using the ct channels then I would recommend editing the sketch to either use non-zero's or if it's a permanent choice then just remove the unused power values to reduce the payload therefore the transmissions time therefore the rf collisions.

Paul

I used the instructions at the bottom of this page to get and flash the latest firmware : http://wiki.openenergymonitor.org/index.php/RFM69Pi_V3

I think it would be a good idea to print out the exact version of the sketch, which can then be logged...likewise it would be cool if all the node sketch versions were transmitted back to the emonhub, which is then used to automatically populate the "node firmware" field on the  http://emonpi/emoncms/nodes/view. Or even set the "name".. but anyway im happy its working.

Id be happy to try flashing the last few versions of the firmware onto my rfm69pi to see if we can determine the bad version... but im not sure how to get the previous versions from GIT ( newbie here too! ) - If you can assist with url's to the previous firmwares ill have a go and see if i can reproduce.

I do have one CT connected to each shield, however there is no current flowing through them, but many thanks for the advice on spreading the channels. - i intend on using all, in fact the two shields are installed into the same project box, and share the same AC-AC feed for voltage calibration. This seems to be working ok on my desk. I did need to calibrate each arduino with different voltage calibration values, but the Vrms values now sent are within .5v of each other and CT's connected to the same test load ( at the same time) are within 5w..

My biggest concern was the radios interfering with one another, but so far this doesnt seem to be an issue...Ill see when i install it into the sub-board.

See attached photos.

In time the "firmware" field is intended to be used to identify the firmware to be installed and with an additional "version" field, monitored for version changes.

Thanks for the offer to seek out the offending firmware, but that probably won't be an easy task and if it's not an issue in later firmware it maybe of little or no use. It would have been interesting to know, and easier to find had there been a better version id.

I recently installed 3 emonTx's in a single box all using rf (in fact the Pi and rfm69pi where in the same box too) and the results are better than I expected, (although not as good as I would have liked either). I don't think there is any "interference" par se, the problem is the receiver can only receive from one at a time and there is no synchronization or order, so blocking occurs. keeping packets short minimizes this.

Paul