Archived Forum

You should be able to flash the bootloader with the rfm12b module in place, provided you have an external pull-up on the rfm12b's /CS signal.  More on the reason for that here:  http://openenergymonitor.org/emon/node/5345

ok, so I have to connect a 10k or 100k resistor between the CS (stands for chip select right? ) and the vcc pins and then try to flash the bootloader?

I will try when I get back home.

Yep, it's often written as /CS because it's active low.  By pulling it high you're ensuring it's not active while you're trying to flash the bootloader.   Once the system image is up and running you can rely on the internal s/w controlled pull-ups but until you've got some s/w down there to enable them, you're kinda' stuck.

mmm tried again with the resistor but still nothing...

sudo avrdude -v -p atmega328p -c usbasp -P usb -B10

avrdude: Version 5.10, compiled on Jun 27 2010 at 00:21:42
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         Setting bit clk period        : 10.0
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: set SCK frequency to 93750 Hz
avrdude: error: programm enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.

How are you powering the rfm2pi during programming? Are you programming at 5v or 3.3v? 

There is only one power rail on the rfm2pi which is normally 3.3v as the rfm is not 5v tolerant. that same rail is connectect to the ISCP header so you must'nt inject 5v if rfm fitted. I don't know the programmer you have can it operate at 3.3v?

Paul

I think the programmer could operate only at 5v, but it has a jumper to disable the power from the programmer to the target, so I am programming the board mounted on the raspberry to power it. in the vcc pin on the rfm I read 3.3v so I think it's ok.

At least the rfm is safe, I do not know the answers to these 2 questions offf-hand but I wonder

Is the rfm2pi avr @3.3v able to communicate with the programmer@5v and vice versa?

Is the reset line free to be controlled by the programmer or is it being influenced by the Pi's gpio settings?

Paul

I don't know the response to the first question, I hope someone more expert could provide the answer

for the second question here http://wiki.openenergymonitor.org/index.php?title=RFM12Pi_V2#Flashing_the_Bootloader

is written:
To avoid accidental connection to 5V, the VCC pin on the ISP header is by default, disconnected. A jumper connection between the two adjacent pads must be made to connect the ISP VCC to the board VCC. On some ISP programmers, (such as the AVR MKII that I use) the VCC pin needs to be connected to initialise the programmer even though the programmer itself does not power the board. An easy way to power the board with 3.3V for programming, is to connect it onto the Pi's GPIO

so I think there should be no problems to program the bootloader with the gpio connected.

Of the reported part I don't understand the 
On some ISP programmers, (such as the AVR MKII that I use) the VCC pin needs to be connected to initialise the programmer even though the programmer itself does not power the board.
I don't have an avr mkii but could it be the same problem?

If you're powering the AVR at 3.3V it's important that your programmer drives the SPI pins at 3.3V.  I would imagine the same is also true for the RFM module (which is also sitting on the SPI bus during all of this).  Ditto for the /RESET line, both for the AVR and the Pi's GPIO signals.  You really don't want 5V near any of it.

Hopefully your programmer is sensing the 3.3V on pin 2 of the 6-pin header and using that voltage to drive all the other pins.  That's what Atmel's programmers do.  Assuming that's the case (so you're not over-volting anything) then Paul's suggestion about a conflict on the /RESET line is a good one.  You probably want to make that Pi GPIO signal an input during the programming process so that the programmer can control it unconflicted.

I just noticed the link in the avrdude output to the programmer webpage and from there a link to the Readme.txt revealed this 

"LIMITATIONS

Hardware:

This package includes a circuit diagram. This circuit can only be used for programming 5V target systems. For other systems a level converter is needed."

Paul

EDIT - this will apply to that programmer, if using a derivative then it may not be relevant of course.

ok, so I think that even if there are some usbasp with a voltage selector jumper mine is too much simple to do it, so it could be time to replace it for something better?

if yes, do you have a suggestion for a decent programmer without spending a lot of money? I don't use it so much to spend a lot on it.

Do you think that with the 5v programmer I have damaged the rf? the datasheet says it has maximum absolute vdd of 6V.

To avoid the possible issues with the gpio could I power the board directly with a 3.3 external power source?

I've had lots of joy with Atmel's own AVRISP mkII.  It's very safe when it comes to voltages.  It never powers the target but rather requires you to, and then it senses what voltage you've powered your target at and uses that voltage for the programming.

