Archived Forum

It does sound like a problem with your RFM12B (is that what you have?) radio module. I cannot remember anyone reporting an issue like this, that was not traced to a faulty radio module or a bad connection to it.

I have this:
http://it.farnell.com/rf-solutions/alpha-trx433s/rf-module-transceiver-f...
I read on the oem site when I bought all the components that these were the same as the RFM12B, the radio seems to be not entirely faulty as without the sleep stuffs the pi sometimes receives the data. I ordered some RFM69CW but they will arrive in 2-3 weeks so I would try to make it working with the RFM12.
I have understood correctly that I can mix RFM12 and RFM69? for example have the RFM12 on the pi and RFM69 on the tx?

That module does indeed look like a RFM12B. Do you have an emonTx, or an emonTx Shield and Arduino, and if so, which Arduino?

Yes, the RFM12B and RFM69CW can work with each other.

This "the radio seems to be not entirely faulty as without the sleep stuffs the pi sometimes receives the data." is what is confusing me. Usually, a fault with the radio module or the soldering will result in the sketch stopping forever at the point where it initialises the radio module.

rf12_sendWait(2); waits for the send to finish - this means blocking the processor and preventing it from continuing until the message has been sent. It is this that makes me think that the library cannot detect that the radio has actually finished sending the message, so it waits.

rf12_sleep(RF12_SLEEP); only sends the radio to sleep.

Taking those commands out will allow the loop to run, but may result in incomplete messages, which emonHub will reject (but log).

@Robert,

> rf12_sendWait(2); waits for the send to finish

Does this routine wait for a "quiet" channel before starting the send?

