OpenEnergyMonitor Community

Problems sketch V3.4 discretesampling ACK

Tags: #<Tag:0x00007f1be9850a00>

I did calibrate with success the latest 3 emontx units I received last week (20 V from reality is huge) and took the older one from early year I think to do the same (I wanted to avoid the emonhub fiddle)

but on this unit it goes bad … not sure why.
Am on Mac with Arduino program and your little usb adapter

when launch Verify I get this error

/Users/yoyo/Documents/Arduino/libraries/Jeelib/RF69.cpp:108:39: warning: ‘prog_uint8_t’ is deprecated [-Wdeprecated-declarations]
static void initRadio (ROM_UINT8* init) {

and upload ends with this error (I cut off after first attemp since it goes on for 10 times

Sketch uses 14,512 bytes (44%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,475 bytes (72%) of dynamic memory, leaving 573 bytes for local variables. Maximum is 2,048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

and that’s it, emontx is now a dead duck and I’m not good enough to figure out what happens or even where to start digging for a solution

help :frowning2:

(btw if needed to go quickly, teamviewer available)

Eric, I seem to remember reading somewhere that the Arduino IDE had been changed - it seems like a year ago but it was probably only months - to not accept some variable declarations that had previously been acceptable. I can’t remember the details now, but your error looks like that.
(I am using 1.6.8 (Linux) and don’t have a problem.)

The cure will be to change the declaration in JeeLib to one it does understand and accept - I would try changing
ROM_UINT8* to uint8_t*
and see if it accepts it and if there are any side effects.

for some other hints.

The problem surfaced last January, but this post seems to have escaped notice:

you mean edit in hard the RF69.cpp file ?


It looks as if adding this line at the top of your file/sketch might also work:


I am no expert on the Arduino IDE. One more thought: is your JeeLib up to date?

I think the libs are up to date as I installed them this morning from git

Edited the file and it works again to send the sketch though I seem to have lost other things in this as it comes up as node 35 with just rssi in it and nothing else instead as emontx3 … did I erase other parts ? guess by tonight I will have rebuild it from scratch lol

set the .cpp file back to original and added your suggestion #define etc, it loads also

still the problem that it comes up under a wrong node and ‘empty’ except rssi value … and very unstable as it pops up and off my pi

Node 35 means that the “ACK” bit is set - but you knew that! (It is not masked.)
The NodeID is the bottom 5 bits, (0 - 31), ACK is the 6th bit, so subtract 32 and you are back to the number you expected.

Can you go back to an earlier Arduino IDE - before December 2015?

Why was I able to edit node numbers and calibrate all the new emontx’s this morning and this older one not ?

extract of the log where you see a ‘normal’ emontx sending (one I did calibrate this morning)and the one messing … seems like it is not fully configured and the pi doesn’t really know what to do with it I guess

2016-12-18 14:13:34,116 DEBUG    RFM2Pi     13547      RSSI : -45
2016-12-18 14:13:34,116 DEBUG    RFM2Pi     13547 Sent to channel(start)' : ToEmonCMS
2016-12-18 14:13:34,118 INFO     RFM2Pi     Publishing: emon/emontx4/power1 55
2016-12-18 14:13:34,120 INFO     RFM2Pi     Publishing: emon/emontx4/power2 0
2016-12-18 14:13:34,122 INFO     RFM2Pi     Publishing: emon/emontx4/power3 0
2016-12-18 14:13:34,124 INFO     RFM2Pi     Publishing: emon/emontx4/power4 0
2016-12-18 14:13:34,125 INFO     RFM2Pi     Publishing: emon/emontx4/vrms 235.92
2016-12-18 14:13:34,127 INFO     RFM2Pi     Publishing: emon/emontx4/temp1 300
2016-12-18 14:13:34,129 INFO     RFM2Pi     Publishing: emon/emontx4/temp2 300
2016-12-18 14:13:34,131 INFO     RFM2Pi     Publishing: emon/emontx4/temp3 300
2016-12-18 14:13:34,133 INFO     RFM2Pi     Publishing: emon/emontx4/temp4 300
2016-12-18 14:13:34,135 INFO     RFM2Pi     Publishing: emon/emontx4/temp5 300
2016-12-18 14:13:34,137 INFO     RFM2Pi     Publishing: emon/emontx4/temp6 300
2016-12-18 14:13:34,139 INFO     RFM2Pi     Publishing: emon/emontx4/pulse 0
2016-12-18 14:13:34,140 INFO     RFM2Pi     Publishing: emon/emontx4/rssi -45
2016-12-18 14:13:34,143 INFO     RFM2Pi     Publishing: emonhub/rx/7/values 55,0,0,0,235.92,300,300,300,300,300,300,0
2016-12-18 14:13:34,144 INFO     RFM2Pi     Publishing: emonhub/rx/7/rssi -45
2016-12-18 14:13:34,147 DEBUG    RFM2Pi     13547 adding frame to buffer => [1482066814.108438, 7, 55, 0, 0, 0, 235.92000000000002, 300, 300, 300, 300, 300, 300, 0, -45]
2016-12-18 14:13:34,148 DEBUG    RFM2Pi     13547 adding frame to buffer => [1482066814.108438, 7, 55, 0, 0, 0, 235.92000000000002, 300, 300, 300, 300, 300, 300, 0, -45]
2016-12-18 14:13:34,149 DEBUG    RFM2Pi     13547 Sent to channel(end)' : ToEmonCMS
2016-12-18 14:13:34,857 DEBUG    RFM2Pi     13548 NEW FRAME : OK 3 251 73 0 0 0 0 0 0 5 2 184 11 184 11 184 11 184 11 184 11 184 11 0 0 0 0 (-30)
2016-12-18 14:13:34,859 DEBUG    RFM2Pi     13548 Timestamp : 1482066814.86
2016-12-18 14:13:34,860 DEBUG    RFM2Pi     13548 From Node : 3
2016-12-18 14:13:34,860 DEBUG    RFM2Pi     13548    Values : [18939, 0, 0, 0, 517, 3000, 3000, 3000, 3000, 3000, 3000, 0, 0]
2016-12-18 14:13:34,861 DEBUG    RFM2Pi     13548      RSSI : -30
2016-12-18 14:13:34,861 DEBUG    RFM2Pi     13548 Sent to channel(start)' : ToEmonCMS
2016-12-18 14:13:34,862 INFO     RFM2Pi     Publishing: emon/3/1 18939
2016-12-18 14:13:34,865 INFO     RFM2Pi     Publishing: emon/3/2 0
2016-12-18 14:13:34,866 INFO     RFM2Pi     Publishing: emon/3/3 0
2016-12-18 14:13:34,867 INFO     RFM2Pi     Publishing: emon/3/4 0
2016-12-18 14:13:34,869 INFO     RFM2Pi     Publishing: emon/3/5 517
2016-12-18 14:13:34,870 INFO     RFM2Pi     Publishing: emon/3/6 3000
2016-12-18 14:13:34,872 INFO     RFM2Pi     Publishing: emon/3/7 3000
2016-12-18 14:13:34,873 INFO     RFM2Pi     Publishing: emon/3/8 3000
2016-12-18 14:13:34,874 INFO     RFM2Pi     Publishing: emon/3/9 3000
2016-12-18 14:13:34,876 INFO     RFM2Pi     Publishing: emon/3/10 3000
2016-12-18 14:13:34,877 INFO     RFM2Pi     Publishing: emon/3/11 3000
2016-12-18 14:13:34,878 INFO     RFM2Pi     Publishing: emon/3/12 0
2016-12-18 14:13:34,880 INFO     RFM2Pi     Publishing: emon/3/13 0
2016-12-18 14:13:34,881 INFO     RFM2Pi     Publishing: emon/3/rssi -30
2016-12-18 14:13:34,882 INFO     RFM2Pi     Publishing: emonhub/rx/3/values 18939,0,0,0,517,3000,3000,3000,3000,3000,3000,0,0
2016-12-18 14:13:34,884 INFO     RFM2Pi     Publishing: emonhub/rx/3/rssi -30
2016-12-18 14:13:34,885 DEBUG    RFM2Pi     13548 adding frame to buffer => [1482066814.857171, 3, 18939, 0, 0, 0, 517, 3000, 3000, 3000, 3000, 3000, 3000, 0, 0, -30]
2016-12-18 14:13:34,886 DEBUG    RFM2Pi     13548 adding frame to buffer => [1482066814.857171, 3, 18939, 0, 0, 0, 517, 3000, 3000, 3000, 3000, 3000, 3000, 0, 0, -30]

Do they all use exactly the same sketch (except for NodeID)?

used IDE 1.6.2 instead 1.6.11 … same problem

used emonTxV3_4_DiscreteSampling_ACK

loaded the emonTxV3_4_DiscreteSampling (src) and same result

seems like some other part is missing but what ?

I don’t think I am able to help you any more, sorry. I have just updated my JeeLib, updated the sketch, and it compiles first time for me, with no changes.

Is Node 3 set up correctly in emonhub.conf?
(Or do you need to set it as Node 35?? - I know Paul’s emonHub works beyond Node 31, but I’m not sure about the Pi.)
Why is the voltage only 5.17 V
@pb66 should be able to help with the Pi.

In the file “RF69_avr.h”, there is this “#define

4 // prog_uint8_t appears to be deprecated in avr libc, this resolves it for now
5 #define __PROG_TYPES_COMPAT__
6 #include <avr/pgmspace.h>
8 #define ROM_UINT8       const prog_uint8_t

therefore it should work properly, and indeed it appears to do so for me. I do not understand why it does not work for you.
Line 5 directs the compiler to be backwards compatible (via the macro).
Line 8 defines ROM_UINT8 as a constant - of the type that’s now deprecated.
There has to be something about your set-up that means that this is not being read, or it is being ignored.

the voltage you see is when it is linked via the usb adapter and not with the line adapter …

Ok and here I’m slamming my head to the wall … nodeid is not emontxid … :head_bandage:
Sorry I didn’t see that before (and this morning I did make correct note off what was what …stupid me)

ok starts to behave some better though not yet there and I didn’t change a thing in emonhub.conf . I see different things according tx … what is the correct one ?
emontx1 and 2 have datacode=h
emontx3 and 4 have datacodes = h,h,h,h,h,h,h,h,h,h,h,L

why this difference and what is best to use since I use 4 identical emontx ?
Do I understand correctly I better use the long format datacodes ?

@Robert.Wall thanks for your patience here …
PS : other problem, a pin from the uart is making bad contact, need to keep the adapter well in place or it fails hence early problems… Murphy ain’t far

Forgive me if I have the wrong end of the stick, but in the initial post it looks to me like the ref to “prog_uint8_t” is a warning only as if this was a compile error it would not proceed to try and upload to the emonTx, resulting in a “avrdude: stk500_recv(): programmer is not responding” error.

From that first post alone it looks like a connection error, was the programmer fully home and the correct way round? was the led flashing? was the reset button being touched?

But I assume you’ve got passed that if you are seeing node 35. What emonbase are you using? the ACK bit not being masked was fixed along time ago in the rfm2pi firmware. but I have no idea about the emonPi firmware offhand.

How much older? is it an rfm69 or rfm12 based emonTxv3?

The correct one to use is the one that matches the sketch! Since it is undoing the encoding applied before sending.

datacode = h, means all data will be signed integers = an undefined but even number of bytes.
datacodes = h,h,h,h,h,h,h,h,h,h,h,L, means 11 signed integers and 1 unsigned long = 26bytes

now even worse … Murphy please let go :rolling_eyes:

flashed with nodeid =8 -> emontx3 in emonhub.conf

when I start it comes up under emontx3 (led comes up, then blinks 10 times) then it disappears from my inputs,then after 70 secs it pops up as node 40, then disappears again … led blinks every 10 secs …
When I restart he emontx it goes through the same cycle again …

What is the power supply to your emonTx? If you have an ac adapter and the voltage is low, and you have a RFM69CW, and a big data packet sent by radio, then the a.c power may not be enough. If you can, use the programmer power or the 5 V USB power.

same problem via the ac adapter (original from emoncms that works since month) and idem via adapter … how to say… puzzling
big data … rssi and vrms … nothing else attached for now …

ok, well finally I was fed up and pushed the reset button, sometimes …

problems in order solved

depreciation problem and related -> uart pins very sensible on this unit and needed to keep the little adapter very tight.

what sketch works on emontx V3.4 for me : -> loaded the emonTxV3_4_DiscreteSampling (src) sketch (not the other one I mentioned earlier)

set datacodes = h,h,h,h,h,h,h,h,h,h,h,L to all emontx nodes to have them all equal and not half/half

seems to work again … finally all the emontx calibrated for voltage

to Robert and Paul, thanks for pushing in the right direction

It wasn’t my fault!! :wink:


Jake Blues: I ran out of gas! I got a flat tire! I didn’t have change for cab fare! I lost my tux at the cleaners! I locked my keys in the car! An old friend came in from out of town! Someone stole my car! There was an earthquake! A terrible flood! Locusts! IT WASN’T MY FAULT, I SWEAR TO GOD!

1 Like