It's not so much max absolute Vdd that's of concern here, but max absolute voltage on a pin... that's typically Vdd+0.5V, in other words 3.8V if you were powering the board with 3.3V.  Even the AVR (which will run happily at 5V) can't cope with any pin higher than 3.8V when you're running it at 3.3V.  The GPIO pin on your RPi that drives the /RESET signal was also potentially exposed.

Or if you have some F-F breadboard link wires (6x) and you are willing to make some changes to avrdude, you could use the Pi as a ICSP programmer without any further expense, although not as easy as ordering a new programmer and plugging it into your existing setup but it's possible, that's what I've used in the past.

Paul

ok, in the meantime I have assembled another rfm12pi without mounting the rfm module and I have successfully uploaded the bootloader.

How can I check that it's all ok before soldering the rfm module? 

I have installed the low write version of emoncms on the raspberry but I had no time to open it yet.

ok, I connected the new rfm12pi to the pi and it seems to be alive, but in the emonhub I have the following log:
MainThread Opening hub...
2015-10-17 14:34:14,774 INFO     MainThread Logging level set to DEBUG
2015-10-17 14:34:14,776 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2015-10-17 14:34:14,782 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2015-10-17 14:34:16,790 INFO     MainThread RFM2Pi device firmware version: [RFM2Pi]
2015-10-17 14:34:16,793 INFO     MainThread RFM2Pi device current settings: 
2015-10-17 14:34:16,795 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
2015-10-17 14:34:17,799 INFO     MainThread Setting RFM2Pi group: 210 (210g)
2015-10-17 14:34:18,802 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2015-10-17 14:34:19,806 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2015-10-17 14:34:20,810 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2015-10-17 14:34:21,814 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2015-10-17 14:34:21,817 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2015-10-17 14:34:21,820 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2015-10-17 14:34:21,823 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2015-10-17 14:34:21,827 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT' 
2015-10-17 14:34:21,831 INFO     MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883
2015-10-17 14:34:21,844 DEBUG    MainThread MQTT Subscribed to channel' : ToEmonCMS
2015-10-17 14:34:21,848 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 
2015-10-17 14:34:21,853 DEBUG    MainThread emoncmsorg Subscribed to channel' : ToEmonCMS
2015-10-17 14:34:21,957 INFO     MQTT       Connecting to MQTT Server
2015-10-17 14:34:21,967 INFO     MQTT       connection status: Connection successful
2015-10-17 14:34:21,970 DEBUG    MQTT       CONACK => Return code: 0
2015-10-17 14:34:22,075 INFO     MQTT       on_subscribe
2015-10-17 14:34:23,092 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..26)
2015-10-17 14:34:23,214 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2015-10-17 14:34:23,332 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2015-10-17 14:34:23,455 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2015-10-17 14:34:23,570 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, with ack
2015-10-17 14:34:23,685 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2015-10-17 14:34:23,800 DEBUG    RFM2Pi     acknowledged command: <n> l      - turn activity LED on DIG8 on or off
2015-10-17 14:34:24,017 DEBUG    RFM2Pi     device settings updated: 65 i1 g210 @ 868 MHz  Lock: 1

it seems that the "Setting RFM2Pi frequency: 433 (4b)" is not working, as at the end it shows 868 MHz.

Even if I have not yet soldered the rf unit on the board it should work and set the right frequency I think.

Without looking closly at the sketch and JeeLib I can't recall what would be the expected behaviour without the rfm device. The settings may not get persisted if some sort of response is required from the RFM to verify the settings.

The "acknowledged command" labelled logs are the help text being printed to serial by the RFM2Pi as it doesn't understand a command given, hopefully it is the "Setting RFM2Pi calibration: 230V (1p)" it is objecting to as this is not used outside of the emonPi and can therefore be deleted from the emonhub.conf. However as is see no responses to the first 4 settings it isn't clear if there is no response to the first 4 and then objecting to the 5th or if it is objecting to the 1st until you amend the emonhub.conf.

It maybe easier to use a serial console and give it non-rfm commands to test it like turning the led on/off etc

