Archived Forum

I've seen with mine that the choice of external power supply can be critical. In fact, I'm even of the opinion that a poor USB supply was responsible for frying one of my programmers.

Some USB chargers, for example, for phones are built to a very poor standard while USB ports on PC's have to meet the USB power source and sync specifications.

Try a different external supply and see what happens.

I've tried it with numerous supplies, even directly connected to the PC, - because we have more than one or two Pi's about here we are very aware of power supply variances :)

It's the action of plugging the UART adapter in to the programming header - and it makes no difference whether or not the adapter is connected to the pc that causes a reboot of the GLCD and hence kickstarts the script...

The script is definitely hung as the the on-screen timer isn't refreshed either

Bump to retrigger this thread, As it is still unresolved, (I kept quiet whilst the Jeelib challenges were fixed :) )

I can plug the USB to serial UART connector direct into the power supply that I am using, and it will boot up properly, just not when powered by the USB cable...

The script doesn't  look like it's hung, as the timer runs (the TX resolved that) however it isn't receiving / processing and data from the emonTx's or it's on board temperature sensor.

It has been suggested elsewhere that this behaviour, may be:

Avontech - your problem sounds like a reset issue since the reset line is connected to the header but not the USB socket. It may be that the fuses in the ATmega328 aren't programmed correctly for the internal reset.

Is this likely to be the cause?

If so, how do I go about viewing and configuring the fuses?

TIA

Avontech I have had the same problem. After quite a bit of time investigating I seem to have struck on a solution or at least I haven't had a reoccurrence since implementing it.

Of course as the emonGLCD is now operating as expected I have only restarted on a small number of occasions generally as I have developed the code for my purpose, but it has fired up fine on each occasion using the same power supply (obtained from the shop) as when it used to hang.

As I write I don't have access to the sketch so I will endeavor to post the relevant code later but the change I made that has made all the difference in my case was during setup(). I decided to initialize the RFM12B last after the calls to the glcd methods and the temperature sensor. I also placed a short delay before and after the call to rf12_initialize. My reasoning was to allow the other components to have started-up/reset etc for the first time and then initialize the RFM12B module also giving it some time to settle down. Notwithstanding I recall the the rf12_initialize code does a check to see if the device is ready.

Avontech maybe if you make a similar change in the setup() method this will work for you also.  

Whilst I was trying to troubleshoot this issue I also noted that much much rarely the emonGLCD would exhibit the same behavior when started via the programming header.

Apart from real basics the electronics side of this is outside my domain so I pursued trying to work out what what was happening via the code after all the emonGLCD did update the screen and display a temperature at least once.

I eventually determined that the RFM12B code was putting the processor into sleep mode from which it never resumed. This was when the emonGLCD was attempting to send the first temperature reading. The state machine indicated that it was attempting to send the first PRE bytes and nothing further happened. Eventually I concluded that no interrupts were being raised rather than an issue with the unit resuming once an interrupt was raised.

In the case when all worked correctly by the time the code tried to send this first reading there had normally been many RFM12B interrupts. I have a number of temperature nodes, emonTX and nanodeRF already deployed. In the case where it hung there were no interrupts. 

After reading about the differing quality of USB power supplies I tried a branded supply which came with an iPad and yes the emonGLCD worked. However this only raised a false hope as whilst it improved the chance of the emonGLCD working  it did still on occasion hang.

This did however make me wonder if the problem concerned the various components powering-up plus my choice of USB power supply which led me to make the change described above.

As noted it has worked for me. So much so I am about to build my second emonGLCD.

During this process I have tried various sketches but the latest HomeEnergyMonitor sketch on GitHub was used in my recent effort to understand what was going on and is the basis of what I have deployed at the moment. I first had this problem about the time the updated jeelib was issued for a previous issue with the RFM12B and have used the updated library since it was made available.

More than happy for someone to 'put me right' regards my conclusion but I hope this helps.

Tim

Hi Tim, thanks for those pointers, I'm running a custom written sketch as I have 2 emontx's each with 3 CT's to monitor 3 pv systems and the house, and display all that info on the screen.

Because of the other emonGLCD issues with the jeelib library I had disabled all the transmit options of the RFM12B module, though of course it is (or isn't :) ) still receiving.

If in the meantime you get access to your sketch please post :)

Many Thanks, Gordon

That works!

I changed the sketch by the moving the rf12 command to the end of the setup section and added delays;

delay(1000) 
  rf12_initialize(MYNODE, freq,group);
delay(1000) 

..

Many thanks.

Thanks for the fix, I've added it into the github examples in case this also effects other people. I've never had this issue but the only side effect is a second or so longer boot up...we can live with that! 

Cheers,

Gordon that was exactly the change I made to the sketch so glad to see it improved matters for you also. 

Would have replied earlier but I have been having fun with the nanodeRF_multinode_bulksend where a small(!) change has made it misbehave. :-(

Tim

Thanks for the fix, I've added it into the github examples in case this also effects other people. I've never had this issue but the only side effect is a second or so longer boot up...we can live with that!

Oh dear, I was hoping we’d all learned something from the “emonGLCD – Not responding” thread. This really isn’t the way to fix problems. It’s one thing to try something to get some more information about a problem but then you really need to find the root cause before incorporating the change as a permanent solution.

It may only be a couple of seconds delay now but if you apply this philosophy to all your problem solving you end up with slow, bloated code that nobody can improve because nobody really understands what it is doing in the first place.

OK, I’ll get off my soapbox now :)

Can I join you - on the soapbox?  Putting a delay in is fine if the cause of the problem is something not completing and there's no means of determining when it has, otherwise as you say it's messy and given time it will enter tribal memory and no-one will know the reason why it's there - and it will be retained even if the cause of the original problem is found and cured.