Sketch uses 23,832 bytes (73%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,656 bytes (80%) of dynamic memory, leaving 392 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.
and yet i cant get the display/leds to turn on, tried using a mini USB and an external 5v 2A power suply, and the FTDI cable with no success
Arduino IDE serial output is, nothing…
Heres a gallery of photos of the assembled board hopefully someone can help me find out if something is wrong
That is not surprising - there is no output programmed in that sketch.
Also, the warning is normal. The sketch uses almost all the capacity of the processor.
Did you run the Tester sketch at Step 21 in the build guide, before you soldered the display in position? Did it respond correctly at that stage?
You have an RFM69CW radio module, have you changed line 38 in the sketch?
Did you run the Tester sketch at Step 21 in the build guide, before you soldered the display in position? Did it respond correctly at that stage?
Thats the only step i skipped, i assumed the display should be working since it was “out of the box”
You have an RFM69CW radio module, have you changed line 38 in the sketch?
just tried this i set it up to 1 and … fixed
Seems i got worried about skiping step 21 and was looking for something to be wrong instead of keeping going with the guide, now i just need to keep reading in order to sync it with the emonTx, thanks Robert
That could have been a bad mistake, because correcting an error on the pcb is almost impossible after the display has been soldered in.
It receives the data direct from the emonTx, so check the nodeID of your emonTx, and make sure that appears in line 120: if (node_id == 10) ...
You may also need to change line 69. That data structure must match the equivalent structure in the emonTx sketch. It doesn’t matter what the variables are called, but you must have the same types in the same order. Also, you do not need to use the ones that you won’t display (pulsecount?), but they must be part of the structure. There is more about that here.
Got it working right away, last emonTx3.4 uses nodeID 8, i just changed line 120 from nodeID= 10 to nodeID= 8 and its working
I havent checked all the code in all sketches of the GLCD (yet), but im worried about the display not showing any backlight, nor the RGB leds working am i assuming these two features only work for the PV code?
What time is it (according to the GLCD’s internal clock)? If between 2200 and 0500, the backlight is turned off.
The GLCD gets the time from your emonBase, or from your emonPi, if you have one. You might need to enable the time in emonhub.conf (in the emonPi/emonBase).
The red and green LEDs are not used in that sketch. But you can easily add them. They are used in the SolarPV sketch, where you’ll also find a description of how the sketch works.
The Tester sketch will operate the LEDs and backlight.
Go back to the line after the one where you set the emonTx nodeID. The nodeID is probably 5 (check in emonhub.conf).
The 60 s update interval is commented out there.
(It is much more readable if you copy and paste characters, instead of a screenshot.)
What ID is the GLCD expecting now? Remember, there is one for the data from the emonTx, and one for the time from the emonBase. Both pairs need to match. 5 is now our standard for the Pi
#define MYNODE 20 // Should be unique on network, node ID 30 reserved for base station
#define RF_freq RF12_433MHZ // frequency - match to same frequency as RFM12B module (change to 868Mhz or 915Mhz if appropriate)
#define group 210
void loop()
{
if (rf12_recvDone())
{
if (rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0) // and no rf errors
{
int node_id = (rf12_hdr & 0x1F);
if (node_id == 8) {emontx = *(PayloadTX*) rf12_data; last_emontx = millis();} //Assuming 10 is the emonTx NodeID
if (node_id == 15) //Assuming 15 is the emonBase node ID
{
RTC.adjust(DateTime(2012, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));
last_emonbase = millis();
}
}
}
I assume 20 is the node for emoncms,
And 8 is the node for the Watts feed,
So in my case (emonTX) then 15 should be 8
and emonhub baseID should be 8
Yes, and that nodeID tells everyone where the message came from. So those if (nodeID == ...) branches in the emonGLCD sketch do different things depending on where the data came from.
The emonHub should have got the date from the Internet. If it does not, I think it normally means that there was a problem connecting to the Internet when the Base booted. I’m not an expert in that area, so hopefully someone who is can continue with you. If there is no Internet connection, then you need to set the time as normal.
The GLCD will keep its own time in between receiving time updates from the Base.
is probably a bit of overkill, the emonGLCD is not likely to lose much time in 60secs, the usual update period is 300, some might argue even that is too is still overkill.
thanks for all the answers apparently the problem was that the pi with the default image was setup in a different time zone what i did to fix this was to run in Super user, enable re-write mode and then reconfigure the timezone of Debian using the commands
sudo su
rpi-rw
dpkg-reconfigure tzdata
This way all the timezones appear on the SSH screen so I can select the one im at
Now theres 2 time zones, Local time (CDT) and universal time (UTC), after a reboot to the emonHUB and to the GLCD now its showing the local time correctly
Thanks for all the help Ill make sure to push and add the few info not portrayed in the GLCD build guide
Everything is working and i even translated a couple strings for my family
1.- Is it posible to increase the contrast of the LCD by pumping its voltage? (its usually possible to do this), i noticed a 12v port on the board so im wondering if i can tweak this, maybe even add batteries,
I believe the display is this www.lcd-module.com/eng/pdf/grafik/dogm128e.pdf
That says it is possible to change the contrast in software. I have never needed to change this, so I have not looked to see how. Your starting point will be the data sheet and the GLCD_ST7565 library. Actually, looking at the library header file, the answer is just a few lines down from the top of the file! Or look at the Tester sketch. So very easily changed.
Again, I believe that the cost of picking and packing the kit, the quantity sold and the difficulty in assembling the display (OK, you and I had no problem, others have found it hard) means that once the present stock has been sold, no more kits will be produced. Now that almost everyone seems to have a smartphone, and the emonBase is actually cheaper and via a web browser can give a lot more information, the decision does not surprise me. I shall be sorry to see it go, nevertheless.
