temperature-measurement

[Dominik21]

Hi
I use a thermal camera from Hikvison (DS-2TD2628-3/QA) and I want to read the temperature values. For that I use the SDK with the ISAPI-command GET /ISAPI/Thermal/channels/2/thermometry/1/rulesTemperatureInfo?format=json.
I saw in the attached pdf that there are possibilities for Real-time Temperature Measurement. One is with the SDK-command NET_DVR_GET_REALTIME_THERMOMETRY (p. 23)and the other is with the rtsp-Stream (p. 18). I didn't try this possibilities because I saw later that they exist...
So as I see there are four possibilities to read the temperature:

• over the ISAPI-command GET /ISAPI/Thermal/channels/2/thermometry/1/rulesTemperatureInfo?format=json,
• over the SDK with the ISAPI- command GET /ISAPI/Thermal/channels/2/thermometry/1/rulesTemperatureInfo?format=json,
• over the SDK with NET_DVR_GET_REALTIME_THERMOMETRY and
• over the rtsp-Stream.

Is that right?
I get the max., min, and average temperature of each zone, which I have edited in the configuration, with the ISAPI command. How does it works for the other two methods?
Did somebody work with the temperature measurement over the rtsp-Stream? How does it work? Do you read the Metadata from each stream?
What is about the speed from this methods? Speed means how long holds a value and how fast do I get an actual value after a temperature have changed in real life.
What are the pros and contras from this methods or when should I use which method?

 

[trempa92]

SDK arming have a down side. Arming is fragile and can easily break if no ideal network enviroment. Also Hik devices tend to have a buffer where they have stored connection and after short break. Your service will tend to rearm and camera will refuse because buffer its not cleared. (you cannot clear it manually)

Therefore i suggest using http GET request with ISAPI rathert han arming over 8000 tcp device port realtime isapi request.

 

[Dominik21]

Oh hi trempa.
you already have helped me here HCNet developers out there: I'm trying to remotely config my camera but....
Ther you said that the connection to port 80 is more stable. But do you know something about the differences in speed? you said that requests over port 8000 are realtime requests... can i suppose that this is the faster connection?

 

[trempa92]

Oh hi trempa.
you already have helped me here HCNet developers out there: I'm trying to remotely config my camera but....
Ther you said that the connection to port 80 is more stable. But do you know something about the differences in speed? you said that requests over port 8000 are realtime requests... can i suppose that this is the faster connection?

Well there is 1 more realtime push that doesnt really require arming and its called AlarmHost on cameras. Basicly camera will push to IP adress you put there. And on that adress you need to have tcp listener. SO Basicly you have 3 methods.

1. Arming and using SDK methods and structs - realtime
2. Periodical ISAPI pulls depending on you over http get post requests(entirely depends on device capability, most can handle 2,3 requests per second which would in your case be like realtime) - When u get status 200 OK just push another GET and so on
3. TCP server listener(just cant remember which port it uses, might be http might be device port and might be 7660) - realtime

 

[Dominik21]

To 2: From where do you know that 2 or 3 requests per second are like realtime in my case?
To 3: CAn I also get measurement datas over the tcp client or only Alarms?

 

[trempa92]

To 2: From where do you know that 2 or 3 requests per second are like realtime in my case?
To 3: CAn I also get measurement datas over the tcp client or only Alarms?

I expressed myself wrongly even with realtime, it entirely depends how fast temp detection ticks are happening on camera, it can i dont believe there are more than 3 ticks /sec. Therefor i dont see it would affect you any differently.
Regarding 3. - Depends on camera(firmware), some may push realtime(camera tick det) temp some may push alarms only and pre-alarms.


ps: Okay sorry if 2 or 3 ticks a second over ISAPI might not be enough for your nuclear reactor, but would 3.6 ticks be enough?

 

[Dominik21]

ps: Okay sorry if 2 or 3 ticks a second over ISAPI might not be enough for your nuclear reactor, but would 3.6 ticks be enough?

psst... you know this is a public Forum.
I don't really know by myself what are the requirements. I've just to find out what is possible.

Regarding 3. - Depends on camera(firmware), some may push realtime(camera tick det) temp some may push alarms only and pre-alarms.

Ok... I didn't find very much about this. But I think at the moment this isn't very important. Or do you know a usecase in which this method is interesting?

I expressed myself wrongly even with realtime, it entirely depends how fast temp detection ticks are happening on camera, it can i dont believe there are more than 3 ticks /sec. Therefor i dont see it would affect you any differently.

Yesterday I tried the method to send ISAPI-commands with the SDK. I had round about 200ms between two requests. I also tried the callback-fuction from the SDK but it didn't worked... (see here Problem with measure real-time temperature ). Now I try the pure ISAPI method.

 

[Dominik21]

I'm trying to implent the ISAPI request over http in Structured Text in TwinCat 3... but for that I've to generate the response in the Authorization-Field. The authorization method is digest. I find a algorithm here RFC7616 but i don't get the correct result. Do you know the correct algorithm?

 

[trempa92]

You may choose to use basic authorization if you wish but its less security wise, login on camera web interface -> left side Security tab -> put WEB Authentification Digest/Basic. Then you have a standard login.
I do know how it works using c# digest auth, i have it in my other app i made long ago.

This is what chatgpt says

 

[Dominik21]

thanks for your help. Now I have it with digest authorization. It works like ChatGPT said and as it is written in the link. Nonce, realm and qop is created by the server (here camera) and the rest is created by the client.
I resume it if somebody has the same issue and finds this here.
-First the client sends a request with the method and the uri to the server.
-If the client is already connected, the server will send the data. Otherwise it will send an "unauthorized" package to the client with the nonce, realm and qop strings.
-Then the Client will create the cnonce, nc and response. the cnonce is a random string, the nc is normally a counter of connection requests and the response is created as said.
- The Client sends his request again with the datas in the authorization-headfile ( as you can see in the link).

I measured the speed of the http-communication. For that I connected the camera with a Beckhoff-PLC via a switch. the PLC makes everytime a request when it gets a status-code 200 from the camera. I measured the time between two packages for 10000 times. I got following results:

• every package has new temperature values
• from one to the next package it needs 200ms in the middle, 500ms maximum and 70ms minimum

I upload the graphs so you can see it.

 

[Dominik21]

new understanding:
With an IR-LED I could see that you get the temperature value, measured a short time after sending your request, in the following answer. The value, which is approx 50ms after sending the request in front of the camera, could be received in the next answer or in the following answer. This is coincidence for me. I hope i explained it understandable .