Archived Forum

Just as an update. I've also tried HomeEnergyMonitor_Old example sketch with the same results. i.e No display or any clue that its running.

Which versions of which libraries are you using? Memory in the GLCD is extremely tight and we recently had problems with the NanodeRF where the Ethercard library had grown over time with various revisions and added "features" and that expansion caused the sketch to fail. I know you're not using that library but I suspect a very similar problem.

Hi Robert,

As far as I know, its the latest of everything off  the hub. The only one I wasn't sure of is the link for the Dallas Temp device which points here. http://download.milesburton.com/Arduino/MaximTemperature/

I wasn't sure which one to download, so I got it from here instead. http://milesburton.com/Main_Page?title=Dallas_Temperature_Control_Library

What you are saying makes sense because I don't get the warning when loading the tester and that works. Do you think this is simply a case of digging around until I can find the smaller previous versions of the library items ?

OK, I'll throw the libraries I'm using into a zip file for you - not now but it will be within 24 hrs.

Thanks Robert.

Just one Noob question as well. Does it matter if I have other drivers ( libraries ) in the library folder ? 

I see I have more than just the 5 required libraries. e.g. GSM, Audio, etc

Does the sketch only load the ones it needs ?

Does it matter if I have other drivers ( libraries ) in the library folder ?  No

Does the sketch only load the ones it needs ? Yes, BUT it seems to ignore folder names. So you cannot rename a directory to (say) jeelib.latest and expect it to be ignored - which any half-decent system would do. If you want to keep the newer libraries, you must zip them and delete the original version.

I don't promise this will get you going, but it is worth a try. Let me know how you get on. It's possible to slim down the GLCD sketch if this does not work.

Hi Robert

I removed all my libraries and replaced with yours.

I now get this bunch of errors when I try to compile

Arduino: 1.5.6-r2 (Windows 8), Board: "Arduino Uno"

C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\x.cpp:252: error: prototype for 'void OneWire::select(uint8_t*)' does not match any in class 'OneWire'
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\/OneWire.h:135: error: candidate is: void OneWire::select(const uint8_t*)
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\x.cpp:464: error: prototype for 'uint8_t OneWire::crc8(uint8_t*, uint8_t)' does not match any in class 'OneWire'
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\/OneWire.h:187: error: candidate is: static uint8_t OneWire::crc8(const uint8_t*, uint8_t)
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\x.cpp:496: error: prototype for 'bool OneWire::check_crc16(uint8_t*, uint16_t, uint8_t*)' does not match any in class 'OneWire'
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\/OneWire.h:210: error: candidate is: static bool OneWire::check_crc16(const uint8_t*, uint16_t, const uint8_t*, uint16_t)
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\x.cpp:502: error: prototype for 'uint16_t OneWire::crc16(uint8_t*, uint16_t)' does not match any in class 'OneWire'
C:\Users\Lionel\Documents\Arduino\Sketchbook\libraries\OneWire\/OneWire.h:224: error: candidate is: static uint16_t OneWire::crc16(const uint8_t*, uint16_t, uint16_t)

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

There's obviously something changed in the OneWire library then! Until I check through the libraries, I don't immediately know what the problem is. The first step is to change just that library back to your "latest" version.

Later, I'll get the current versions and see how I get on with the HEM sketch.

Hi. The only way I can get it to compile is to use my OneWire library with everything else from your Zip file. ( The results are the same - No sign of life ) 

The OneWire Library I used came from this site: http://www.pjrc.com/teensy/td_libs_OneWire.html

Ahem....  I'd obviously renamed the files inside my OneWire library to disable it, and forgotten to change them back. X.h and X.cpp need to be renamed to OneWire.h and OneWire.cpp  (and remember to completely shut down the Arduino IDE and restart it). With that done, the current "HomeEnergyMonitor.ino" compiled for me and appears to run OK (It says 0w and 24°C - the 0w is not surprising as I haven't got an emonTx running.)

