I have successfully built GLCD and Tx unit and have them talking OK. Have now built Emonbase and uploaded the Rx_SimpleRFM12B_demo sketch. Sketch compiles and loads OK but I don't receive any data from the Tx. Have checked the Node ID - TX is 10 and the network is 210. I monitor the serial and have added some extra print statements so I know it is looping OK.
I have checked voltage on the RF12B and seems OK 3.24V . I have resoldered all the pads OK.
Any suggestions what other tests I could do to determine the problem?
Should have said I have also tried the TX demo which I thought would screw up the GLCD readings as it would receive from both TX and Emonbase, but nothing happened.
#define freq ??
PayloadTX structure is the same (though you should get something even if that is wrong)?
Using this line on all three devices
#define freq RF12_433MHZ
Now the module is soldered in I can't check that the RF12B is actually 433MHz but that was what I ordered and what came with the Tx and the GLCD.
Payload seems to line up with everything else too.
How do I determine if the RF12B is u/s or if it is something else? Anyone tried to desolder one?
Sorry, I can't help you with testing the RFM12B.
To unsolder the module, you need to instantaneously heat all 14 joints together and lift the module away. I think you will need a very high-powered soldering iron and a custom bit that will reach across the module and melt all the joints on both sides. I would not even try using a solder wick or a vacuum 'solder sucker' because they will still leave enough metal behind to make a good joint.
There's this idea: http://dangerousprototypes.com/2011/11/14/desolder-smd-ics/ but I've no idea whether it would be satisfactory. The danger I see with this is it will not heat the joint quickly enough and lift the tracks on the main PCB.
It might be preferable to destroy the RFM12B (using say a Dremel) and desolder the remnants of each contact one at a time rather than risk greater damage to the main PCB. I think the moral is, always check before soldering.
I'll have a go with the clever bent wire idea, then the dremel. Problem is I don't even know that this is the problem and if I destroy the RFM12B, I may not find out. I won't buy a new one till I get this one off safely because I might be heading towards a whole new board :-( and there are none in stock. Double :-(
I wouldn't try and de-solder the module, it will probable break the module and the pcb pads. The chances are it's the correct module. Even if it's not it will still work with slightly reduced range. The frequency is set in software. You say you have the emonGLCD receiving data from the emonTx, this means the problem must be with the emonBase. I'm assuming you have the demo sketch on the same frequency and network group and frequency as the emonTx?
Have you double checked the RFM12B has been soldered onto the emonBase in the correct orientation? If all seems well then possibly you have a faulty module. While not impossible, this is quite rare, in almost 500 modules I've not had a single faulty one yet...
Hope you manage to get solve the problem. Email us through the shop if you believe you have a faulty unit.
Best of luck,
Definately soldered in the correct orientation. Just checked again. I have also resoldered all the joints and checked the supply voltage. I don't know what else to check.
Ha Ha. The problem is solved and is due to the incorrect placement of the 10uF capacitor step 25b. I incorrectly guessed the position of pin 2. Only when I looked up what a ISP pinout was did I find the truth. Whoops. Glad I didn’t cut out the RFM12B ! Perhaps an amendment to the build guide might save someone else the same mistake.
Thanks to all who made suggestions.
please make the amendment to the build guide, the webpage is free to edit for al users! So hopefully I don't make this mistake at my nanodeRF build (gonna solding it this weekend..)
I think it would be unwise to create a fork from Ian Chilton's original version (at http://ichilton.github.com/nanode/) unless there is good reason. And I don't see that there is. The photograph is fairly clear and the OP made a guess that turned out to be wrong. If there is an error, then I think it is with the silk screen on the PCB (i.e pins 1 & 6 are labelled which means it is possible to read the numbers in two ways and get 1 & 6 on diagonally opposite corners, and one way is wrong. In my opinion, 1,2 5 & 6 could be labelled which would remove all doubt. However, I don't believe this PCB design is controlled by openenergymonitor so a change in the immediate future is unlikely.
Open-source tools for energy monitoring and analysis. This project uses the GNU General Public Licence