Cumulus Support

So, for the last week or so I've set up a custom SQL insert to add some Davis reception stats to a table.

It's been working fine, but what I'm seeing is that once that value gets above 32767 (my guess is it's that value), the values inserted change to a negative number. It's just one value at the end of the day. Here's what I saw in the log file once I set it to debug:
I included the previous insert for context.

Any idea how to alleviate this?

Thanks.

Looks like you are using Signed smallint i.e. range -32768 to 32767
The range for Unsigned is 0 to 65535, should do the trick.

rogerthn wrote: ↑Fri 15 Oct 2021 3:28 pm Looks like you are using Signed smallint i.e. range -32768 to 32767
The range for Unsigned is 0 to 65535, should do the trick.

OK I changed that to UNSIGNED and it was set to BIGINT (I thought I set to UNSIGNED as part of my troubleshooting) but the snippet I provided was directly from the MXdiag file on debug; wouldn't that be value it was attempting to pass? It usually doesn't show up until the last record of the day (at 23:45) so I'll set it back to debug and look at it in the morning to see if it's passing the wrong value at that time.

BigOkie wrote: ↑Fri 15 Oct 2021 3:52 pm OK I changed that to UNSIGNED and it was set to BIGINT (I thought I set to UNSIGNED as part of my troubleshooting) but the snippet I provided was directly from the MXdiag file on debug; wouldn't that be value it was attempting to pass? It usually doesn't show up until the last record of the day (at 23:45) so I'll set it back to debug and look at it in the morning to see if it's passing the wrong value at that time.

BIGINT, Signed or Unsigned should be OK BUT
Maybe "Davis reception stats" is Signed 16 bit?

It is held in a "int" which is an alias for Int32, that has a maximum value of 2147483647.

I just fudged it to set the counter = int.MaxValue, then retrieved from the web tag and got...

{"DavisTotalPacketsReceived":"2147483647"}

I get the negative values every day, but I thought nothing of it really, as I don't log any of it.

Sorry I was at cross purposes here. This is the value coming from the console. Let me look at how it is being decoded....

Actually, looking at that log entry the console is using a signed 16 bit int to hold the value because it is sending "2D-33-32-35-37-39" = -32579

I'll add a correction in the next release of CMX to allow for this...

mcrossley wrote: ↑Sat 16 Oct 2021 1:09 pm Actually, looking at that log entry the console is using a signed 16 bit int to hold the value because it is sending "2D-33-32-35-37-39" = -32579

I'll add a correction in the next release of CMX to allow for this...

Is there a way to normalize that specific data or is it just not going to be accurate. Wonder why Davis would have done that. If it's any help I'm using 1.90 firmware on my Davis and would really rather not upgrade any further as I'm of the belief 'if it's not broke don't fix it'.

Thanks.

It should (might?) be possible to add a column and convert e.g. -32579 to a "proper" value?

Davis just messed up! Like you have found you do not notice until near the end of the day when the packet count can exceed the variable limit.

To convert the correct value you can just add 65536 to the returned value if it is negative.

mcrossley wrote: ↑Mon 18 Oct 2021 3:39 pm Davis just messed up! Like you have found you do not notice until near the end of the day when the packet count can exceed the variable limit.

To convert the correct value you can just add 65536 to the returned value if it is negative.

Yeah, I would have never noticed it before I was using the newer versions of CMX because then the time of day request (which also seems to reset the packet count as well as day rollover) came at 4am. Now it's configurable and I started doing it at midnight.

Thanks.