Archived Forum

Use minicom to check what is set and see if it matches what the emoncms page is telling you.

You'll probably need to kill/remove the emoncms line from your cron script.  

After using minicom , readd  the cron script line and restart your pi

According to Minicom the correct base ID is set, if I restart the PHP script it starts sending the data under the correct base ID for a short period of time, however it switches to sending it from random base id's again.

I am wondering if the RFM2Pi firmware has a bug.

Check Nathan Chantrell's twitter: http://twitter.com/nathanchantrell and also Elyob's http://twitter.com/elyob
I think they might experience the same problems?

Do you have another user registered on your emoncms that has other RFM2Pi settings i.e. these that it tends to change to?

I haven't experienced this, interested to know what the cause is, probably it has its good explanation.

Hi Martin,

No, just 1 user registered, I monitored what was coming out of the RFM2Pi this morning and it appears to be totally random

@ 10:06 it was posting from base ID, @ 10:25 it changed to 24, 10:30 is was 11, 10:40 it was 12 and 11:27 it changed to 4

I stopped monitoring after that.

Hi Fluppie007,

on Nathanchantrell's twitter feed it seems to suggest you can change the PHP to get around it, but can see what he is suggesting, am I missing something ?

Could you post the code you are using?

Hi Ukmoose,

I am using the standard Firmware in the RFM2Pi.

I have modified the raspberrypi_run.php
    After line
           $url = "/emoncms/input/post?apikey=".$apikey."&node=".$values[1]."&csv=".$msubs;
           getcontent("localhost",80,$url);
I have inserted          
           $hour = date('H');
           $min = date('i');
           fprintf($f,$hour.",00,".$min.",00,s");
           sleep(1);

I am using the firmware below in a spare NanodeRF module to constantly monitor the airwaves for any 433mhz transmission and display the data packet via the serial monitor port.

/*
  RFM12_Monitor

  Display data recieved from any wireless

  Original Authors: Trystan Lea and Glyn Hudson
  Part of the: openenergymonitor.org project
  Licenced under GNU GPL V3
  http://openenergymonitor.org/emon/license

  JeeLib Library by Jean-Claude Wippler

  THIS SKETCH REQUIRES:
 
  Libraries in the standard arduino libraries folder:
    - JeeLib        https://github.com/jcw/jeelib

*/

#define UNO       //anti crash wachdog reset only works with Uno (optiboot) bootloader, comment out the line if using delianuova

#include <JeeLib.h>         //https://github.com/jcw/jeelib
#include <avr/wdt.h>

#define MYNODE 40           
#define freq RF12_433MHZ     // frequency
#define group 210            // network group

//---------------------------------------------------------------------
// The PacketBuffer class is used to generate the json string
//---------------------------------------------------------------------
class PacketBuffer : public Print {
public:
    PacketBuffer () : fill (0) {}
    const char* buffer() { return buf; }
    byte length() { return fill; }
    void reset()
    {
      memset(buf,NULL,sizeof(buf));
      fill = 0;
    }
    virtual size_t write (uint8_t ch)
        { if (fill < sizeof buf) buf[fill++] = ch; }
    byte fill;
    char buf[150];
    private:
};
PacketBuffer str;

const int redLED = 6;                     // NanodeRF RED indicator LED
//const int redLED = 17;            // Open Kontrol Gateway LED indicator
const int greenLED = 5;                   // NanodeRF GREEN indicator LED

int rf_error = 0;                         // RF error flag - high when no data received

unsigned long last_rf;                    // Used to check for regular emontx data - otherwise error

char line_buf[50];                        // Used to store line of http reply header

unsigned long time60s = -50000;
//**********************************************************************************************************************
// SETUP
//**********************************************************************************************************************
void setup () {
 
  //Nanode RF LED indictor  setup - green flashing means good - red on for a long time means bad!
  //High means off since NanodeRF tri-state buffer inverts signal
  pinMode(redLED, OUTPUT); digitalWrite(redLED,LOW);           
  pinMode(greenLED, OUTPUT); digitalWrite(greenLED,LOW);      
  delay(100); digitalWrite(redLED,HIGH);                          // turn off redLED
 
  Serial.begin(9600);
  Serial.println("\n[RF Monitor]");

  rf_error=0;

  rf12_initialize(MYNODE, freq,group);
  last_rf = millis()-40000;                                       // setting lastRF back 40s is useful as it forces the ethernet code to run straight away
  
  digitalWrite(greenLED,HIGH);                                    // Green LED off - indicate that setup has finished
 
  #ifdef UNO
  wdt_enable(WDTO_8S);
  #endif;
}

