The cameras are connected to a laptop on usb 3 ports.

Also, how are you powering the 3 devices? Directly from the laptop? If that's the case, could you try with powered USB hub or Y-adapter?
It might be that laptop can't provide power for 3 devices, and they randomly crash when there's a power spike (power spikes from one device can be up to 2W of average power consumption).

    Hi jakaskerl

    Thanks for the response below are the information you asked:
    Base OS = 22.04 ubuntu
    Architecture = x86_64
    Docker image = Custom docker image build with 2.24 depthai version installed for both cpp and python
    camera = OAKD W

    Thanks,
    Abhay

      Hi erik ,

      We are using by connecting it by laptop but we have many of them and it is only happening for few laptops that to after deployment is their any way we can get the log of power consumption by the devices that would be very helpful.

      Thanks,
      Abhay

        Hi @abhay ,
        Not really, you could add USB power meter, but they aren't that precise and can't detect short power spikes. I'd suggest trying with a powered USB hub first.

          erik We're using Dell's GL15 gaming laptop deployed only inside the US, with very stable power, with a very advanced and capable power brick. We've used the Y-Adapter P/N 00513 with the same inconsistency as without. We've eliminated camera's damaged during transit by replacing the camera's onsite before powering up the system with the same double-count effect. We've had camera's which double counted onsite come back to the production facility and now have been operating over 1 month, with no double counting. We don't mind adding the Y-Adapter to our bill of materials but….this problem is based elsewhere, I believe.

            @CrisLuce so either it's (from more to least likely imo):

            • Power issue - power dips below 5v and device brownouts, you can use oscilloscope to measure that)
            • Mechanical/connectivity issue - eg. cable moves around and isn't screwed via USB-C screw holes, disconnects the power/comms lines for a short time and connection drops. Here you could use USB-C with screws for a better connection
            • Hardware issue - device/cable has an issue.Not sure if you already tried different devices/cables. Here we can replace the units, or even ship units+laptop to our office to try to repro.
            • FW issue, but seems unlikely, as it only happens at the customer, not at your place. Would need to repro as well to come to the culprit of the issue.

            Thoughts?

              Hi erik Thank you for the detailed thoughts. We randomly have the same issue at our production facility as well. We've replace the USB A / USB C cables that come with the camera as well, with the same random results. We are not receiving a crash dump report from the devices - we are experiencing inconsistent operating outcomes - I would like to figure out how we can get a crash dump report from you guys - all the data from you guys - so we can use that data to pinpoint a direction to resolve these random issue. Many thanks for your attention and interest in helping us resolve the issues.

                This is a link to the laptop we use: G15 Gaming Laptop – Gaming Laptop Computers | Dell USA

                All the systems are setup the same with the same power & connected devices, etc. Some systems will work with no issues and others will have crashing issues.

                The only accessories being powered by the laptop are the two Oak-D cameras.

                We have tried it with the cables that come with the cameras and with higher end aftermarket cables with the same issues.

                We'll get with our Electrical guy and see if there's a way for us to test the voltage coming from the port.

                Thanks!

                @CrisLuce @CliffAtSmartSort we'd love to help you guys and resolve this issue, but the link to the computer unfortunately doesn't help us much.
                Ideally, the whole setup would be shipped to our local office (in EU) so we can repro, or you could first measure the voltage with oscilloscope and measure if there was any voltage dip when the crash happens.
                Thanks, Erik

                  Hi erik Lets focus on getting the crash dump data (all data) so we can further inspect and go from there.

                    Hi @CrisLuce , If you already tried getting the crash dump (and there was none found), then it (very likely) wasn't FW issue, and we can't do much about it. So next option would be to look into power/connectivity.

                      erik Even on the systems that were double counting/crashing/causing us a problem, there was no crash dump data, so, outside of power / connectivity, what could it be?

                      It sounds like FW crash is out of the question, we know the cables are secure, we know the power is good, but we'll continue to inspect the power side.

                        @CrisLuce let's first check power side if that is stable. If it is, then it would be best to send the whole system over, so we can debug locally with a JTAG debugger, and actually see what is going on.

                          Hi erik That is a very expensive and lengthy situation. If all units experienced the same issue I'd be much more likely to jump to that. We have proprietary code and components, this would require a several legal agreements due to multi-national patents, including EU. I'm assuming there is no way to perform a remote JTAG debugger?

                          Are you unable to suggest other areas of potential issue. For example, we have a custom docker, any potential conversion issues, ques getting jammed up with sensor data from our vision app.

                          I appreciate the attempt to support within this forum, I think a quick call might be best. I'll connect with Jim. Please let me know if you have any other thoughts - many thanks!

                            Hi @CrisLuce ,

                            1. JTAG: I don't think so, as we need toolchains that are under NDA to debug that. So same issue as you have on your side.
                            2. Docker: we haven't heard about that, but yes, I'd try without docker container as well.
                            3. Call: sure