Hello.
In our operations we have several CR1000X, and a CR3000 dataloggers, connected via ehternet to a 4g-router, accessible to us. I'm no expert on the devices and programming language, so we wanted to ask for help.
We've noticed something: the snippets of code that we use are similar; in the CR1000X we get the expected value in the JSON, a string with "YYYY-MM-DD hh:mm:ss", but the CR3000 returns for that value an int value, aroudn 4 million, that I cannot interpret as either a pointer or an offset from a given epoch, and would need to be converted.
CR3000 has FP2 as the datatype, CR1000X as IEEE4.
In the CR3000 the AirTC is defined everywhere as FP2.
CR3000
Datatable definition
DataTable(DoceHora, True, -1)
DataInterval(0, 12, HR, 10)
Minimum(1, AirTC, FP2, False, True)
FieldNames("tMin12H,tMin12Hora")
Maximum(1, AirTC, FP2, False, True)
FieldNames("tMax12H,tMax12Hora")
EndTable
Part of the JSON fill function.
json_field_labels(12) = "tMin12Hora" If output_doce_hora Then json_field_values(12) = DoceHora.tMin12Hora(4, 1)'comment Else json_field_values(12) = "" EndIf json_field_labels(13) = "tMax12H" If output_doce_hora Then json_field_values(13) = format_number_json (DoceHora.tMax12H) Else json_field_values(13) = "" EndIf json_field_labels(14) = "tMax12Hora" If output_doce_hora Then json_field_values(14) = DoceHora.tMax12Hora(4, 1)'comment Else json_field_values(14) = "" EndIf
CR1000X
DataTable
DataTable(DoceHora, true, -1)
DataInterval(0, 12, Hr, 10)
Minimum(1, AirTC,IEEE4, false, 1)
FieldNames("TMin, TMinHora")
Maximum(1, AirTC,IEEE4, false, 1)
FieldNames("TMax, TMaxHora")
Maximum (1,ff,FP2,False,False)
FieldNames ("ff12HMax")
SampleMaxMin (1,dd,FP2,False)
FieldNames ("dd12HMax")
EndTable
JSON Fill function
json_field_labels(11) = "tMin12H" If output_Doce_hora Then json_field_values(11) = format_number_json(DoceHora.tmin) Else json_field_values(11) = "" EndIf json_field_labels(12) = "tMin12Hora" If output_Doce_hora Then json_field_values(12) = DoceHora.TMinHora(4, 1) Else json_field_values(12) = "" EndIf json_field_labels(13) = "tMax12H" If output_Doce_hora Then json_field_values(13) = DoceHora.tmax Else json_field_values(13) = "" EndIf json_field_labels(14) = "tMax12Hora" If output_Doce_hora Then json_field_values(14) = DoceHora.TMaxHora(4, 1) Else json_field_values(14) = "" EndIf
The tMin12Hora, tMax12Hora, TMaxHora, and TMinHora are the timestamps on which the maximum/minimum was recorded. The tMin12H and tMax12H hold the respective temperature values, and they are being rescued properly
We would like to properly rescue in the CR3000 the timestamp of the value (in a record), but the 'DoceHora.tMax12Hora(4, 1)' instruction returns a number.
The only difference I see is the datatype: FP2 vs IEEE4; I would like to know how could I access for the CR3000:
- the timestamp where the min-temp and max-temp in the 12 hour interval have been stored.
- or if I have to convert it from the number to a datetime string, and if there is a primitive function for that, or a codesample to perform myself the conversion ( we already have defined a format_number_json subroutine).
Kind Regards,
If you are getting an integer for time, I expect it is seconds since Jan 1, 1990.
Hello, JDavis.
Regretfully, I'm not an expert nor have any campbell training courses. because of bugdet related reasons; my formation is in Computer Science though, so I'm trying to get this right to avoid 'wasting' a good datalogger.
According to this, the number should be in the order of 1 billion and something (1.044.000.000+)
https://www.epoch101.com/seconds-in-1990
But the CR3000 output is this: (JSON sample, generated by the datalogger itself)
{ "codigoNacional":"330114",
"fecha":"2023-01-31",
"hora":"20:13:00",
"dd":"211.4868",
"ff":"11.88699",
"dd02Min":"198.6171",
"ff02Min":"11.11548",
"dd10Min":"202", "ff10Min":"9.91", "ts":"30.17",
"tMin12H":"15.04",
"tMin12Hora":"4951184",
"tMax12H":"25.4",
"tMax12Hora":"4950372",
"td":"11.23", "p0":"956", "qfe":"956.178", "qff":"1010.407", "qnh":"1013.678", "rNeta":"388.5", "hr":"31.12037", "rr":"0", "rr6H":"0", "rr24H":"0", "U10":"-1.283", "V10":"-5.553", "W10":"-0.325", "TV10":"28.29", "SU10":"1.258", "SV10":"1.525", "SW10":"0.706", "ST10":"0.583", "CUV10":"0.8880001", "CUW10":"0.177", "CUT10":"0.08000001", "CVW10":"0.59", "CVT10":"0.486", "CWT10":"0.239", "U30":"-1.433", "V30":"-6.962", "W30":"-0.139", "TV30":"27.89", "SU30":"0.975", "SV30":"1.032", "SW30":"0.928", "ST30":"0.478", "CUV30":"0.502", "CUW30":"0.006", "CUT30":"0.138", "CVW30":"0.294", "CVT30":"0.328", "CWT30":"0.186", "te02":"30.41", "te10":"28.99", "te30":"28.3" }
the values tMin12Hora and tMax12Hora are weird:
Even if they were in "microsecon
Maybe because of the datatype FP2 we are getting some overflow.
Is there any way to reference the timestamp field of the DataTable (named DoceHora) when the tMin12H was recorded ?
Also, when I was looking at the manual for the CR3000 (rev. 9/07), I found the Tablename.timestamp(m,n) definition which has ([1...7], n), but the value doesn't match for the microseconds since the start of day.
DoceHora.TMinHora(4, 1)
The (4,1) does not make sense to me since I'm not looking for the timestamp.
questions:
1.- Would it be an option to simply remove the (4, 1) and maybe get something coherent?
The instruction works as expected in the CR1000X (it gives a nice datetime string), but not in the CR3000.
2.- If changing to IEEE4 the variable type, maybe would I get a number more coherent value?
3.- Does internally the CR1000X works/interprets differently the instructions or are there some implicit conversions in the CR1000X ?
Thank you in advance
Hello.
Just in case someone is experiencing a similar issue: We solved the issue doing these steps:
1.- chancing the var. type to IEEE4
2.- Upgrading the firmware in the deployed CR3000 datalogger.
We got the data un MM-DD-YYYY format though from the CR3000, so we had to make an exception in our generic programming for parsing the JSON data.
This post is under review.
This post is under review.
If the time is presented to you in the form of an integer, the seconds that have passed since January 1, 1990 are most likely what you are looking for. geometry dash
The deployed CR3000 datalogger's firmware has to be upgraded. In order to parse the JSON data, we had to declare an exception to our generic programming because the data we received from the CR3000 was not in the MM-DD-YYYY format basketbros