//**********************************************************************************************************************
// LOOP
//**********************************************************************************************************************
void loop () {
 
  #ifdef UNO
  wdt_reset();
  #endif

  //-----------------------------------------------------------------------------------------------------------------
  // 1) On RF recieve
  //-----------------------------------------------------------------------------------------------------------------
  if (rf12_recvDone()){     
      if (rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)
      {
        int node_id = (rf12_hdr & 0x1F);
        byte n = rf12_len;
        
        str.reset();
        str.print("Data Received :"); str.print(node_id); str.print(":");
        for (byte i=0; i<n; i+=2)
        {
          int num = ((unsigned char)rf12_data[i+1] << 8 | (unsigned char)rf12_data[i]);
          if (i) str.print(",");
          str.print(num);
        }

        Serial.println(str.buf); // print to serial json string

        last_rf = millis();
      }
  }

  //-----------------------------------------------------------------------------------------------------------------
  // 2) If no data is recieved from rf12 module the server is updated every 30s with RFfail = 1 indicator for debugging
  //-----------------------------------------------------------------------------------------------------------------
  if ((millis()-last_rf)>30000)
  {
    last_rf = millis();                                                 // reset lastRF timer
    str.reset();                                                        // reset json string
    str.print("No Data Received for 30000 Mill");
  }

}
//**********************************************************************************************************************

I have just been monitoring again and hopefully you can see the result below.

Base id 20 and 25 = GLCD sending out temp information, base id 10=emonTX sending out power usage and solar etc

and base id 15 = RFM2Pi sending out time, but as you can see it changes for no reason to sending it out as base id 12 ?

What I can see from your data capture is the first id12 reading also contains an error.  

The first reading is 12:46,16,46

Can you keep running the output and see if each time it changes this occurs?  

You should be able to use an if statement to only print if the node_id isn't 20 or 25.

When you say you are running the standard  raspberrypi_run.php it has gone through 3 versions in the last month. 

What is the line number of the line getcontent("localhost",80,$url); ?

The line getcontent("localhost",80,$url); is at 134 which I believe is the current version.

I have noticed the error you have spotted, but it doesnt appear to happen everytime.

The following is a printout where you can see the base id changing rapidly from 15 to 12 to 11 all within the space of 1 minute, each time with a noticeable error

The second display is a change from 11 to 19 with no discernable error in between

So how many lines of data are you seeing in a minute?

Did you see this issue when you first got the script working?
If not, does it go away if you revert to the older version?

Can you try to add 

fprintf($f,"\r\n");

just before the time-sending segment:

           $hour = date('H');
           $min = date('i');
           fprintf($f,$hour.",00,".$min.",00,s");
           sleep(1);

this would clear the RFM2pi's buffer. The RFMDemo sketch treats commands like 'A'-'Z' as requests to change the Node ID, this  looks like a possible cause of the problem, if the send buffer gets corrupted with incoming transmission while we prepare to send.

..also the rasperrypi_run.php has some debug ourput, try to run it from the console for a while to see what it outputs.

cd /var/www/emoncms/Modules/raspberrypi/

php raspberrypi_run.php

Roughly the RFM2Pi module transmits the time 19 to 21 times a minute.

I assume your talking about the PHP script ? This is the first time I have got it working with the Raspberrypi_run script so I don't know if it would work or not with previous versions.

I suspect it's something in the firmware of the RFM2Pi module as everything is correct on the Emoncms side of things (The Raspberry Pi config screen, the SQL database), and the PHP script doesn't send an base id information, it just uses the channel that is already opened.

           $hour = date('H');
           $min = date('i');
           fprintf($f,$hour.",00,".$min.",00,s");
           sleep(1);

It would be good if someone who has a spare NanodeRF could load the firmware above and change the PHP script to see if they can recreate the problem.