Having said that, I'm not sure how much more you can test, it is clearly communicating over serial so vcc, gnd, rx and tx lines seem fine, as must the reset line as you have flashed the firmware, the only stuff left can only really be tested by installing the rfm, maybe you could use some short link wires to temporarily "tack" the rfm in circuit if you are nervous.

Paul

"maybe you could use some short link wires to temporarily "tack" the rfm in circuit if you are nervous."
Robin's energy diverter PCBs are laid out so that short wires are necessary to connect to the RFM module. It makes later removal very easy.

(Picture from http://www.mk2pvrouter.co.uk/)

ok, so it seems that the best thing to do is to solder the rf module in a temporary way to see if with the rf it works.

I will remove th  230V (1p) line too from the emonhub config.

with the minicom serial console it seems that no commands are recognized, every key I press I receive back the help text. 
reading the sketch for the rfm12pi here

https://github.com/mharizanov/RFM2Pi/blob/master/firmware/RF12_Demo_atme...

it seems that the handleInput (char c) prints the help if it receives a char that is not a number, a letter or a comma or if the letter is not a recognized command (default: showHelp();) so if I send only a number I should expect nothing back (the sketch sets the value and wait for another number or a command) but I get the help string.

ok, after an upload of the new version pf the rfm12pi sketch and some soldering it seems that the second board is now working with the rf soldered in a temporary way.
Now I need to verify if it's receiving something, but my emontx v2 seems to have some problems too.
The emontx v2 build guide states that the atmega328 sold with the kit are shipped with the optiboot 4.4 bootloader, but I bought only the pcb from openenergymonitor shop as I had some atmega at home but they have the standard bootloader, I have to use the optiboot or I can keep the standard one?

What do you mean by the "standard bootloader"?  What is it, and how did you flash it?  As far as I can tell, optiboot 4.4 is the standard bootloader if you're flashing it with the Arduino IDE.

ok, I didn't know this, so I have the right bootloader!

So now I have to figure out why it's not working!

From where I can start to make some throubleshooting? yesterday I tried to put the atmega on an arduino, I flashed the blink sketch and put the atmega on the board but I just figured out that the arduino sketch have the led on the pin 13 and the emontx on the pin 9, so the led was not flashing because it was not connected to the right pin.

I will probably try to edit the sketch and try again in the evening to check at least if the chip is well powered and if it's executing the sketches on the board.

I verified the crystal too and it seems that it's working well.

What are the symptoms again?  I've lost track of which hardware is working and which isn't.  I take it when the atmega was on the Arduino board it was flashing the LED ok?

yes, the atmega on the arduino flashes the led, so it seems that the chip is working.

when I upload the emonTx_CT123_Voltage sketch, put the atmega on the emontx and power the board nothing happens, I expect it to at least power up the led as in the setup() there's digitalWrite(LEDpin, HIGH);

I'm not particularly familiar with those sketches or the radio module, but it looks like it doesn't set the LED high until after it's returned from rf12_initialize().  I think your idea of running the blink LED sketch (after you've fixed the LED pin) on your emontx is a good one.    Provided that works, you can focus on why emonTx_CT123_Voltage is hanging before it gets around to turning on the LED.

If your blink LED sketch doesn't work, then look at Vcc, the crystal and the /RESET signal.  Sounds like you've already checked the first two, so maybe /RESET is being asserted (held low).

When referring to a sketch it sometimes helps if you include a link (or location) as there are many similar named sketches, this allows the sketch to be confirmed as "the right one" and ensures all are commenting about the same sketch.

Not getting an initial flash from a RFM enabled board usually means the RF initialization has failed, this can be due to a faulty rfm or soldering etc, but the most common cause (with many sketches) is the "#define RF69_COMPAT" incorrectly set before compilation. Does the emonTx v2 have a rfm12 or rfm69 fitted? 

Paul

hi,

I have #define RF69_COMPAT 0 in the sketch and a rfm12 fitted

this is the sketch:
https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxV2...
 

Can I try, after the simple blink sketch is working, to upload a modified version of the sketch with the two rf initialization lines commented out so I can see if the rf initialization is the problem?
I hope that the rf is not the problem, as removing it is a pain but I think that probably I will have to remove it

I believe if you comment out Lines 92 & 93 and line 130 it should run, but I've not tested that theory :-)

Paul

ok, so commenting out the three lines I should expect to see the led flashing at boot and the flash every a couple of seconds right?

Valerio

