Allow me to explain with a practical example: you have a camera on the network, and you want to automate taking snapshots in response to some arbitrary trigger (e.g. every minute, or whenever a separate motion sensor is activated). There are standards and conventions for type of integration, but military grade hardware often wants you to do things from first principles.
Typical consumer/IP camera: the camera has a REST API for its command set, so you can formulate a HTTP request like GET http://my-camera-ip/command/snap?stream=0 and the server will respond with image data. You can knock this out in maybe < 30 mins and < 100 lines of code. If you’re a bit crafty, you can add support for multiple different camera models, which may vary in URI formation and authentication.
On the other hand, trying to do this with a military grade camera, the experience is usually something like this: The camera comes with proprietary client software that is closed source. In UI you can click a ‘snap’ button to take an image, but no viable route for automation. You try to reverse engineer it with WireShark, but it appears to be a WebSocket connection with constant data transfer, which makes dissecting the ‘snap’ command difficult.
You check the manual, and the only mention of how to directly command the camera is via a serial line. That’s the first problem: you don’t want to run a long cable from the server running your automation, to the camera itself. So you buy a small serial device server, and run a serial cable between it and the camera. It will forward any byte sequence that is sent to it over your LAN, to the camera’s serial input.
The manual references a separate document that explains the communication protocol, which should explain what byte sequence to send to ‘snap’ an image. You hunt down this document, and. Uh-oh. It’s 344 pages long. Ctrl+F, you look for “snap” and find it’s in section 17. It references some earlier sections about sync bytes, message headers, and checksums. You finally work out that the full byte sequence you need to send to trigger a snapshot is00 7E 11 3D 01 00 0E 0D 0A. You write code that sends that sequence over TCP to the serial device server. But there’s a problem: you’re not receiving any bytes back. Where is the resultant image?
You go back to the manual and it mentions that “snapshots and recordings are stored on the internal SD card” and “SD card contents are available via FTP”. It doesn’t give a spec, or even a filesystem, for the SD card. After trying a bunch of different ones, the camera finally detects your SDXC card formatted as exFAT: the magic combo.
There is no explanation of the FTP functionality in the manual, so you try the default FTP port, and make some educated guesses for the right username/password combo. None of them work, so you contact the manufacturers for help. 2 weeks later, they respond with the credentials. Finally, you’re in, and you’re seeing new image files showing up whenever you send the byte sequence. Success! Now, your code does something like this:
Send 00 7E 11 3D 01 00 0E 0D 0A via TCP to serial device server
Wait a moment
Connect to camera FTP server and download image file from SD card
A week later, your boss walks in and says that a new competitor, manufacturer B, has cameras with much more impressive IR sensors for nighttime surveillance. The existing cameras will be replaced starting next week. None of what you have built is reusable for manufacturer B cameras; it’s time for a new adventure.
It’s mind-boggling. It’s like the manufacturers’ engineers have not spoken to anyone who has written any software in the last 20 years.
I understand. However, I’ve had very similar experiences with industrial cameras and sensors in a research setup.
Taking snapshots was ok, once you had setup everything (it only worked with GigE Network cards supporting jumbo packets and some other specific settings) and used their “acquisition” software (which could be automated). However, triggering multiple cameras at once at the exact same time was a similar experiences with additional trigger lines and multiple discussions with the manufacturers application engineers.
Even worse where non standard sensors line photosynthesis sensors or other industrial sensors used in a non standard setup. For the lidar I also had to read their hundreds of pages long documentation of their serial interface but send it via TCP in special packets which had almost no documentation. Depending on the command the byte order also had to be swapped which was not documented at all and I had to find it by trial and error.
For a different laser sensor that produces point clouds there was a simple interface to get preprocessed images but we wanted the raw point cloud data which also required to download the files from an on-device FTP server which also required so some guess work.
Later I worked in industrial settings with PLCs and these guys sometimes also go overboard with complex setups (I’m looking at you, Siemens RFID reader…)
So I’m not sure if it’s the military grade that makes it such an experience. Industrial grade seems like a similar experience. I guess a lot of consumer devices also do shit like that under the hood but hide it in firmware and drivers.
I believe you but can you explain why?
Allow me to explain with a practical example: you have a camera on the network, and you want to automate taking snapshots in response to some arbitrary trigger (e.g. every minute, or whenever a separate motion sensor is activated). There are standards and conventions for type of integration, but military grade hardware often wants you to do things from first principles.
Typical consumer/IP camera: the camera has a REST API for its command set, so you can formulate a HTTP request like
GET http://my-camera-ip/command/snap?stream=0and the server will respond with image data. You can knock this out in maybe < 30 mins and < 100 lines of code. If you’re a bit crafty, you can add support for multiple different camera models, which may vary in URI formation and authentication.On the other hand, trying to do this with a military grade camera, the experience is usually something like this: The camera comes with proprietary client software that is closed source. In UI you can click a ‘snap’ button to take an image, but no viable route for automation. You try to reverse engineer it with WireShark, but it appears to be a WebSocket connection with constant data transfer, which makes dissecting the ‘snap’ command difficult.
You check the manual, and the only mention of how to directly command the camera is via a serial line. That’s the first problem: you don’t want to run a long cable from the server running your automation, to the camera itself. So you buy a small serial device server, and run a serial cable between it and the camera. It will forward any byte sequence that is sent to it over your LAN, to the camera’s serial input.
The manual references a separate document that explains the communication protocol, which should explain what byte sequence to send to ‘snap’ an image. You hunt down this document, and. Uh-oh. It’s 344 pages long. Ctrl+F, you look for “snap” and find it’s in section 17. It references some earlier sections about sync bytes, message headers, and checksums. You finally work out that the full byte sequence you need to send to trigger a snapshot is
00 7E 11 3D 01 00 0E 0D 0A. You write code that sends that sequence over TCP to the serial device server. But there’s a problem: you’re not receiving any bytes back. Where is the resultant image?You go back to the manual and it mentions that “snapshots and recordings are stored on the internal SD card” and “SD card contents are available via FTP”. It doesn’t give a spec, or even a filesystem, for the SD card. After trying a bunch of different ones, the camera finally detects your SDXC card formatted as exFAT: the magic combo.
There is no explanation of the FTP functionality in the manual, so you try the default FTP port, and make some educated guesses for the right username/password combo. None of them work, so you contact the manufacturers for help. 2 weeks later, they respond with the credentials. Finally, you’re in, and you’re seeing new image files showing up whenever you send the byte sequence. Success! Now, your code does something like this:
00 7E 11 3D 01 00 0E 0D 0Avia TCP to serial device serverA week later, your boss walks in and says that a new competitor, manufacturer B, has cameras with much more impressive IR sensors for nighttime surveillance. The existing cameras will be replaced starting next week. None of what you have built is reusable for manufacturer B cameras; it’s time for a new adventure.
It’s mind-boggling. It’s like the manufacturers’ engineers have not spoken to anyone who has written any software in the last 20 years.
I understand. However, I’ve had very similar experiences with industrial cameras and sensors in a research setup.
Taking snapshots was ok, once you had setup everything (it only worked with GigE Network cards supporting jumbo packets and some other specific settings) and used their “acquisition” software (which could be automated). However, triggering multiple cameras at once at the exact same time was a similar experiences with additional trigger lines and multiple discussions with the manufacturers application engineers.
Even worse where non standard sensors line photosynthesis sensors or other industrial sensors used in a non standard setup. For the lidar I also had to read their hundreds of pages long documentation of their serial interface but send it via TCP in special packets which had almost no documentation. Depending on the command the byte order also had to be swapped which was not documented at all and I had to find it by trial and error.
For a different laser sensor that produces point clouds there was a simple interface to get preprocessed images but we wanted the raw point cloud data which also required to download the files from an on-device FTP server which also required so some guess work.
Later I worked in industrial settings with PLCs and these guys sometimes also go overboard with complex setups (I’m looking at you, Siemens RFID reader…)
So I’m not sure if it’s the military grade that makes it such an experience. Industrial grade seems like a similar experience. I guess a lot of consumer devices also do shit like that under the hood but hide it in firmware and drivers.
Are we getting a schematic of proprietary technology on Lemmy? Let me get my notebook.
No, you’re thinking of the War Thunder forums.
I’m guessing poor documentation exacerbated by security clearance checks.