it's sending me nutty.

The PHP script sets the baseid, here are the lines:

fprintf($f,$baseid."i");

..and later..

if ($settings['baseid'] !=$baseid) {$baseid = $settings['baseid']; fprintf($f,$baseid."i");}

I think the best starting point is to just see what the PHP outputs, it will give us clues on the possible reason

I have traced both the PHP and the output from my NanodeRF monitor and it does appear the PHP is asking the RFM2Pi to change to a different base id.

I have uncommented all the Echo lines in the PHP and added echo $f,$hour.",00,".$min.",00,s";  just before the fprint at line 138

Here is the PHP output

And here is the RFM2Pi monitored output

Notice how it changes to i11@ at the same time.

How can I trace the PHP to see what is being sent to the RFM2Pi ?

The RFM12Pi is also receiving the data from your other devices and sending them all onto your  database. So I concur with Martin that I think your inputs to your RFM12Pi are corrupting the output.  

Sorry to confuse you as to which version of rasperrypi_run.php, I thought you had the script working earlier when the added lines were after line 100.

I tried to reproduce this today, setup my  RFM2Pi board to send time and left it running for an hour. A JeenodeV6 runing RFDemo sketch was picking up the transmissions, see below a 12 minute extract. The RFM2Pi didn't change its ID, so the trouble must be local.

I'd suggest to grab the latest version of the raspberrypi module and only apply the "send time" patch. This setup had me going for an hour without ID changing, I will leave it running the whole day. 

So the plot deepens :) 