Sorry about that foul-up. I'll carry on and get the latest libraries and see if I can track down the problem.

Hi

Did the rename, deleted my directory, copied yours, shut down the IDE and restarted.

No errors on compiling other than Low Memory warning.

But the display is still the same. Dead as a Dodo.

If the test sketch didn't work I'd be checking my work, but it does everything it should.

That the test sketch loads (and works) is a good indication that your construction skills pass! Unfortunately, as you can't run it with my libraries, I'm a bit puzzled. My build reports "Binary sketch size: 27,260 bytes (of a 32,256 byte maximum)"  with no warnings (other than the expected unused variables etc). What numbers do you see? I'm using Arduino IDE V1.0.5 under Ubuntu Linux, not that it should make any difference except that the standard Arduino libraries might have grown bigger too.

[Edit] Under Windoze 8.1, Arduino IDE V1.0.5-r2, I can can still load and run it, sketch size is now 27,240 bytes (? ! ! !)

As you don't need the Beta 1.5.6 version for the Atmel 328P in the emonGLCD, is it worth dropping back to the 1.0.5 release? All the indications are that it should work.

Hi

I will try that now.

The text below is what appears in the black box of the IDE.

Sketch uses 24,722 bytes (76%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,643 bytes (80%) of dynamic memory, leaving 405 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur

Hi

Removed the latest IDE and installed 1.0.5

I now only get this in the black box

Binary sketch size: 24,700 bytes (of a 32,256 byte maximum)

I've just noticed that you report 27,240 bytes under Win 8.1  Why would mine be smaller ?

Maybe we have been chasing a red herring and I'm missing something rather than being over size.

I now only get this in the black box
  Binary sketch size: 24,700 bytes (of a 32,256 byte maximum)  That is all you expect to see.

I get 24,700 bytes now - yours was smaller because I'd got the templates.ino file that has the PV and DHW pages in it (same name, different file - Aargh!). But that makes it even more puzzling as my larger file ran quite happily.

Do you still have no display? Or is it no backlight? - The clock starts at midnight and is set by a radio message. The sketch turns the backlight off between 10 pm and 5 am, so you won't see a backlight for 5 hours unless you set the clock by a radio message from a base/server, although it will flash briefly as the sketch starts.

If still no joy, in the main sketch comment out:

rf12_initialize(MYNODE, RF_freq,group);

and

if (rf12_recvDone())
{
  ...  and the whole of the conditional block it controls
}

and right at the end

rf12_sendNow(0, &emonglcd, sizeof emonglcd); 
rf12_sendWait(2);

If the display works now, you might have a soldering fault on the RFM12B module or the module itself may be faulty.

Sir, you are an Officer and a Gentleman. You may take the rest of the week off.

As soon as I commented out the initialize the wireless bit, the display started working.

I found the solder pad next to the antennae pad had cracked horizontally breaking the correction. A quick re solder of all the wireless module pads and its working like a charm.

My day job requires me to be logical and methodical, but it made no sense that the test script worked, but the real one didn't. Until now of course when you realize that the test script doesn't have any wireless code.

Thanks for sticking with me.

All the best

Lionel

"Sir, you are an Officer and a Gentleman." Thank you! You could have added "persistent". I was thinking I need to figure out a way to test the RFM12B without everything hanging inexplicably, and then sell the idea to Trystan & Glyn.

"You may take the rest of the week off." No chance of that, I fear.

"My day job requires me to be logical and methodical"  Mine used to, and this (almost full time) one still does!

I've just checked - that pad was only the 3.3 V supply to the module - which explains a lot.

Hello. I am having a similar problem 

I have soldered two GLCDs 3 weeks ago. One worked fine for some time as I used "Tester", "Template" and Energy Monitoring examples and they all showed proper display. But all of a sudden it just stopped working. I didn't use it for a week or so and afterwards it again started working for a few hours.

The other one only worked when powered with the programmer (USB to serial UART) and not with the usb. Im not sure what is the exact problem.

Taking the second one first, that's clearly pointing towards a problem with either your USB power supply, your USB lead, the USB connector, or the PCB tracks between that and the point where the FTDI connector joins up. First check your power supply and lead. Then, with the GLCD powered off, you need to use a multimeter to check that you have continuity between the USB GND and all the places marked 0 V, GND, PWR- etc and similarly between the USB 5 V and all the places marked PWR, PWR+.

The first one sounds as if it could be a temperature problem. What stops working, the display, the LEDs, the backlight, the radio, or everything? Have you checked voltages when it works and when it fails? and is anything getting hot?

For the first one: When for example  I use the tester example the LEDs are blinking and the backlight is turned but no display. I am not sure about hte radio.

For the second one: The power cable seems fine as it worked for the first one. LEDs and backlight working as well. Here are the voltages

(W.R.T USB Ground)

GND=0

PWR += 32 mA but reducing

PWR -= 0

(W.R.T USB 5V)

GND= 31

PWR - = 31 mA

PWR += 0

It is reducing slowly to zero.

There is no need to post 4 times. I read the first one and deleted the rest, as they contribute nothing. But it does not help. I asked about voltages and temperatures. 31 mA is about right.

Have you switched your first and second units? Now you have me confused. Which is showing which set of symptoms? Have you looked at the circuit diagram and layout on the Wiki?

The unit that worked with the FTDI programmer and not with the USB supply: The 0 V and 5 V connections are common to both, so the fault has to be either the USB socket or the soldering or the PCB track. A continuity test should reveal it.

The unit that worked for a short time: Are the voltage multiplier electrolytic capacitors all the right way round (C8 - C12)? Check the PCB version against the notes in the construction guide, because there was a layout error in one version that has been corrected.

Ok to make it easy. LCD-A worked for a some time and LED-B only worked with programmer. I am using Version 1.5 GLCD. 

​For A:

When for example  I use the tester example the LEDs are blinking and the backlight is turned but no display. I am not sure about hte radio. I guess you are referring to electrolytic capacitors C13 and C14 but they are corrected in the V 1.5 for may be it is not the problem.

For B:

The voltage voltage is still decreasing and it is now 27 (and still decreasing). I will try to resolder the port and see what happens.

For GLCD A following are the voltages across LCD pins. I am running "tester" from the energy monitoring example lib.

1= 0.57v       

2= 0.46v       
3= 0.47v      
4= 0.53v        
5= 0.51v       
6= 0 v          
7= 1.26v        
8= 1.48v        
9= 1.72v        
10= 1.43v        
11= 1.56v        
12= 0.71v       
13= 0v              
14= 3.29v          
15= 3.29v           
16= 0.01 to 0.04v (Fluctuating)          
17= 0.01 to 0.03v                 
18= 3.27 to 3.28v           
19= 3.27 to 3.28v  

20= 0v  

These are a little different from http://openenergymonitor.org/emon/node/333.

GLCD A:
The voltages on pins 1-5 and 10-12 are an obvious concern. These are all part of the step-up circuit and voltage regulator for the LCD and clearly all need to be a lot higher for proper operation. The regulated 3.3 V supply looks OK, so I have to suspect those electrolytics C13-16 and possibly, though less likely, the disc ceramics C8-12. I'd also suggest you carefully examine the PCB for manufacturing defects - a broken track or a whisker of copper (or of solder) though it's going to be very hard to see anything on the display side of the PCB now it's assembled.

Well Robert What to say. GLCD A has started to work again. I have just tried to clean the joints and although I could not see anything (like wisker of solder or something) but there must be something so it is working now. The voltages are now much greater on pins 1-5 and 10-12. I will keep it running for some time.

It might be that the GLCD has been damaged in transit, but in my experience something that works intermittently, and especially that works after it's been handled, points to a bad joint. It could be that you have a pin or a component lead that is tarnished and hasn't taken the the solder properly, or the bad joint just might be inside the component itself. I think the capacitors I mentioned, and the GLCD pins they connect to, is where you should be looking.