ICI and DALI thermal camera software ?

[CRC]

From what I've seen they need to be frequent or it degrades quickly. Those with the commands won't respond so it's up to us to figure it out.

[CRC]

I found a 30 pin .5mm FFC break out board on Amazon that fits the cable from the small type. Pin 30 is video and 1 is ground. I think I traced out the serial lines too. I'm going to connect them to a 3.3v serial to USB adapter and see if it spits out anything when it boots up. The image indicates Dali protocol,  38400 baud and address 2 when it first powers up. It would be nice if it accepted both Dali and PELCO-D  commands but being set to Dali I'm sure I'm locked out.

Searching Dali commands is futile since all you get are Dali lighting system documents.

[nidlaX]

I found a 30 pin .5mm FFC break out board on Amazon that fits the cable from the small type. Pin 30 is video and 1 is ground. I think I traced out the serial lines too. I'm going to connect them to a 3.3v serial to USB adapter and see if it spits out anything when it boots up. The image indicates Dali protocol,  38400 baud and address 2 when it first powers up. It would be nice if it accepted both Dali and PELCO-D  commands but being set to Dali I'm sure I'm locked out.

Searching Dali commands is futile since all you get are Dali lighting system documents.

Have you thought about sniffing the bus while the module receives commands from the dual camera control board? I can't imagine the protocol being all that complicated.

[Fraser]

Sadly the communications protocol may be set to Pelco P, Pelco D or DALI proprietary command strings. As yours is set to DALI you would need to change the communications setting in the menu system to use Pelco with your unit. The Pelco command structure is also a bit unusual as it is using a standard CCTV keyboard as the terminal. It is not a function per button but rather accessing functions via presets.

The DALI proprietary command set is sadly not one that I would have been able to guess and the command string is not as simple as ASCII or AT commands. The command set document may be obtained from DALI but you may be required to sign an NDA.

[CRC]

Sadly the communications protocol may be set to Pelco P, Pelco D or DALI proprietary command strings. As yours is set to DALI you would need to change the communications setting in the menu system to use Pelco with your unit. The Pelco command structure is also a bit unusual as it is using a standard CCTV keyboard as the terminal. It is not a function per button but rather accessing functions via presets.

The DALI proprietary command set is sadly not one that I would have been able to guess and the command string is not as simple as ASCII or AT commands. The command set document may be obtained from DALI but you may be required to sign an NDA.

I would gladly sign an NDA and abide by it if they would acknowledge my attempts to communicate with them.

[CRC]

I found a 30 pin .5mm FFC break out board on Amazon that fits the cable from the small type. Pin 30 is video and 1 is ground. I think I traced out the serial lines too. I'm going to connect them to a 3.3v serial to USB adapter and see if it spits out anything when it boots up. The image indicates Dali protocol,  38400 baud and address 2 when it first powers up. It would be nice if it accepted both Dali and PELCO-D  commands but being set to Dali I'm sure I'm locked out.

Searching Dali commands is futile since all you get are Dali lighting system documents.

Have you thought about sniffing the bus while the module receives commands from the dual camera control board? I can't imagine the protocol being all that complicated.

I'm working on that now. Currently I'm just sniffing what it's doing when it powers up and does NUCs. Now that I have confirmed which lines are what for serial RX and TX I'm going to attempt exactly what you suggest.

[CRC]

I used the breakout board then also found that R64 = camera TX and R65 = camera RX on the ribbon connected video board. Tapping those and running them to a Waveshare USB to  RS232/485/422/TTL box, using TTL at 3.3v setting I am seeing hex 02 06 00 4B 42 44 2C 43 2C 6C 03 going to the camera every time it auto-NUCs or when manual NUC is initiated. However, I am unable to get it to respond to that command when trying to inject that from my TTL box.

That hex array converts to ASCII; KBD,C,l

It also seems that if the camera is disconnected the networking board goes manic and starts sending increasingly frequent commands trying to make contact with it.

[Fraser]

KBD,C, is the calibrate command as you have discovered. It is from the keyboard simulation command set.

There are two commands that you can send to the camera to see if you have good communications and no faults. As you will see, it is not a simple ASCII text command as there are other 'components' in the packet.

Try these as a test but I cannot supply the complete command set for this core (it is not mine to share).

CCM (Communications check)
02 04 00 43 43 4D 2C FF 03

Core should respond with CCM 1 to show that the command was received OK so comms are good.

GCS (Core status, including any faults found)
02 04 00 47 43 53 2C 09 03

Core should respond with GCS 1 which is "all OK" or another number to indicate a fault found in the core.

If you do not get a response from the core to these commands something is wrong (obviously).

Fraser

[CRC]

KBD,C, is the calibrate command as you have discovered. It is from the keyboard simulation command set.

There are two commands that you can send to the camera to see if you have good communications and no faults. As you will see, it is not a simple ASCII text command as there are other 'components' in the packet.

Try these as a test but I cannot supply the complete command set for this core (it is not mine to share).

CCM (Communications check)
02 04 00 43 43 4D 2C FF 03