_{? 49 72 147 204 127 206 234 173 52 222 53
? 149 5 122 115 72 56 232 117 75 24 114 139 182 119 132 143 82 103 35 200 242
OK 10 160 6 182 6 245 0 98 0 209 37 224 64
OK 15 9 0 1 0
? 13 125 241 15 224 136 252 137 184 203 16 136 105 227 45 173 148 35 115 128 193
OK 10 149 6 171 6 244 0 98 0 227 216 223 64
OK 15 9 0 1 0
OK 22 116 9 1 8
OK 15 9 0 1 0
? 15 216 104 15 139 167 95 119 159 187 126 95 112 115 250 225 162 207 160 133 240
? 17 132 128 174 50 237 13 227 116 7 48 86 153 223 9 139 67 209 193 135 227
OK 10 155 6 177 6 245 0 98 0 83 176 223 64
OK 15 9 0 1 0
OK 15 9 0 1 0
? 34 5 89 66 251 35 212 222 13 102 169 192 17 98 35 215 103 23 12 231 245
OK 10 153 6 174 6 245 0 98 0 8 242 222 64
OK 15 9 0 1 0
OK 7 121 12 87 11 121 12
OK 15 9 0 2 0
OK 10 149 6 170 6 245 0 98 0 111 195 222 64
OK 15 9 0 2 0
? 191 49 27 203 72 27 73 213 156 11 99 129 96 13 25 97 64 121 9 20 104
? 32 211 102 37 25 61 136 73 77 246 111 64 15 254 129 20 79 241 204 214 180
OK 10 144 6 166 6 245 0 98 0 165 230 221 64
OK 15 9 0 2 0
OK 10 138 6 158 6 245 0 98 0 237 245 220 64
OK 15 9 0 2 0
OK 10 125 6 145 6 244 0 98 0 111 239 219 64
OK 15 9 0 2 0
OK 22 116 9 2 8
OK 15 9 0 2 0
OK 10 145 6 165 6 245 0 98 0 150 216 221 64
OK 15 9 0 2 0
OK 10 141 6 161 6 245 0 98 0 8 175 221 64
OK 15 9 0 2 0
? 17 82 83 30 50 100 185 137 240 164 79 219 145 82 28 203 232 228 93 18 145
OK 11 108 7 171 11 108 7
OK 15 9 0 3 0
OK 7 121 12 79 11 121 12
OK 15 9 0 3 0
OK 10 148 6 169 6 245 0 98 0 206 49 222 64
OK 15 9 0 3 0
OK 10 152 6 173 6 245 0 98 0 148 167 222 64
OK 15 9 0 3 0
? 31 37 218 17 138 211 53 2 228 150 123 5 232 35 224 164 232 86 151 206 172
OK 10 158 6 179 6 245 0 98 0 117 53 223 64
OK 15 9 0 3 0
OK 9 72 11 189 7
OK 15 9 0 3 0
OK 10 154 6 174 6 245 0 98 0 2 33 223 64
OK 15 9 0 3 0
OK 11 108 7 171 11 108 7
OK 10 159 6 180 6 245 0 98 0 63 1 224 64
OK 15 9 0 4 0
OK 15 9 0 4 0
OK 7 121 12 87 11 121 12
OK 15 9 0 4 0
OK 19 120 5 171 11
OK 10 152 6 173 6 244 0 98 0 1 164 223 64
OK 15 9 0 4 0
? 11 69 233 170 238 234 225 231 156 224 60 59 164 150 102 40 20 30 103 113 114
? 6 36 20 102 46 209 60 106 176 197 232 222 122 202 89 125 19 22 70 162 43
OK 10 153 6 174 6 244 0 98 0 128 18 224 64
OK 15 9 0 4 0
OK 22 116 9 4 8
OK 15 9 0 4 0
? 129 171 127 126 97 206 110 206 219 15 246 196 230 249 29 95 114 164 171 22 121
OK 10 135 6 155 6 243 0 98 0 27 68 222 64
OK 15 9 0 4 0
? 162 139 6 38 230 82 17 51 124 146 250 7 203 203 76 104 20 83 85 108 184
OK 10 158 6 179 6 244 0 98 0 47 166 224 64
OK 15 9 0 4 0
? 24 252 211 203 209 104 28 31 213 222 64 59 127 38 67 78 112 171 135 197 18
OK 10 155 6 176 6 244 0 98 0 69 55 224 64
OK 15 9 0 5 0
? 43 164 8 82 201 248 46 12 51 212 152 246 5 248 91 102 53 226 146 186 96
OK 10 157 6 178 6 244 0 98 0 99 125 224 64
OK 15 9 0 5 0
OK 15 9 0 5 0
OK 10 160 6 180 6 244 0 98 0 166 146 224 64
OK 15 9 0 5 0
OK 7 121 12 79 11 121 12
OK 15 9 0 5 0
? 129 144 239 243 244 134 0 129 209 202 1 93 33 65 37 203 210 83 201 249 97
OK 10 151 6 171 6 244 0 98 0 205 129 223 64
OK 15 9 0 5 0
OK 40 0 0 134 10
-> ack
OK 15 9 0 5 0
OK 22 116 9 5 8
OK 15 9 0 5 0
OK 40 0 0 134 10
-> ack
OK 15 9 0 5 0
OK 10 149 6 170 6 242 0 98 0 110 23 225 64
OK 15 9 0 5 0
OK 10 144 6 165 6 242 0 98 0 221 91 224 64
OK 15 9 0 5 0
OK 10 156 6 177 6 243 0 98 0 255 38 225 64
OK 15 9 0 6 0
? 23 163 230 7 66 152 70 48 115 179 136 200 213 193 144 66 225 163 151 193 39
? 203 226 216 235 81 207 101 3 175 215 164 201 182 187 201 108 128 136 111 205 227
OK 10 158 6 180 6 243 0 98 0 240 120 225 64
OK 15 9 0 6 0
OK 10 160 6 181 6 243 0 98 0 153 172 225 64
OK 15 9 0 6 0
OK 7 121 12 79 11 121 12
OK 10 163 6 185 6 243 0 98 0 22 59 226 64
OK 15 9 0 6 0
OK 15 9 0 6 0
OK 15 9 0 6 0
OK 22 116 9 6 8
OK 15 9 0 6 0
OK 10 161 6 182 6 243 0 98 0 89 228 225 64
OK 15 9 0 6 0
OK 10 142 6 163 6 242 0 98 0 195 210 223 64
OK 15 9 0 6 0
? 22 8 252 209 248 203 136 70 170 71 153 231 105 8 72 26 124 134 247 13 47
? 16 78 252 96 114 114 238 17 41 127 235 153 98 190 107 248 118 181 212 163 90
OK 10 159 6 180 6 243 0 98 0 97 199 225 64
OK 15 9 0 7 0
OK 10 159 6 179 6 243 0 98 0 20 181 225 64
OK 15 9 0 7 0
OK 10 148 6 168 6 242 0 98 0 147 196 224 64
OK 15 9 0 7 0
OK 15 9 0 7 0
OK 10 159 6 179 6 242 0 98 0 244 57 226 64
OK 15 9 0 7 0
OK 22 116 9 7 8
OK 15 9 0 7 0
OK 7 115 12 87 11 115 12
OK 15 9 0 7 0
? 35 71 113 72 10 93 205 2 4 136 27 254 170 247 152 63 137 200 58 250 89
OK 10 155 6 176 6 242 0 98 0 88 178 225 64
OK 15 9 0 7 0
OK 10 43 7 47 7 242 0 99 0 201 207 242 64
OK 15 9 0 7 0
OK 10 133 7 132 7 243 0 100 0 221 208 252 64
OK 15 9 0 8 0
OK 10 122 7 121 7 243 0 100 0 74 14 251 64
OK 15 9 0 8 0
? 10 251 50 100 232 80 14 159 119 221 97 146 28 80 241 255 91 204 239 193 139
OK 10 134 7 133 7 243 0 100 0 195 226 252 64
OK 15 9 0 8 0
OK 10 128 7 127 7 243 0 100 0 166 149 252 64
OK 15 9 0 8 0
OK 15 9 0 8 0
OK 10 139 7 139 7 243 0 99 0 110 110 253 64
OK 15 9 0 8 0
OK 7 121 12 87 11 121 12
OK 15 9 0 8 0
OK 15 9 0 8 0
OK 10 135 7 136 7 243 0 99 0 157 35 253 64
OK 15 9 0 8 0
OK 10 117 7 116 7 244 0 100 0 131 7 250 64
OK 15 9 0 9 0
OK 10 118 7 118 7 243 0 100 0 152 163 250 64
OK 15 9 0 9 0
? 30 228 114 15 121 107 149 61 141 114 32 194 149 135 246 60 233 79 3 87 243
OK 10 113 7 113 7 243 0 100 0 16 165 250 64
OK 15 9 0 9 0
OK 19 120 5 171 11
OK 15 9 0 9 0
OK 10 122 7 122 7 243 0 99 0 246 126 251 64
OK 15 9 0 9 0
OK 22 116 9 9 8
OK 15 9 0 9 0
OK 15 9 0 9 0
OK 10 113 7 112 7 243 0 100 0 28 26 250 64
OK 15 9 0 9 0
OK 7 115 12 79 11 115 12
OK 15 9 0 9 0
OK 10 103 7 102 7 244 0 100 0 151 38 248 64
OK 15 9 0 10 0
OK 10 107 7 106 7 244 0 100 0 64 253 248 64
OK 15 9 0 10 0
? 18 8 179 77 243 197 37 50 239 119 20 103 31 211 108 69 119 166 97 220 255
OK 10 84 7 84 7 242 0 100 0 74 18 247 64
OK 15 9 0 10 0
OK 10 104 7 104 7 243 0 100 0 64 206 248 64
OK 15 9 0 10 0
? 148 221 233 147 201 113 51 0 241 108 28 243 94 249 59 119 193 253 1 70 22
OK 15 9 0 10 0
OK 10 98 7 98 7 243 0 100 0 218 9 248 64
OK 15 9 0 10 0
? 33 62 118 219 16 41 56 82 3 180 225 1 75 90 96 68 142 113 83 195 75
OK 10 109 7 108 7 244 0 100 0 60 61 249 64
OK 15 9 0 10 0
OK 11 126 7 171 11 126 7
OK 15 9 0 10 0
OK 10 96 7 94 7 244 0 100 0 128 61 247 64
OK 15 9 0 10 0
OK 7 115 12 87 11 115 12
OK 15 9 0 11 0
OK 10 103 7 102 7 244 0 100 0 34 102 248 64
OK 15 9 0 11 0
OK 10 112 7 112 7 243 0 100 0 83 72 250 64
OK 15 9 0 11 0
OK 10 104 7 104 7 243 0 100 0 70 23 249 64
OK 15 9 0 11 0
OK 22 116 9 1 8
OK 15 9 0 11 0
OK 10 89 7 88 7 242 0 100 0 171 11 248 64
OK 15 9 0 11 0
OK 10 107 7 106 7 243 0 100 0 209 92 249 64
OK 15 9 0 11 0
? 63 253 97 3 26 202 139 196 33 66 3 209 60 61 195 81 216 63 251 250 26
OK 10 101 7 100 7 243 0 100 0 255 219 248 64
OK 15 9 0 12 0
OK 10 106 7 105 7 243 0 100 0 199 157 249 64
OK 15 9 0 12 0
? 183 111 212 245 29 246 105 76 35 89 241 68 248 9 248 190 140 246 145 33 41
OK 7 109 12 79 11 109 12
OK 15 9 0 12 0}