I don't think that's its function. It's hard to see exactly how it operates, as it means chasing interrupts, but it doesn't wait to send, it waits for the send (which I presume is - it must be - interrupt-driven) to complete before returning. [In the RFM69CW, there's a buffer to look at and when it's empty, it's safe to release the processor to continue.] So it's quite possible that by taking this out, Valerio is sending incomplete messages but sometimes a complete one gets through and is decoded. It would be worth trying any sort of wait to see if the messages get through. 

If you look at MartinR's PLL sketch, you'll see he sends 3 dummy bytes after the end of the message - I think that's to achieve the same end. My 3-phase sketch also has Martin's code - and the '69 equivalent.

Hi,

I have ad emontx , not the arduino shield.

The fact that it's sometimes sending confuses me too...

I forgot to mention that I have added a delay(1000) in place of the rf12_sendWait(2), so the sketch is waiting 6 seconds between the loops (delay(1000) + Sleepy::loseSomeTime(5000)). Could this be the problem with the data sent only sometimes? If I comment out the delay(1000) and leave only the Sleepy::loseSomeTime(5000) the loop is continous (without waiting 5 seconds). To "monitor" the loops I added a led flash in the loop().

There's another way to wait for the message to be sent? could be the delay(1000) that is stopping the sending process? 

"I forgot to mention that I have added a delay(1000) in place of the rf12_sendWait(2), so the sketch is waiting 6 seconds between the loops (delay(1000) + Sleepy::loseSomeTime(5000)). Could this be the problem with the data sent only sometimes?" .... "could be the delay(1000) that is stopping the sending process? "

I don't think so. I've loaded that demonstration sketch (g_TransmittingData.ino) into an emonTx V3.4 with RFM12B radio and it works just fine for me with delay(1000) in place of rf12_sendWait(2); sending every 6 s or so without fail.

"If I comment out the delay(1000) and leave only the Sleepy::loseSomeTime(5000) the loop is continous (without waiting 5 seconds)."

I too see that behaviour. It is not right, but JeeLabs say that if an interrupt occurs, loseSomeTime will return immediately, so I'm guessing that the RFM12B is firing an interrupt inside that first second. I find mine works most times with delay(4), never (does not send at all) with delay(3) or less, and always works with delay(5). That's with a 4-byte message. If I increase the message to 10 bytes, it sometimes fails with delay(5). This demonstrates what rf12_sendWait( ) should do.

I think all this is pointing to a hardware problem with your radio module, or the connections. Have you looked very carefully at the soldering - with a magnifying lens - and checked every joint? Did you buy the emonTx assembled with its radio from the shop, or did you add the radio yourself?

I bought only the pcb and some other parts and added the radio myself, as I had a problem with a radio in the pi I soldered  in a "temporary" way on this board to check the radio before soldering it permanently, I checked all the joins when I soldered them, I will do it again when I will be back home just to be sure.
With the delay > 5 you are always receiving the packets on the other side? so the fact that I am not always getting the packets to the raspberry is not caused by the delay.

I was using an emonGLCD running my own diagnostic sketch to check the transmissions, I did not notice any failures when the delay was long enough to be sure that the message had completed sending. "so the fact that I am not always getting the packets to the raspberry is not caused by the delay." - Yes, I think that is correct.

Is there another transmitter nearby on the same frequency band that could be 'jamming' your emonTx? - if you have the delay and not sendWait( ), then while it does not mean that your transmitter always works, it could be working and something else is corrupting the message.

Hi,

I rechecked everything and there were no shorts, but yesterday it started to deliver all the messages, so I added the sleep and then the send_wait and all is working except that after some time it gets stuck again and the tx stops working, if I power down and power it up again it starts again and stops after some time (less than an hour of 5-sec transmissions)

This has all the signs of a faulty connection. You handled and checked it, then it worked for a time. You left it for a time and it stopped working. I wonder whether there is a hairline break somewhere, that connected when you handled it and then broke the connection as something cooled or relaxed back into position? Can you check continuity on all the tracks that connect to the RFM12B module - and while you are doing that, bend and twist the PCB so as to stress the joints and the tracks. 

If Robert's suggestion of very close track examination show nothing, there is a further possibility.  If the catalog photo is accurate, the radio module is the 'epoxy blob' type.  The silicon die is flipped and pushed directly against pads on the PCB, then the epoxy holds this in place and (mostly) keeps out contaminants.

If the module has been stored for long periods in high humidity, the chip to pad interface can be compromised during soldering and give symptoms all the way from intermittent operation to completely dead.  Once in a while you can actually demonstrate this by pressure on the blob restoring function for a time.

Later versions from Hope RF moved away from the 'blob' and used conventional lead-frame packaging with welded bonding wires.

hi all, I'm back here to update you with some good news as finally it's working, I don't know why but after checking everything another time and "bending and twisting the PCB" at the end it started working properly, so I uploaded the power+voltage sketch, calibrated everything and saturday morning I installed it on the main panel and from then it's working ok! 

Thanks to all for the quick support!!!

I modified the sketch to use the Sleepy::loseSomeTime(5000) instead of the delay as it's consuming much less power (I think is has been commented on the github code for the 2.5 board that is powered directly by the ac adapter).

For now the board is hanging from the panel, I am now looking for a solution to put it somewhere less visible. if I cannot find sufficient space inside the panel do you think I can extend the CT wire or it will cause problems to the readings? I don't have solar or other, so I am evaluating the idea to try to design a "small as possible" single CT + voltage board, do you think it could be useful for someone else too?

If extending the CT cable is not a solution do you think I can extend the ac voltage cable?

First, don't trust it. What you describe exactly fits a bad connection somewhere. You have a badly soldered joint or the problem that emjay described. I can almost guarantee that it will come back, my guess would be in about 2 years' time when a bit of oxidation sets in.

[I once spent two years trying to find a badly soldered joint in an audio amplifier - every time I as much as touched the screws holding the lid on, the problem went away. It was only after the joint had tarnished enough for the fault to remain while I got inside that I could find the problem, one touch with the iron and it was fixed.]

You can extend either or both cables. The CT is a current source (unless you have one with an internal burden) so voltage drop isn't a problem, but if you're extending it by more than a metre or two, you just need to get the screening right. I've repeated what you must do many times here. Voltage drop with the ac adapter, if it's also the power supply, might be a problem if you use the thinnest of wires, otherwise that too will be fine. 

I don't think many people would want a single channel board, most of those who aren't happy with the emonTx want many more channels than four. 

Thanks for the explanation.

i will not trust it, it's just to get a visualization of the data, so if it one day fails and stop sending data the only problem will be that I will not know how much I'm consuming, and the rf module is still "temporarily soldered" so there's the possibility that I will work on the board again to solder it. If it would work for 2 years then I will surely know if I really need it and then if I will need to replace/rework it or not.

I have a ct bought from the oem shop so it should be a current source, and the burden is on the board. I have a relatively small pcb-mountable ac ac adapter, from what I can find it's 9V 222mA, the one sold in the shop is 666mA, do you think it could be used for ac measurements? I think it could be a little underpowered to also power the board (and the tx v2.2 could not be powered from AC so it should need a board redesign) am I right?
My problem is that I can't fit the standard pluggable AC adaptor in the panel, so I need to move the adaptor away and fit the rest in the panel or move everyhing away, extend the CT cable and plug it or use the pcb ac adapter and try to fit everything in the panel.

The 9 V adapter should be fine for the ac measurements, but if you have an emonTx V2, then that needs a separate 5 V d.c. supply to power it. As your adapter isn't the standard one, you'll need to recalculate (or adjust by trial and error) the voltage calibration coefficient so that your emonTx reads the correct voltage. All that is in Resources > Building Blocks.

The problem with powering the emonTx from the ac adapter isn't so much power (200 mA is more than enough), but you can only have a half-wave rectifier to get the d.c., and the current pulse when the reservoir capacitor (which needs to be twice the size you'd expect) charges causes a dip in the voltage wave that makes it inaccurate. Therefore you need an adapter that's capable of delivering a short, high-current pulse without too much dip, and you need to stretch the current pulse as much as possible to limit the amplitude.

the voltage calibration is not a big problem, I did it for the node that is now running.

could a large capacitor make it more stable? if I remember well the moment when the circuit draws more current is when the rf is sending, and it's not in the same moment as when it's reading the voltage (the next voltage reading is 5-10 seconds after, so the capacitor should be recharged in that time?).

No, a large reservoir capacitor makes no real difference, the problem is the current charging that capacitor. Every cycle, you need to restore the charge that's drained away running the emonTx for the last 19 ms or so, and it's that 1 ms pulse of current that distorts the voltage wave while you're measuring the voltage. I've published a simulation showing the dip, which a search should find for you.