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.