Another idea to get this going (dirty hack) is to comment out the node setting in RFM2Pi firmware , just make sure it is set up correctly first and it saves in EEPROM. Then comment out all occurances of

config.nodeId = (config.nodeId & 0xE0) + (c & 0x1F);
saveConfig();

And the RFM2Pi board will not be able to change its id.

After leaving it to run for a while, I too got the change of ID.

So, I guess it is RFM2Pi's reaction to gibberish serial input, maybe it needs some kind of CRC validation, but that will make things more complex.

As a dirty fix, I disabled changing band, node  and frequency commands. I hardcoded those in the firmware and don't expect trouble anymore. Basiclly, once you set these once, you don't need to modify them, isn't that a fact?

Ok, so here is the final resolution:

I created alternative RFDemo sketch and now it includes a option to lock the board for configuration change. That lock is toggled by a special key > '123 x'. If the lock is set to 1: band, id and frequency can be modified. If the lock is set to 0, no changes are possible, so gibberish serial input can't spoil the settings.

Here is the alternative firmware version: https://github.com/mharizanov/RFM2Pi/tree/master/firmware/RFM2Pi_RF12_De...

I also uploaded a compiled .hex here: 

https://github.com/mharizanov/RFM2Pi/tree/master/firmware/Pre_compiled_A...

