I have a recently purchased emonTx shield which is plugged into an Arduino Uno. I soldered the parts on and attempted to upload the Shield_CT1234_Voltage sketch but unfortunately it seems to be getting stuck on line 109: rf12_initialize(nodeID, RF_freq, networkGroup); The LED does not light (since it comes after this) and there is no output in the serial monitor apart from the intial info text. The sketch is set correctly for the RFM69CW and I also tried another RFM69 radio module in case I made a mess of soldering it on. I’ve also tried using some older versions of jeelibs without success.
I’m a bit stuck on how to trouble shoot it further.
I’m uploading the sketches by having the Uno connected to my laptop via USB, rather that by a UART programmer though I assume that doesn’t make any difference.
I don’t know Arduinos, so I can’t help there. But as you can see the start-up text, then I think that department is OK. In any case, even if the radio is not receiving data, it should initialise. Not initialising means either the radio isn’t receiving commands from Jeelib, or JeeLib isn’t receiving the responses.
Hopefully a silly question: Have you identified the orientation of the RFM69 correctly. There’s a page in Learn with photos - the obvious thing to look for is the antenna, which goes to the hole near the corner of the pcb into which you solder the wire whip.
Have you checked the jumper positions?
The USB port on the Uno is essentially a “UART programmer” anyway, so no, it will make no difference.
I’ve double checked the RFM69 orientation and that is correct. Jumpers are set to digi 10 and digi 2. Here is a photo just to be sure:
It’s beginning to look like a faulty RFM69CW. I see it doesn’t have a paint blob on it, I don’t know whether that is significant - they used to have a bronze spot, I believe it signified “Tested”.
If you haven’t done so, it might be worth checking the jumper settings against your particular Arduino. I’m not an Arduino expert, so this doesn’t help, it is about as far as I can help you.
One final test would be to comment out all the RFM lines, and check that the rest of the Shield works. I doubt if that will prove much, since there’s every indication that most except the RFM is OK.
Failing at rf12_initialize(nodeID, RF_freq, networkGroup) is usually that the radio module is not responding to the SPI bus. Note that the jeelibs drivers are switchable between the legacy RFM12B module and the RFM69CW module - the driving code and the SPI conversations are significantly different.
Check that you have set this line correctly:
#define RF69_COMPAT 1 // define this to use the RF69 driver i.s.o. RF12
Unless I’m mis-reading his original post, it looks like he’s already done that.
If the correct library build is confirmed, then it is ok to insert some debug code into static void initRadio() in RF69.cpp - the driver is still setting up ahead of the real packet transactions so there are no timing/interrupt nasties to worry about.
Dump out the readReg(REG_SYNCVALUE1) values allowing time to flush out the UART buffer.
The code is basically checking that both 0xAA and 0x55 can be written and read back to/from the RF module on the SPI bus (10101010 & 01010101) as a quick check for stuck bus line, clocking/chip select errors.
I can confirm that #define RF69_COMPAT is set to ‘1’.
Can you give some guidance on how to do the debugging you’ve suggested? I’m guessing a serial.println won’t do it for a cpp file.
Robert - I can confirm that if I comment out the rf12 lines it runs fine.
Do you have another power source you can try?
It has come up before now that the Arduino Uno’s can do funky things when powered with less than 7volts, we also know that the rfm’s are not very forgiving for undervoltage. If the power supply was borderline it would come as no surprise to me if the first symptom was the rfm failing to operate when everything else appeared ok.
Thanks for the suggestion. I’ve just tried with a 12v supply for the Arduino unfortunately without success (I checked the supply to the RFM which was a solid 3.3v, same as when powered by USB).
Apologies everyone, I just did some more checking with the multimeter and found a dodgy solder on the SDI RFM pin. It now appears to be working correctly
Sorry for the wasted time.