Archived Forum

Why are you casting rf12_data[n] to (unsigned char) before shifting? If you shift an 8-bit value eight bits, there's nothing left...

What's the type of *rf12_data? If it's smaller than int, its value should automatically be promoted to int when you apply the shift operator to it. I.e. don't cast it.

Why the abs()? Are there really negative values in the rf12_data array?

It's generally a bad idea to mix different types in C, because the rules for promotion and implicit type casts are pretty complicated. Use (long) on the arduino if you need the 32 bits; use (int) otherwise (e.g. for the loop variable i).

Don't use type casting unless it's absolutely necessary, and use -Wall when compiling. This way the compiler will help you find many issues.

For what it's worth, rf12_data is actually a pointer in the library to the start of the 66-byte data block. So unless you are sending and retrieving bytes, it needs either a cast or a union.

arvidb, "If you shift an 8-bit value eight bits, there's nothing left..." is a red herring. The intention is to shift an 8-bit byte from the arrray into the high order byte of the 16-bit integer, and that's OK. This line has been lifted out of the multi-node base sketch. The cast is OK because all you are trying to do is recover exactly what you put in at the other end, and you don't want to treat the most significant bit as a sign bit.

But I think that emoncms.org can only handle signed integer inputs. So if you feed it an unsigned,  you'll have to figure out how to handle it in the inputs and feeds pages.

As I see it, we don't know exactly what or where the problem is. My best suggestion is to hang a serial monitor on your base, and put a few lines in to output the values so that you can actually see what you are trying to send to emoncms. Then take it from there. What actually is your data, is it a consumption rate, or is it an accumulator (i.e. the meter reading)?

folks-thanks for the input. 

I think I do need to get in close and see exactly what I'm sending . and get rid of the abs() which I'd forgotten about..

arvidb's comment to avoid mixing types is very good advice  ; I'll try to simplify things

My payload from the emontx is an int(emontx voltage) and unsigned long accumator(pulse count). I'm converting the pulse count from the ElsterV100 to litres at the emontx and sending that over to the base. (code attached) but would really like to get a csv dump from the db and look through the inputs for both these variables; anyone know how I do that from emonemc.org?

Eamonn

try to attach again .....

You can get a dump of all the values of a feed by using 

/emoncms/feed/data?id=1   where 1 is the number of the feed.  This will deliver it to the screen in a json-like format but its easy enough to cut and paste into the spreadsheet of your choice where you can reformat it until your hearts content. 

On the feeds screen if you click on "Feed API Help" you'll see the options

A bit OT now, but: Robert is right about the "red herring", since the cast has higher precedence than the shift. The original code is:

  int num = ((unsigned char)rf12_data[i+1] << 8 | (unsigned char)rf12_data[i]);

and the steps done become:

1. Cast uint8_t (the type of *rf12_data) to unsigned char (should have no effect?)
2. Promote* type of value to int
3. Shift left 8 bits (will give incorrect result if MSb is set)

* See e.g. www.google.com/search?q=c+integer+promotion

May I suggest this code instead:

for (int i=0; i<n; i+=2)
{
  unsigned int num = rf12_data[i+1];
  num <<= 8;
  num |= rf12_data[i];

  ...
}

(Verified to compile only; not tested further.)

Edit: Show code correctly.

can't seem to get certain feeds data.

Am I right in thinking the following should get me everything for feed 2499 from

01 Aug 2012 00:00:00 GMT to 01 Oct 2012 00:00:00 GMT?

http://emoncms.org/feed/data?id=2499?start=1343779200&end=1349049600

I only get a [] returned, and can see the data clearly in the charts.

strange... other feeds work ok - just seems to be an issue with the unixtime spec.

thanks a lot,

Eamonn

they look right to me.  You don't need to add the start/end

http://emoncms.org/feed/data?id=2499 should dump all the data for the feed.

You can then look at the timestamps and see whats happening 

"Is there a way to post code on this forum? "

Two ways:
either attach a file (best if it is more than a short snip - i.e longer than this!) - Note my post about making it visible at http://openenergymonitor.org/emon/node/841#comment-7895

or paste the code in, switch to plain text editor and surround it with <pre> </pre> tags

Hello,

I have a Raspberry Pi with an image I created over Christmas (so must be whatever was latest around then).

It's been running pretty happily since then and I'd now like to get some data off and put it in Excel or equivelant in order to play around with it a bit.

I've tried the suggestion from ukmoose "/emoncms/feed/data?id=1   where 1 is the number of the feed" where I put that in the browser preceeded by the RPi IP address but I get a message on emoncms "Message: Permission Denied".

Anyone got any idea how I get permission?

I was also thinking of putting phpMyAdmin onto the RPi but it seems like it might be complicated to link it to the already existing databases so I've chickened out for now.

Thanks for any help.

Yes, append your API key "/emoncms/feed/data?id=1&apikey=[YOUR API KEY] " to the request. (Probably the read-only one for safety).

EnergyRnR did you ever get to the bottom of your original issue?

I just happened across this thread and looked at your sending code.  One possible issue is that in this line:

WaterMeter.W_litres=(pulseCount)*0.25;

the read of pulseCount is not atomic on a processor like the AVR.  

pulseCount is an unsigned long so you're at risk of the ISR firing while the above code is reading pulseCount.  This can lead to inconsistencies if the ISR's

pulseCount++;

results in a carry from one byte up to the next byte while your process level code is fetching those bytes.

In addition to that problem, you should also tell the compiler that pulseCount is volatile.

Thanks a lot for that. I had 2 problems, (....apart from some serious personality defects, but this isn't the time or place :-) )

 - was using litres in my payload and hitting int overflow. I'm now using m3 and will never get near the limit, unless there is some serious tea drinking going on!   casting it as an int like this - WaterMeter.m3=int((pulseCount)*0.00025);

- was not declaring the pulseCount variable as volatile, so this is now sorted. Has anyone tried usint the <utils/atomic.h> lib. Seems to be similar to using the nointerrupts(), interrupts() wrappers but I haven't had time to try it out. Apart from the volatile declarations, would it also be good coding practice to always use those wrappers? I haven't...

Has anyone tried usint the <utils/atomic.h> lib. Seems to be similar to using the nointerrupts(), interrupts() wrappers

Either will work... they both basically do the same thing.  

Apart from the volatile declarations, would it also be good coding practice to always use those wrappers?

Yes,  you need to do both as they each solve a different problem.

volatile tells the compiler not to use a local register copy of a variable, but rather read it from (or write it to) memory each time you access it in your code.

The atomic stuff (doesn't matter whether you use atomic.h, or nointerrupts()/interrupts(), or cli()/sei()) ensures that when you're reading a variable larger than 1 byte, you get the entire variable snapshotted in one consistent state.

thanks for that.