So basically you need to unlock th board for configuration, configure the band, id, frequency and then lock it again by issuing '123 x' (it toggles the lock state). The current lock state is displayed in the "Current configuration" line:

Available commands:
  123 x      - Toggle configuration change protection, 1=Unlocked
  <nn> i     - set node ID (standard node ids are 1..26)
  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
  <n> c      - set collect mode (advanced, normally 0)
  ...,<nn> a - send data packet to node <nn>, with ack
  ...,<nn> s - send data packet to node <nn>, no ack
  <n> l      - turn activity LED on DIG8 on or off
Current configuration:
79 i15 g210 @ 868 MHz  Lock: 0

Thanks for persevering with this, I think your right, I think whats happening (this is purely a guess at the moment I have no evidence) is that the RFM2Pi board is trying to process a send and receive at the same time and I suspect the TTY interface is giving out some error message which is being interpreted as a change base ID command, I think because the firmware allows the baseid to be changed with a single uppercase character its interpreting the first character of an error message and changing the baseid to that. but as I say, all guess work at the moment.

So far the baseid has been changed to 19,24,11,12,4,25, which translate to T,X,K,L,D,Y, I was thinking an error message starting TX ? but maybe I am reading too much into it.

Anyway, I am now the proud owner of an AVRISP MKII programmer so I will try and upload some new firmware and test out my theory.

Brace yourself for some stupid questions around loading firmware etc ! :-)

I included a pre-compiled .HEX on github , grab it from there.

Flashing it should be straight forward:

sudo avrdude -c avrispmkII -p t84 -P usb -e -Uefuse:w:0xFF:m -Uhfuse:w:0xD7:m -Ulfuse:w:0xE2:m -U flash:w:ATtiny84_RF12_Demo.cpp.hex

Quick question, Reading your programming the ATtiny84 instructions it says you must power it with 3.3v which can be taken from the Pi. Does that mean I can leave it plugged into the Pi GPIO pins while I program it or do I just jump 3.3v off the Pi but disconnect it from the GPIO ?

you can leave it plugged in, I do that all the time