The LED will come on after it has initialised the radio module (or skipped that if commented out) and then go out after the first sample has been or would have been sent. Then the LED should flash every 5.2 s approximately (= 5 s sleep time + the sample duration).

You will need an ac voltage input, otherwise calcVI( ) will not run properly as it will not have an ac wave to time itself with. Therefore, your voltage input pin must be correct.

It will not affect your problem, but with the latest emonLib, you no longer need "settled" and the wait for the filters to settle.

ok, I will remember to connect the ac voltage input!

eventually there's a simple way to desolder the rf unit?

I have done all the tests above and the board seems to hang on 

rf12_initialize(nodeID, RF_freq, networkGroup);

I would not advise de-soldering the RF Module without a hot air gun - it is tricky to get off without lifting a pad or two in the process.

There is more debugging of the module in situ that can be done if you have access to a scope.

If you have a multi-meter you could check the vdd and grounds to the rfm and check for any shorts to neighboring pins etc (assuming nothing can be seen with a magnifying glass eg whiskers of solderetc)

Also is the rfm board orientated correctly? may seem daft but unfortunately it wouldn't be the first time one has been fitted 180° out! 

Paul

I checked the shorts on the neighbor  pins immediately after soldering the rfm and are ok, I checked ground and vdd pins (the two near the antenna pin) when I made the power check as written on the building guide and the rfm is correctly receiving 3.3v. I checked the module orientation too following the datasheet and the building guide so I think those issues could be excluded, anyway I will make all the checks again just to be sure. 
http://openenergymonitor.org/emon/emontx/make/assemble/buildguide22

I have a scope but I am not so familiar with this instrument, so I will try the debugging in emjay's post and use this as a learning experience on how to use the scope.

I attached a photo of the mounted module so you can check the orientation too

And just for fun and documentation here is a picture of the temporary soldered rfm on the rfm12pi to test everything some days ago.

the only thing I don't understand well in this post
http://jeelabs.net/boards/6/topics/1672?r=1735#message-1735
is where I have to put the "magic button". Now I am powering the board from the batt pins with a 3.3v regulated source so as far as I know I am not using the internal voltage regulator (is that what in the post is called LDO right?) so I can avoid using the button and simply plug and unplug the power to the board?

Sorry, that part of the debug instructions is aimed at a JeeNode (a similar design and layout).  This has an 3.3V LDO in the supply for both MPU and RFM that has current foldover protection. The "magic button" is a way to get glitchless control of this supply rail.

You really need a similar "clean" way to apply power to get the Power-on-Reset function of both chips to run successfully - there are restrictions on minimum rate of change of the voltage ramp. Simple plug/unplug is generally too "noisy" a method.

Perhaps some more detail on what is happening.  If the RFM gets through its internal Power-on-Reset function, it generates a clock output (CLK pin) preset to 1 MHz, derived from the onboard crystal, . This does not require any external set up through the SPI.  Getting this clock is a good sign of RFM health, it's absence suggests either very basic wiring errors (which you have eliminated) or a fried RFM.

Once the rf12 driver initialisation code is allowed to run, as part of the general register set configuration, the CLK frequency is changed to 1.67 MHz.  This requires SPI transactions to succeed - which is where you look stuck at.

Later, to save power since CLK is not used, the CLK pin output is disabled.

Edited: the frequency change is now done after the CLK pin is disabled, so no longer visible on the scope. The controlled disappearance of the CLK signal is still a good indicator that SPI transactions to the module are succeeding.

so given that I have a variable power source, could I start from minimum power (probably not enough to power the board) and progressively increase the voltage up to 3.3V so the rf module will power up when it will have enough power?
or could I wire the "magic button" between the gnd and v+ of the supply?

I have one of these cheap power supplies: https://www.youtube.com/watch?v=4H6iwiPIaJI (not specifically the same but something similar)

I uploaded a modified version of the sketch with a delay(10000) before the rf12_initialize(nodeID, RF_freq, networkGroup); to have some time to read the CLK before the initialization.

when I power up the board (raising the current limitation on the power source) I get the 1Mhz square on the CLK pin (the attached pic) but then when I get to the rf_initialize the CLK returns to 0 and remains there... what I have to check now? in the post linked it says:

No CLK change to 1.66MHz implies the RFM12B has failed software set up.