Core should respond with CCM 1 to show that the command was received OK so comms are good.

GCS (Core status, including any faults found)
02 04 00 47 43 53 2C 09 03

Core should respond with GCS 1 which is "all OK" or another number to indicate a fault found in the core.

If you do not get a response from the core to these commands something is wrong (obviously).

Fraser

Thank you Fraser for the info! I just tried it and get no response so my transmit side tap must not be correct or something.
I tried with the FFC breakout board camera and received responses so yes, my communications setup is at least working!

Could you pass along any contact info for them? I used a "contact us" type of link on a web page but never received anything back from them.
Also, do you know if it's even possible to obtain any other video color but the hot iron out of the camera's CSVB output or does it require external processing?

[Fraser]

The core is capable of providing a range of colour palettes that may be selected via the Pelco commands and likely also directly using DALI commands The core also offers an “invert” option so “white hot” and “black hot” is available in the monochrome palette.

Normally when someone has trouble communicating via serial TTL I suggest that the communication settings, levels and data polarity is checked as these can differ when working with various cores. In your case you are able to read the data coming out of the network board so you should have the correct levels and data polarity configured. Why your core is not responding I am not sure.

[nidlaX]

Actually, you should just email sales@dali-tech.com. Ask for the DALI protocol specification, turnaround time is a few business days or less, no NDA was required (for me).

[cynfab]

I picked up one of the Type 2 cameras off e-bay the other day and have been poking around.
I tried installing the posted Dali control software, firmware updater as well as the IR Flash STM software with WINE.
The updater installed and ran, I didn't update the firmware as I wanted to poke at the old version for a while.
The Dali control software failed with the afore mentioned missing .cab.
The STM software failed due to an incomplete implementation of the ninput.dll.
Neither of those failures were unexpected.
So I tried again on a "Real" Windows 10 Pro machine.
The updater behaved as expected.
The Dali control software failed in almost the same way with a nice error message about the missing .cab not being
found: C:\Users\kenm\AppData\Roaming\DALI\Temperature measuring system 1.0.18\install\***chineese chars***-DL1.cab
The STM software installed but when run, just produced a splash screen and either crashed of terminated without any further messages.

I gave up and started reading the eevblog thread again and then the comments from all the sellers of Completed Items on e-bay.
One said that "I can pre-program these cameras for use on your NVR system". Another refereed to the Debug connector.

I opened mine up an sure enough there was a debug connector, 4 pin JST 1.25mm. I then figured out the pinnout and
connected a USB-serial adapter and was met with a u-boot startup followed by the Linux kernel startup followed by
the camera startup.
I was able to interrupt the u-boot startup and change the bootargs to give me a root shell after the kernel and system were up but
befor the camera was started.

I am now at the point of poking around in the file system to see what I can find. ...stay tuned...

UPDATE,
The system supports both an mmc card and USB vfat formatted thumbdrive. There is a 4 pin JST connector labeled USB which I'll try and connect up at some point.
UPDATE 2,
Attached is a zip file of some interesting parts of the file system.
UPDATE 3,
Not really an update but a question:
What firmware do folks have on their cameras, and did you update it?

[CRC]

Interesting,  to me they seem far too slow.

[clavo]

Thanks for that explanation.  Are you aware of HTTP strings that can be sent to change the camera color lookup tables?  For example, after a lot of time I figured out an older FLIR core would cycle color tables by sending: http://192.168.1.XX/axis-cgi/com/serial.cgi?port=1&write=ff01000b000511.    This was an old pan/tilt FLIR Photon plugged into an old 4 port AXIS server that used serial for the Pelco pan/tilt....  if remember right.  So perhaps that command was taken by the AXIS server and changed to Pelco..... then sent serial to the camera in serial (Most likely guess).  Old AXIS servers are pennies on ebay, and there is plenty on space inside these cases to take an AXIS board and just stick it inside.  The older ones run linux and have a built in web server and even could provide a clean composite 2x2 or 4x4 mosaic/matrix.   I was using a AXIS 2400+

[cynfab]

A bit of progress, I have been able to fiddle with some of the .html files on my camera to enable some of the menus that were disabled.
Also found that by using https://github.com/sr99622/libonvif the video is not laggy at all.
 I am by no means skilled at html, but I used Opera to dynamically fiddle with the code.
Here is a quick look.

[CRC]

A bit of progress, I have been able to fiddle with some of the .html files on my camera to enable some of the menus that were disabled.
Also found that by using https://github.com/sr99622/libonvif the video is not laggy at all.
 I am by no means skilled at html, but I used Opera to dynamically fiddle with the code.
Here is a quick look.

Where are the files you modded located? How did you access them?

[ArsenioDev]

A bit of progress, I have been able to fiddle with some of the .html files on my camera to enable some of the menus that were disabled.
Also found that by using https://github.com/sr99622/libonvif the video is not laggy at all.
 I am by no means skilled at html, but I used Opera to dynamically fiddle with the code.
Here is a quick look.

Where are the files you modded located? How did you access them?