Struggling to get this new firmware loaded, cant seem to get the programmer to see the ATtiny84 chip. I think it's not getting the correct 3.3v, can you explain how I get 3.3v out of the Raspberry ? which pin is it ?

At last, long night, but finally got the new firmware uploaded, now I know how this AVR programmer works !

I will leave it monitoring overnight, hopefully bring back some good news in the morning.

Good news, after leaving it monitoring over night the base id is still the same and hasn't changed.

Thanks for the updated Firmware, if I pull together all the updates I have made to get this working is there any chance we could incorporate them into the standard software package on GIT ?

Guys, sorry to disturb your nirvana, but my bloody display still shows only the minutes correctly, the hour is constantly 0 .. Any ideas why it might be happening ?

Cheers,

P.S. Debug from raspberrypi_run.php:

SERIAL RX: 10 147 2 0 0 0 0 211 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 52 10
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 10 147 2 0 0 0 0 211 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 10 154 2 0 0 0 0 211 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 52 10

Now I'm totally baffled .. From minicom, if I want to manually send time, i have to use sequence 00,hh,mm,00,s  ..

Anyone smarter than me care to explain ??

Regards,

There are a few areas of the emonGLCD script that I changed which seems to work

Add the following into the section that defines the radio packet structures (around line 70)

typedef struct { int hour, mins, sec; } PayloadBase;
PayloadBase emonbase;