Suspect the SPI bus (connections and loading from other attached devices), any code that manipulates directly or indirectly the SPI bus.

but I don't know what to do... :(

Well the good news is your RF module is responding to SPI commands. I've scanned the current driver code and the CLK disable is now done before the change to 1.67MHz (which of course will no longer be visible). But at least the CLK disable was done, so nothing much wrong with SPI transactions.

I'm afraid at this stage it will take stepping through the driver code to see where the hang occurs.  Since the driver is a mix of base level and interrupt level code, it is not advisable to use the standard printf() tracing.  You can do direct writes to spare I/O pins though for tell-tale LED's.

Anything odd about the IRQ/INT line?  The driver can't get very far without the RF Module free to pull this down.

Yes, at least it's not completely dead!
I checked all the connections from the rf and the atmega, and all the rf used pins (SEL, SCK, SDI, SDO, IRQ) are connected to the right atmega's pins and there are no adjacent rf lines shorted together, so IRQ line seems ok.
I can check the IRQ line behaviour with the scope next time, what I should expect it to do?

If the IRQ line is not the problem how could I proceed? I know that it's a 5€ component and that could be cheaper to replace it with a new one but I'm here to learn, so if someone could help me I'm happy to proceed with some more debugging.

Ok, time to take the covers off the driver code. Pull down the most recent version of the source and look for the rf12_initialize() entry. You know you are getting past  the SPI call that turns off CLK from the scope evidence.

As I mentioned above, direct writes to spare I/O pins with tell-tale LED's are best to mark your progress through the code. Some hints here.

could I use the emontx internal led?
I can put in RF12.cpp a code block like 

digitalWrite(9, 1);
delay(200);
digitalWrite(9, 0);
delay(200);

every a couple instructions on rf12_initialize and count the flashes before it gets stuck, then I can isolate a narrower set of instructions (from the first after the last blink to the one before the next blink) and move the blinks between these instructions to drill down to the one that is blocking the driver?
Or the delay instructions could affect in some way the execution?

to modify the code I have only to modify the RF12.cpp file in the lib and it will be automatically uploaded when I upload the sketch to the atmega?

"to modify the code I have only to modify the RF12.cpp file in the lib and it will be automatically uploaded when I upload the sketch to the atmega?"

No, that is not enough. The IDE loads and keeps the library in memory. You must close ALL instances and windows of the IDE, and then restart it.

ok, I will try and report here what I discovered! thanks for the hints

Unless you put them to sleep (which is fairly hard to do accidentally) these AVR processors never really hang... they'll always be executing something.  The SPI bus has no concept of acknowledgement so even if a SPI device is totally unresponsive, the CPU won't hang... it'll just get back garbage (usually the pull-ups) from any SPI reads and SPI writes will be silently ignored.