Hit f12 and edit the lines for the right menus to not be hidden.
Then you'll have access to the other menus

[cynfab]

Most of the files are in /app/web/webpages/.  Now to find what in the .html/js/css/conf files I need to change to make it permanent.
And to test what actually works when the menus are enabled.
Got both mmc & USB working, the USB needs a jumper soldered on the main board. mmc works without any hardware fiddling.

[CRC]

Actually, you should just email sales@dali-tech.com. Ask for the DALI protocol specification, turnaround time is a few business days or less, no NDA was required (for me).

I did. I received no response.

[CRC]

Most of the files are in /app/web/webpages/.  Now to find what in the .html/js/css/conf files I need to change to make it permanent.
And to test what actually works when the menus are enabled.
Got both mmc & USB working, the USB needs a jumper soldered on the main board. mmc works without any hardware fiddling.

I noticed the 5v power line to that usb header had a missing jumper but I'm not sure if that's what you are referring to if I missed one somewhere else as mine didn't respond when trying to access it.

Also, on a bit of a tangent here, I have one of the small cameras that completely stopped responding via ethernet. All indications are that it's on and working (internal LEDs, activity lights, etc...) but it doesn't even respond to a port scan. It's strange. I have no idea what changed or happened to it. I tested the camera separately and it works normally.

[CRC]

Maybe I missed it but has anyone found any info about the visual camera in the small ones? I didn't see any writing on it that lead to anything I could research on line. It would be nice to be able to adjust its gain and whatever other parameters. Mine also seems adjusted to be best focused at about 12  feet away or so. Images of the street out front are a bit out of focus with the front yard and items closer clear. It looks as if there is a focus ring on that black plastic lens tube assembly but it doesn't want to turn and I fear I will break it.

[ArsenioDev]

Not sure what sensor, but does pretty nice in low light.
The glue on it is halfass, pick at it with your fingernails and it'll come loose

[cynfab]

The jumper to enable the 5V for USB is labeled LB22 on the main board. I believe it is a reference to a ferite bead for EMI suppression. Some disassembly required.
There are references to an IMX290 in the startup messages that come out the debug port. That is a SONY 2M pixel STARVIS low light level camera, not the most sensitive in the product family, that would be the IMX462, but pretty good.
$ grep -ri imx *

Binary file app/modules/hisi.so matches
startup_2.txt:==== Your input Sensor0 type is imx290 ====
startup_2.txt:>>> imx290_init
startup_2.txt:imx290_i2c_init [ok]
startup_2.txt:===IMX290 1080P 30fps 12bit LINE Init OK!===

Seems like the hisi.so driver supports several imx flavors.

$  strings hisi.so |grep imx

imx415_i2c_addr
imx415_addr_byte
imx415_data_byte
imx415_init
imx415_exit
g_astimx415
imx415_standby
imx415_restart
imx415_write_register
imx415_read_register
imx415_i2c_init
imx415_i2c_exit
imx415_linear_8M25_init
g_astimx290State
imx290_write_register
imx290_i2c_addr
imx290_addr_byte
imx290_data_byte
imx290_init
imx290_exit
g_astimx290
imx290_standby
imx290_restart
imx290_read_register
imx290_i2c_init
imx290_i2c_exit
imx290_prog
imx290_linear_1080p30_init
imx290_wdr_1080p30_2to1_init
imx290_wdr_1080p60_2to1_init
imx290_wdr_1080p30_3to1_init
imx290_wdr_720p60_2to1_init
imx290_wdr_720p60_3to1_init
imx290_wdr_1080p120_2to1_init
imx290_wdr_1080p120_3to1_init
g_astimx274State
imx274_write_register
imx274_init
imx274_exit
imx274_standby
imx274_restart
imx274_read_register
imx274_spi_init
imx274_spi_exit
imx274_prog
imx415_set_bus_info
imx415_i2c_init
imx415_write_register
imx290_set_bus_info
imx290_write_register
imx290_i2c_init
imx290_init
===Imx290 imx290 1080P15fps 12bit 3to1 WDR(30fps->7p5fps) init success!=====
===Imx290 imx290 720P30fps 12bit 2to1 WDR(60fps->30fps) init success!=====
===Imx290 imx290 720P15fps 12bit 3to1 WDR(60fps->15fps) init success!=====
===Imx290 imx290 1080P60fps 10bit 2to1 WDR(120fps->60fps) init success!=====
===Imx290 imx290 1080P30fps 10bit 3to1 WDR(120fps->30fps) init success!=====
imx274_init

[cynfab]

There is also resistor R788 that connects the video out of the thermal camera to the BNC connector.
But there are other components connected as well. R702, U10 and R701 which leads back to the CPU which is a HiSilicon Hi3519V101.

[cynfab]

I can confirm that R65 and R64 are the comm lines from the Hi3519 to the Dali Thermal camera.
Baud rate 38400 (although the firmware will try at 115200 if 38400 fails) N81.
With the Super/Debug menu enabled you can send  commands to the core, and see the response.