Then change the part that receives the data to read (around line 150)

      if (node_id == 15)
      {
        emonbase = *(PayloadBase*) rf12_data;
        RTC.adjust(DateTime(2012, 1, 1, emonbase.hour, emonbase.mins, emonbase.sec));
        last_emonbase = millis();

Obviously change 15 to the nodeid of your RFM1Pi

Make sure that you have the following lines coded correctly in /var/www/emoncms/Modules/raspberrypi/raspberrypi_run.php

           $hour = date('H');
           $min = date('i');
           fprintf($f,$hour.",00,".$min.",00,s");
           sleep(1);

Cheers mate, worked like a charm. The only issue I'm experiencing right now is that it stops receiving messages from node 10 (emonTX) after a random amount of time. Rebooting the pi helps, killing and restarting the run php script doesn't. I know that the emontx is actually transmitting, because I can see the updating values on the LCD display ... Weird. I've seen that someone had similar issues, also your one (raspi backpack) was changing node ID, but if my one would be doing the same thing I wouldn't be able to see temp updates from the LCD and the sketch I'm running atm (solar pv-derrivate) would show me that the base is not sending the updates. Oh well, 1st git pull to see if anything in emoncms folder has been updated since Tristan has built this .img. What did you use, the ready-made pi-emon image or did you install from scratch ?

I have built mine from scratch, it's been through various iterations to be fair.

I am also having the same issue as you though, occasionally the Raspberry Pi/RFM12Pi stop receiving data from the emonTX although as you say the GLCD still receives transmissions from the TX so it must be something to do with the Raspberry Pi/RFM ?, still have not yet got to the bottom of it though.

Blimy ..

Because of the problems with reception, I'm running the rasp run.php on a screen session (btw, I have to correct one thing .. killing the process and restarting it solves the issue immediately). Look what I have caught today when the node 10 went below the radar :

SERIAL RX: 10 30 1 0 0 0 0 192 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 145 7
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 10 31 1 0 0 0 0 183 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 145 7
SERIAL RX: 10 30 1 0 0 0 0 183 12  <-- Last Transmission received, and then ...
SERIAL RX:Available commands:
SERIAL RX:  <nn> i     - set node ID (standard node ids are 1..26)
SERIAL RX:               (or enter an uppercase 'A'..'Z' to set id)
SERIAL RX:  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
SERIAL RX:  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
SERIAL RX:  <n> c      - set collect mode (advanced, normally 0)
SERIAL RX:  ...,<nn> a - send data packet to node <nn>, with ack
SERIAL RX:  ...,<nn> s - send data packet to node <nn>, no ack
SERIAL RX:  <n> l      - turn activity LED on DIG8 on or off
SERIAL RX:  <n> q      - set quiet mode (1 = don't report bad packets)
SERIAL RX:Current configuration:
SERIAL RX:76 i12 g210 @ 868 MHz
SERIAL RX:> 14b
SERIAL RX:> 0b
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 145 7
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 139 7
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 145 7
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 145 7
SERIAL RX:> 0s
SERIAL RX: -> 4 b

What the hell ? That looks like the initialization message from rf12 demo, but look at the Current Configuration: node id 12 ??And if I'm correct (as the output suggest), that's the received transmission, so it must be from a different node .. The problem is, that the remaining nodes are all working fine, and if the emonTX would change it's ID the display would not be updating itself, also it would spit out an error (again, running the SolarPV sketch on LCD proves to be useful, because it shows you if you have lost contact with base and/or emonTX and for how long in minutes).

As you can see, even when it stops receiving from node 10 it's still receiving the data from node 20, surprisingly, when it stops receiving from 10 it also (as it seems) stops sending the time to LCD (because it shows baseFail on display).

Again, restarting the scripts solves the issue immediately.

The most common log when it stops receiving is like this:

SERIAL RX: 10 34 1 0 0 0 0 192 12
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 139 7
SERIAL RX: 10 36 1 0 0 0 0 192 12
SERIAL RX:> 1b
SERIAL RX:> 0b <- That's how it starts ..
SERIAL RX:> 0b
SERIAL RX:> 0s
SERIAL RX: -> 4 b
SERIAL RX: 20 139 7
SERIAL RX:> 0s

... but it still receives from node 20 ..

So which node has changed it's ID ??

Martin, if you're still watching this thread, could you please try to explain how's that possible ?

I'm thinking of hardcoding the init values into each and every radio module, and then seeing if it helps .. 

Anyone, some bright ideas ? Pretty please ..

H.S.

You seem to be running the old firmware, the new one allows you to "lock" settings. Can you upgrade and report back?

Yeah, I've red that you have locked that on atiny and even posted the .hex, but unfortunately I don't have a programmer handy, I'd have to order it first. If I understand correctly, you're suggesting that it might be the PI that changed the ID ?

Back to square one, then .. Programmer ordered ..

Sorry Guys.. 

I understand iv got to upload the firmware to the RFM2Pi board. But i dont understand how..

Can i do it connected to the pi with nothing else?

Do i need another ardunio to do this?
I think i do.. But again im not 100% sure even how i can do this. 

Sorry im sure this seems like very simple stuff to you but im over my head for this.

No you can't do this with just the RaspberryPi.

You can do it using another arduino, but to be honest  as you can buy an AVR programmer for around £10, I'd go for this option.  

What you need is one that can connect to the standard 6pin avr pins (there's also a 10pin version)

Try looking for "usbtiny clone" on ebay or "avr programmer" on the search engine of your choice.

Hi @ll,

Just to let you know, after flashing that with the lockable firmware from Martin, it's been working rock stable for the last 72h+

Thanks to everyone involved for their help and support :)

TBP.

right finally got around to uploading the new hex file to the rfm12pi. All looks good, Thanks Martin..

But had a bit of a mair with the php code to send the time to the GLCD..

           $hour = date('H');
           $min = date('i');
           fprintf($f,$hour.",00,".$min.",00,s");
           sleep(1);

Is the code mentioned above but this sets the mins correct but not the Hr..  (Running latest code on the pi and GLCD)

Picked up from a jeelink.   RFM12B Transmission - OK 15 12 0 15 0    

had to change the code to 

           $hour = date('H');
           $min = date('i');
           fprintf($f,"00,".$hour.",".$min.",00,s");
           sleep(1);

Picked up from a jeelink.   RFM12B Transmission - OK 15 0 12 17 0

This works for me. Not sure if this is something i should be worried about though. As it seems most are using the above with out a mod.

Nothing to worry about: this will shred little light: http://en.wikipedia.org/wiki/Endianness

Somewhere it should be explained about the jumper above the ISP-connector. There are two empty holes where it says "ISP Power 3.3V only" where you solder two pin header. If you put a jumper on that header the RFM12Pi will be supplied with 3.3V from the Raspberry, otherwise there will be no power. This is important if you use a Avrisp which will not power the Attiny itself. Thus you have to mount a jumper here to be able to update the software.