So when looking for hangs, you're almost always looking for software loops that don't terminate  (or maybe IRQs that won't clear). A very quick perusal of rf12_initialize() here:  https://github.com/jcw/jeelib/blob/master/RF12.cpp#L622 makes me think there's only one opportunity for that routine to never return and that's this loop:

    while (digitalRead(RFM_IRQ) == 0)
        rf12_xfer(0x0000);

So putting your scope on the RFM_IRQ pin would probably be a good starting point.  If it remains permanently low, then that loop will run forever.

ok, I made some experiments and now more or less magically the initialization works, but now I have problems later on the 
rf12_sendWait(2)

I modified the codein this way:

void rf12_sendWait (uint8_t mode) {
    // wait for packet to actually finish sending
    // go into low power mode, as interrupts are going to come in very soon
digitalWrite(9, 1); delay(1000); digitalWrite(9, 0);delay(100);
    while (rxstate != TXIDLE)
digitalWrite(9, 1); delay(1000); digitalWrite(9, 0);delay(200);
        if (mode) {
            // power down mode is only possible if the fuses are set to start
            // up in 258 clock cycles, i.e. approx 4 us - else must use standby!
            // modes 2 and higher may lose a few clock timer ticks
            set_sleep_mode(mode == 3 ? SLEEP_MODE_PWR_DOWN :
#ifdef SLEEP_MODE_STANDBY
                           mode == 2 ? SLEEP_MODE_STANDBY :
#endif
                                       SLEEP_MODE_IDLE);
digitalWrite(9, HIGH); 
            sleep_mode();
        }
digitalWrite(9, LOW);
delay(200);
}

and I have another led blink on emontx_lib just after rf12_sendWait(2);
I can see that while executing the sleep_mode(); line the led is on for about 5-6 seconds, the the led goes off and the program stops responding (the led doesn't blink  as written in the emontx_lib and to upload a new sketch I have to disconnect the power).
At this point I really don't know where the execution goes, it doesn't continue to cycle as it doesn't execute the 1000ms blink at the start of the cycle, and it doesn't exits from the sendWait function as the next blink after the call to this function is not esecuted. The only point where it could be it's the rxstate != TXIDLE check, am I right? it makes the check the first time, enters in the loop, completes it in about 5 seconds, then it tests the while condition rxstate != TXIDLE for the second time and gets blocked there?

I think you're going to need some more curly brackets.  The code used to do something like:

while (rxstate != TXIDLE)
  if (mode) {
    do some stuff
  }

but you've changed it to:

while (rxstate != TXIDLE)
  digitalWrite(9, 1);

delay(1000);
digitalWrite(9, 0);
delay(200);
if (mode) {
  do some stuff
}

But even after you've fixed that error, judging by the comments in the original code, I'd guess your delays are going to significantly change the behaviour of the code.

yes, you're right, I missed the brackets, probably because I program for work and me and my team as a best practice always include the brackets even if, like in this case, them are not so needed.

I agree that the delays could change the behaviour of the code, so I will try to avoid them in some way, I don't yet know how, but I will think to something to avoid delays at least in the while loop.

ok, everything now seems ok, I removed the delays and all the led flashing I added to the code, so now I have the led flashing every 5 seconds, the problems now is that the rfm12pi doesn't seem to receive any data... i should get the data in the emonhub logs right?

how could I try to know if the rf are working properly?

I updated the rfm12pi firmware to the last with git pull and the command update-RFM12 in the RFM2PI directory of my pi but it didn't resolved. is that the right firmware for my setup?

at startup in my emonhub.log I have a lot of these:
2015-10-26 20:24:02,893 DEBUG    RFM2Pi     1 NEW FRAME : OK 0
2015-10-26 20:24:02,894 WARNING  RFM2Pi     1 Discarded RX frame 'string too short' : []
2015-10-26 20:24:02,905 INFO     MQTT       on_subscribe
2015-10-26 20:24:02,995 DEBUG    RFM2Pi     2 NEW FRAME : OK 0
2015-10-26 20:24:02,996 WARNING  RFM2Pi     2 Discarded RX frame 'string too short' : []
2015-10-26 20:24:03,097 DEBUG    RFM2Pi     3 NEW FRAME : OK 0
2015-10-26 20:24:03,098 WARNING  RFM2Pi     3 Discarded RX frame 'string too short' : []
2015-10-26 20:24:03,199 DEBUG    RFM2Pi     4 NEW FRAME : OK 0
2015-10-26 20:24:03,200 WARNING  RFM2Pi     4 Discarded RX frame 'string too short' : []

and then nothing else from the RFM2PI

Does the led on the rfm2pi flash when the emonTx led flashes to indicate receipt?

Is the emonTx and rfm2pi in the same group (usually 210 by default) ?

Is the emonhub loglevel set to debug? can you post the log entries for the rfm2pi interfacer setting up? it may be easier to resatrt emonhub using sudo service emonhub restart rather than scanning the file, 

Paul

no, the rfm2pi led is off, it flashes only a couple of times during the emonhub initialization
emontx and rfm2pi are on the same group (210 as default)
the log level is set to debug as you can see in the startup log.
 

here is the startup from the log file:

2015-10-27 06:39:38,682 INFO     MainThread EmonHub Pre-Release Development Version (rc2.0?)
2015-10-27 06:39:38,683 INFO     MainThread Opening hub...
2015-10-27 06:39:38,684 INFO     MainThread Logging level set to DEBUG
2015-10-27 06:39:38,685 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi' 
2015-10-27 06:39:38,688 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2015-10-27 06:39:40,694 INFO     MainThread RFM2Pi device firmware version: [RF12demo.12]
2015-10-27 06:39:40,695 INFO     MainThread RFM2Pi device current settings:  E i5 g210 @ 433 MHz
2015-10-27 06:39:40,696 INFO     MainThread Setting RFM2Pi quiet: 0 (0q)
2015-10-27 06:39:41,699 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)
2015-10-27 06:39:42,701 DEBUG    MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2015-10-27 06:39:42,703 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2015-10-27 06:39:42,705 DEBUG    MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2015-10-27 06:39:42,707 DEBUG    MainThread Interfacer: Subscribed to channel' : ToRFM12
2015-10-27 06:39:42,712 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT' 
2015-10-27 06:39:42,714 DEBUG    RFM2Pi     acknowledged command: > 0q
2015-10-27 06:39:42,717 INFO     MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883
2015-10-27 06:39:42,724 DEBUG    MainThread MQTT Subscribed to channel' : ToEmonCMS
2015-10-27 06:39:42,726 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg' 
2015-10-27 06:39:42,729 DEBUG    MainThread emoncmsorg Subscribed to channel' : ToEmonCMS
2015-10-27 06:39:42,821 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2015-10-27 06:39:42,827 INFO     MQTT       Connecting to MQTT Server
2015-10-27 06:39:42,832 INFO     MQTT       connection status: Connection successful
2015-10-27 06:39:42,834 DEBUG    MQTT       CONACK => Return code: 0
2015-10-27 06:39:42,923 DEBUG    RFM2Pi     1 NEW FRAME : OK 0
2015-10-27 06:39:42,924 WARNING  RFM2Pi     1 Discarded RX frame 'string too short' : []
2015-10-27 06:39:42,936 INFO     MQTT       on_subscribe
2015-10-27 06:39:43,025 DEBUG    RFM2Pi     2 NEW FRAME : OK 0
2015-10-27 06:39:43,026 WARNING  RFM2Pi     2 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,128 DEBUG    RFM2Pi     3 NEW FRAME : OK 0
2015-10-27 06:39:43,129 WARNING  RFM2Pi     3 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,231 DEBUG    RFM2Pi     4 NEW FRAME : OK 0
2015-10-27 06:39:43,232 WARNING  RFM2Pi     4 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,333 DEBUG    RFM2Pi     5 NEW FRAME : OK 0
2015-10-27 06:39:43,334 WARNING  RFM2Pi     5 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,436 DEBUG    RFM2Pi     6 NEW FRAME : OK 0
2015-10-27 06:39:43,437 WARNING  RFM2Pi     6 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,539 DEBUG    RFM2Pi     7 NEW FRAME : OK 0
2015-10-27 06:39:43,540 WARNING  RFM2Pi     7 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,663 DEBUG    RFM2Pi     8 NEW FRAME : OK 0
2015-10-27 06:39:43,664 WARNING  RFM2Pi     8 Discarded RX frame 'string too short' : []
2015-10-27 06:39:43,765 DEBUG    RFM2Pi     acknowledged command: > 1p
2015-10-27 06:39:44,118 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..30)
2015-10-27 06:39:44,224 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2015-10-27 06:39:44,344 DEBUG    RFM2Pi     acknowledged command: <nnnn> o   - change frequency offset within the band (default 1600)
2015-10-27 06:39:44,571 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2015-10-27 06:39:44,676 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2015-10-27 06:39:44,901 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2015-10-27 06:39:45,022 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2015-10-27 06:39:45,128 DEBUG    RFM2Pi     acknowledged command: <n> q      - set quiet mode (1 = don't report bad packets)
2015-10-27 06:39:45,249 DEBUG    RFM2Pi     acknowledged command: <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2015-10-27 06:39:45,577 DEBUG    RFM2Pi     acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
2015-10-27 06:39:45,700 DEBUG    RFM2Pi     acknowledged command: <addr>,<dev>,<on> k              - KAKU command (433 MHz)
2015-10-27 06:39:45,924 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2015-10-27 06:39:46,026 DEBUG    RFM2Pi     15 NEW FRAME : OK 0
2015-10-27 06:39:46,026 WARNING  RFM2Pi     15 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,148 DEBUG    RFM2Pi     16 NEW FRAME : OK 0
2015-10-27 06:39:46,149 WARNING  RFM2Pi     16 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,251 DEBUG    RFM2Pi     17 NEW FRAME : OK 0
2015-10-27 06:39:46,252 WARNING  RFM2Pi     17 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,375 DEBUG    RFM2Pi     18 NEW FRAME : OK 0
2015-10-27 06:39:46,376 WARNING  RFM2Pi     18 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,478 DEBUG    RFM2Pi     19 NEW FRAME : OK 0
2015-10-27 06:39:46,479 WARNING  RFM2Pi     19 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,601 DEBUG    RFM2Pi     20 NEW FRAME : OK 0
2015-10-27 06:39:46,603 WARNING  RFM2Pi     20 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,704 DEBUG    RFM2Pi     21 NEW FRAME : OK 0
2015-10-27 06:39:46,705 WARNING  RFM2Pi     21 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,828 DEBUG    RFM2Pi     22 NEW FRAME : OK 0
2015-10-27 06:39:46,829 WARNING  RFM2Pi     22 Discarded RX frame 'string too short' : []
2015-10-27 06:39:46,931 DEBUG    RFM2Pi     23 NEW FRAME : OK 0
2015-10-27 06:39:46,932 WARNING  RFM2Pi     23 Discarded RX frame 'string too short' : []
2015-10-27 06:39:47,055 DEBUG    RFM2Pi     24 NEW FRAME : OK 0
2015-10-27 06:39:47,056 WARNING  RFM2Pi     24 Discarded RX frame 'string too short' : []
2015-10-27 06:40:12,788 INFO     emoncmsorg sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1445928012
2015-10-27 06:40:12,924 DEBUG    emoncmsorg acknowledged receipt with 'ok' from http://emoncms.org
2015-10-27 06:40:42,729 INFO     emoncmsorg sending: http://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2015-10-27 06:40:42,944 INFO     emoncmsorg sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1445928042
2015-10-27 06:40:43,098 DEBUG    emoncmsorg acknowledged receipt with 'ok' from http://emoncms.org

and then it follows sending empty data to emoncms.org every 30 seconds

another consideration:

I made the antennas from an old ethernet cable with solid cores, and the antenna length is 165mm as I am using 433mhz modules, is this correct?

I'm also looking for a better avr programmer (for this and for future projects) but I found out that the avrisp mkII suggested by dbc some days ago seems to be no longer produced by atmel, could it be one of these clones a valid alternative? are them real clones of the original one with the same circuits and the same behaviour?
http://www.ebay.it/itm/Atmel-AT-AVRISP-AVR-ISP-mkII-In-System-Programmer...
It seems that atmel is now producing the atmel ice as a replacement of the avrisp mkII:
http://www.ebay.it/itm/ATATMEL-ICE-PCBA-debuger-Atmel-Ice-/111807273158?
I should go for the rock solid avrisp mkII (even if a chinese clone if the design is the same it seems a good programmer) or the new genuine atmel ice? the price for the two listings seems almost the same( some € more the ice)

I don't think the antenna should be a problem, a single solid core ~165mm sounds ok and I would presume during this debugging stage you would be testing the devices side by side, so it would need to be very "wrong" for a packet not to make it.

Can you use a serial console to check the actual serial traffic, there appears to be good comms between emonhub and the rfm2pi firmware since emonhub has displayed the firmware version and settings, unfortunatly almost all the firmwares have the same version so it doesn't confirm which firmware you are using.

It's unusual for empty packets to be processed,at all, without a received packet the rfm2pi shouldn't send anything, so I'm inclined to think it may be emonhub mis-parsing the data but I'm not familiar enough with the emon-pi version to be sure either way and the lack of an led flash on the rfm2pi  contradicts that,  

Paul

yes the pi and frm2pi are talking, as with minicom I can talk with the module, but it's not showing incoming packets when the emontx transmits, I tried to modify the group to 0 but nothing.
the Discarded RX frame 'string too short' : [] logs are displayed only at emonhub startup, then nothing except the emoncmsorg sending: http://emoncms.org... logs every 30 seconds.

The firmware I am using is the one that gets selected with the update-RFM12 script in the RFM2PI directory of the sdCard image so it should be the following (I Haven't the raspberry here to check that the repository is the right one)
https://github.com/openenergymonitor/RFM2Pi/tree/master/firmware/RFM69CW...
and the hex loaded by the script is the RFM12_Demo_ATmega328.cpp.hex

the station and base are on the same room at about 1 meter, I tried to put the rasp on the near room but it's the same.