Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Question about DataTable in a CR3000 vs a CR1000X


RSAPIAIN-DMC Feb 2, 2023 06:57 PM

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,

 


JDavis Feb 2, 2023 08:02 PM

If you are getting an integer for time, I expect it is seconds since Jan 1, 1990.


RSAPIAIN-DMC Feb 2, 2023 08:45 PM

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


RSAPIAIN-DMC Apr 10, 2023 08:44 PM

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.


remudawhen May 7, 2024 09:10 AM

It is significant to remember that the firmware version and configuration settings of the data logger may have an impact on the particular capabilities and limitations of DataTables. When it comes to data geometry dash lite storage, the CR3000 and CR1000X share the same concept-DataTable-which allows them to store data in a tabular fashion. Nevertheless, DataTables' features and restrictions differ slightly across these two types.

Log in or register to post/reply in the forum.