Hello @SKA, Thank you for the details. I can't think of anything right now, but will double check this. I know that there is one potential issue in voxl-camera-server - the SPS header (which is part of the H264 / H265 stream) is only sent by the video encoder once (at the beginning of the stream). I believe that voxl-streamer will cache the SPS packet (which contains things like resolution, etc) and i think when clients connect to voxl-streamer, then it will send that SPS header to the clients. However, if voxl-streamer does not get that first header, it will not be able to forward it to the clients. This is a guess for now, but could be related to the issue that you are seeing. I can look into this issue. Can you please let me know how exactly to set up VLC for 0ms cache? I want to make sure that my test is the same. Also, which version of VLC are you using? Also, i noticed one thing - you are using hires_misp_color stream from camera server, which is not actually encoded, but YUV. Then voxl-streamer will take those YUVs and encode them (using hardware encoder). Is there a reason why you are not using the hires_misp_encoded stream to get H264 directly from camera server and serve it using voxl-streamer without re-encoding? I wonder if in the old SDK you were using _color or _encoded stream? Alex

@qubotics-admin Hi, we sell all of those components for companies to integrate into their products. The Flir Hadron adapter (MDK-M0202-1-00) can be requested by reaching out to sales at https://modalai.com/contact The rest of the components should be available to purchase at modalai.com

@JoonaR Hi Joona, the DP should work to drive an HDMI projector with the appropriate adapter. This adapter has been tested to work: https://www.amazon.com/Cable-Matters-48Gbps-Adapter-Supporting/dp/B08MSWMXT4?th=1

@Alex-Kushleyev Can you please look into this or tag someone who can help me solving this type of networking related issue?

I did some additional testing and was able to narrow things down a bit. After reconfiguring the WiFi as a SoftAP using voxl-wifi and then rebooting the VOXL, the network now shows up consistently again. So the broadcast issue seems to be resolved for the moment. However, the core problem remains: I still can’t actually connect to the AP — the connection attempt starts, prompts for the password, and then fails just like before. If anyone has ideas on what else I could check or has seen similar behavior with this setup, I’d really appreciate the help.

@John-Nomikos Hi, Can you please explain how you solved this? I am facing same problem where my camera is connected via USB to ethenret convertor with Microhard add-on board and my host machine is unable to ping my camera but can ping voxl2.

@Seungjae-Baek , the resolution of the camera should depend on the use case. However, it is also important to keep in mind what exactly you are doing with the images coming from the hires cameras. For example, if you set the resolution to 4K and you try to view those uncompressed images using voxl-portal, this process will be very taxing on the CPU for the following reason: when you view uncompressed images in voxl-portal, these images are encoded with a software JPG encoder and then sent from voxl2 to your browser. This process is very cpu-heavy. On the contrary, if you use h264 / h265 stream, it should be perfectly fine to encode 4K30 video to disk or even stream, since H264 / H265 encoding is done by a hardware encoder. voxl-portal, actually does support showing h264 (but not h265) 30FPS streams, so that would be a lot more efficient for the CPU, since there would be no jpg encoding. Otherwise, if you are using raw frames (not _encoded) in voxl-portal , please keep in mind that you will always have a lot of cpu overhead. voxl-portal is designed for debugging / development purposes, so it's not necessarily the most efficient solution for video streaming. For real video streaming use cases, you would use h264 or h265 encoding and save to disk on voxl2 + stream the encoded video for remote viewing. You could encode the same camera source with two different resolutions / codecs / bitrates. If you need help setting up a specific use case, please provide some details and I can help you further. Alex

Actually, I see from the log that your FPV camera is IMX214 (please confirm). So then my next questions are: which Voxl2 SDK are you using? does the crash happen if you only view the Hadron EO stream (this is OV64B camera) can you please check the cpu temps when you view many cameras (using voxl-inspect-cpu) The dmesg error suggests some sort of low level error during MIPI transmission, but it could be tied to the SoC overheating. When voxl-portal is used to view images (especially in multi-view), the images on VOXL2 are converted from YUV to Jpeg using a software Jpeg encoder (which is very taxing on the cpu for large images). This can cause the cpu to overheat and start throttling operating frequencies to reduce the temperature). We are aware of this issue and it is on the list to fix the multi view to be more efficient and not overheat the CPU. Alex

@Eric-Katzfey interesting, think you for this information. Once i demo this drone for a couple weeks in its current BNF w/ ndaa add ons configuration I will be looking to move to a smart system and incorporating optical hold and other gps denied search features.

@jeremyrbrown5 we figured it out, we just changed the name of the model to yolov8n_float16.tflite. Pretty spot on now!

@jeremyrbrown5 , it is possible that overheating VOXL2 cpu could be causing your SoftAP performance slowdown. You can run voxl-inspect-cpu which is a tool that will show you cpu usage, temps and other stats. If the CPU cores reach 95 deg C, the thermal management will slow down the cpu clock, so all the processes will run slower, including SoftAP. Alex

@lhermosillo That is harsh. Do you have a bare board, or one with some additions? If you can use the bare voxl2, try that. If you have been using the bare board all along, I'm stumped here. I'd maybe try to reinstall the modalai-qdl env, or use another image. Maybe the qdl command itself instead of the webUI. Hope you'll be able to save your board!

@N-Chen I tried the webUI and the command line and as near as I can tell the webUI uses lsusb (or something along those lines) to detect the presence of the board. The install.sh uses adb or fastboot to detect the board and will sit waiting until the board is detected or CTL C is sent. My guess is the usb controller interface is alive and reporting but everything beyond it is dead.

@ravi I'm suspecting you have a bad cable or the cable is subject to some interference. Can you try this on a benchtop with just a VOXL 2 and an FC v2 and no other components? Is it currently integrated into a custom drone? Can you look at the signal quality on the TX and RX UART lines with an oscilloscope?

@Robbie-McCue worked, thanks so much!

I have the same problem before — turns out the compass setup finally worked after I did a full sensor recalibration in QGroundControl and made sure the GPS/compass was facing the right direction. Worth a try if you haven’t done that yet! You can also try this tool for free. https://123compass.org/

@jeremyrbrown5 Ah, yes, that'll do it.

@Dmytro-Stolbovyi Here is the updated link: https://docs.modalai.com/voxl2-unbricking/