We assist customers to build their “Own-Products”. Through the technologies we’ve been cultivating for many years in the areas of Communications, A/V Processing, and Internet of Things, we custom make products for our clients aiming at their unique applications and market growth. To achieve this goal, there are many key factors that we value the most including:
Talitor has been building up a decent reputation within the industry and international market over the past 20 years. Helping customers to build their “Own-Products'' means that we put our clients’ commercial wisdom and market protection first. We treasure your commercial knowledge which will always be administered as top confidential during the entire development procedure and throughout years of operations. At your concerns, hardware and software can be branded with your logo at a minimal economic scale requirement. Agreements can be arranged including NDA, MOU, Development Agreement and etc., in order to further assure you of your business intelligence.
Even in those arenas that we are professional, challenges are always there during new product development in terms of production definition, software coding, and hardware integration compatibility and sometimes even mass production. Dexterously experienced engineers and efficient project management are indispensable to get to the delivery of the ODM project. Occasionally greater encounters of incompatibility such as lower stack of IC coding supportive issues can lead to deficient functionality or even failure of the project. In such a case, a strong determination of increasing resources solely on Talitor’s side, and perseverance of administration and engineering works must be carried out to fulfill the delivery. For the past 20 years we have been overcoming a lot of challenges on ODM products and customization, which, at the end, our clients had complimented as Cash Cow contributing to their revenue.
A successful product has to occur early in the design stage when our engineers begin to assess the
feasibility of a concept, long before a prototype is built.
In Talitor we care every detail from the product concept to every single piece of production quality.
Our distinguished marketing staff will walk you through all your requirements
in order to justify the commercialization of your product concept from the technical view point,
as well as professionally recommend ways of getting it achieved.
Our experienced software and hardware engineers collaborating harmoniously and intensively with
marketing people
will plot out the product functional blocks, schematic, PCB diagrams,
and eventually putting PCBA fabrication in an ISO qualified manufacturing facility.
Software development was being assessed beforehand,
coding is initiated and continued under the hardware being developed until eventually being loaded and
tested for functional justification.
Coding rectification, pressure test and product longevity test are also being treated in highly
deliberate concerns.
Even after shipment is made, software upgrade service is continuously being supported, for example if a
feature is proved no longer valid and modification will improve.
Other persistence such as components used in the hardware are overall genuine and rigorous branded.
Hardware manufacturing is implemented in stringent quality control with whole amount tested and
inspected.
Capability of 24/7/365 operation on video recording applications are crucial in professional areas, yet technological challenges are implicit and recondite.
For over the past decades, we have many experiences accumulated that are precious to help our ODM clients succeed in their professions.
In real-life practice, there could be hundreds of reasons causing Device stop functioning, common culprits including unforeseen complexity of software design,
failure of Device component, broken storage media, components’ drivers issue, and even operating system failure, etc.
We are citing some of our experiences and solutions that were being implemented in our customized projects for your reference :
Case Study #1 : How will our Digital Video Recording system react when it encounters a storage media such as SD card failure after a long period of 24/7/365 operation ?
In rare cases, a Digital Video Recorder can stop recording after a long period of operation due to SD card issue,
which could cost the device owner with tons of troublesome when they found no video being recorded at critical time.
Our experiences are certain particular SD cards (ex. Kingston, Transcend, Hagiwara, etc.)
would have lock mechanism to protect the SD card from being bad block if it detects sudden SD voltage supply disrupted and drop below a certain level ex. 2.7VDC,
normally at unexpected power disruption, and the locked status would remain even after the SD voltage abruptly restores to normal 3.3VDC afterwards.
In consequence, SD card will automatically enter a self-protective mode in which read/write function are both restrained, causing DVR recording unfunctional, however without possibly being noticed.
But the locked status of SD Card can only be released by re-plugging SD card or executing a system powering off/on.
Solution: We created a self-diagnostic and recovery mechanism in our DVR firmware to execute system automatic reboot when it detects SD I/O error (i.e. read/write function of SD card being locked). The system takes a minute or two for rebooting and gaining back normal functionality. Then, the program will continue monitoring and detecting the health of SD Card status, and keep the system working properly 24/7/365.
Case Study # 2: Isn’t it easy to have a precise system health indication by LED display ?
NAND flash normally stores significant programing codes such as firmware file, event log, system default file, configured parameters, etc.
In rare cases, NAND flash may have bad block due to long-term system operation under harsh environment such as outdoor ambiance,
it caused firmware not being loaded correctly from NAND flash when a next round of system booting needed.
Therefore, system booting would be stuck at the very beginning stage right after U-boot completed, but before system application and watchdog timer takes effect.
However, in this case, the U-boot is ready and supposed to take control of the system LED indication (eg. lighting Green LED as system normal).
There is no way for a supervisor to notice the system was actually down until it is too late when a footage of evidence is needed
to be retrieved from the recorder, as the LED indicates normal status yet the system actually gets stuck.
It may lead to serious consequence of missing recording evidence.
Solution: We created a clear and precise LED indication mechanism to avoid misjudgement. System LED will maintain OFF during U-Boot starts. After U-boot is completed, system application takes effective and device enters recording status, system LED will then be turned ON. Furthermore, there are four specific behaviors of system LED indicating different status, such as system normal/recording, video loss, system abnormal/not recording, and no power.
Case Study #3 : Wi-Fi application is so popular and convenient nowadays that most people take it for granted.
In fact, it is a highly complicated technology adapted to application environment that even your in-house renowned branded Wi-Fi router would sometime encounter connectivity problem.
Our StreeCam series is purposely designed for distributed surveillance area where video evidence will be reviewed and retrieved only when needed via dedicated Wi-Fi connection.
As a standalone surveillance system which works independently 24/7/365 and endures a harsh outdoor environment, the stability of the system is the crucial element,
especially when the surveillance camera/DVR is normally installed in places for eg. hanging on a street lamp pole, where is intentionally no maintenance being provided.
In field application, we’ve ever encountered scenario that after months of nonstop operating, Wi-Fi SSID may disappear due to crowded interferences but the Wi-Fi hardware is still alive.
Since Wi-Fi SSID is invisible, it’s unable for the law enforcement people or users to connect the StreeCam via Wi-Fi for manipulating sophisticated features,
such as playing back recorded video files, downloading video files, configure parameters, etc.
Such incompetence of wireless connection could cause tons of problem when a recorded video evidence is needed to be fetched.
Solution: As a remote surveillance system where maintenance is very costly to access, a self-diagnostic and recovery mechanism is crucial to keep the system non-stop running without hassle. We developed our system with a mechanism that executes and refreshes the dedicated Wi-Fi system daily, at a user’s pre-selected time point. Yet the whole device will not be influenced while Wi-Fi refreshing within a minute of time, so that the video recording and all other functions won’t be affected. This effectively solve the vividness of Wi-Fi in long term operation, especially under a crowded Radio Frequency interference environment.
Case Study #4 : Crucially a Digital Video Recording system is supposed to run 24/7/365 with all recording evidence safely preserved. But how is that possible ?
In longrun practice, a Digital Video Recorder can abruptly stop recording due to system glitch, be it kernel panic or storage failure detected, or dozens of other reasons.
Our experience is that after a long-term operation with SD card full and overwritten,
the Linux system may have tiny chance failing to detect storage correctly or even the existence of SD card is detected but incapable of writing data into the storage.
In consequence, the programming will abort the recording loop, causing recording disruption.
Such unexpected recording disruption could cost the device owner with an ocean of troublesome when they found no video evidence being kept at critical time.
Solution: To achieve robustness of our products, watchdog self-recovery mechanism is implemented in the products to recover the system after a rare system glitch or when the OS kernel encounters an unexpected panic. For situation such as Linux detecting issue, where watchdog mechanism has no course to take effective, we create a supplementary design to execute rebooting mechanism to avoid recording disruption. In addition to instantaneous rebooting as remedial measures, we also develop a mechanism that refreshes the system daily, at a user’s pre-selected time point.
Case Study #5 : Never neglecting the heavy burden on system health after long-term operation,
a common seen system busy in many embedded system devices may cause big trouble for maintenance.
After a long and stewing operation, when a video footage is needed to be reviewed wirelessly from a video recorder,
it may have a very rare probability that the system is busy and not able to transfer files from device to terminals for playback on software.
Normally such failure could be recovered by a power reset.
However, considering that the device (camera dvr) is normally installed in places not easy to access physically,
it would be time-consuming and heavy labor cost to recover the symptom.
Solution: In order to prevent unknown system busy or program stuck after long-term operation, we add a precautionary mechanism to refresh the system daily at a user’s pre-selected time point according to their need. Such mechanism will refresh the entire operating system including the Wi-Fi communication applications for maintaining the system health. As a supplementary measure, user can also manually execute device system reboot from the software on a mobile terminal while they encounter such a rare issue.
Case Study #6 : Rapidly duplicate system configuration from one device to multiple devices.
There are dozens of device parameters to be configured customizable. Best way is to have your preference preset and default at manufactory.
However, it is practically hard to avoid re-configure those parameters when the device makes its deployment on the field.
Solution: To raise efficiency and reduce labor force from setting the parameters one by one, we designed our firmware a mechanism of exporting a total set of configurable parameters to a SD Card, which user can then utilize it as a prime configuration file that to have it duplicated to each individual device. The duplication can be done through a quickly importation of configuration file from the SD Card.
Case Study #7 : When it comes to a remote area surveillance where 3G/4G/5G telecom is needed, is there an EASY way for user to set up the camera DVR device ?
Solution: To achieve easy connection, our video surveillance solutions are embedded with NAT Transversal technology and Point-to-Point Cloud server support to accomplish convenient and friendly connection experience, where every device is communicated via a simple UID number on the Internet, instead of complicated IP address and port forwarding etc. The cloud-assist connection help establish the Internet connection between terminals and devices easily through 4G or even 5G router, the video will be streamed directly point to point and bring the users effortless remote monitoring experience for live video streaming, video playback & clips downloading, parameter configuration, etc.
Case Study #8 : Device working temperature is easily neglected when an embedded system is integrated by over a few hundreds of components,
yet such negligence may have grave risk of system stability.
When it comes to surveillance camera/DVR installed outdoors, especially in unattended harsh outdoor environment where maintenance couldn’t reach often,
e.g. remote area park, mining area, construction site, warehouse, etc, system stability is the crucial element in terms of preserving video evidence.
Among many factors contributing to system stability,
the tolerance of high temperature is a significant yet easily overlooked segment, which greatly affects the sustainability of the entire system.
In field application, our experiences are that high temperature is likely to cause device malfunction
such as booting failure, image noise, system breakdown, etc and lead to serious consequence of video evidence either missing or illegible in case of accident or crime.
Solution: To avoid the predicament caused by high temperature, it is a must to take precautionary measures and have strict verification tests before a new product is released, for example, conducting high temperature aging tests. A heat chamber test is proceeded with an intensive test cycle between high environmental working temperature up to 60°C and normal ambient temperature, simulating the real application outdoor scenario of 12-hour of warm daytime and 12-hour cool nighttime. Heat dissipation solution needs to be taken into account and applied on the product as well, such as adding heat sink on the main chipsets, housing mechanical design for heat dissipation, etc. These scrupulous measures help to strengthen the steadiness and robustness of the system and reduces the risk of missing video evidence caused by seemingly trivial yet essentially significant details.