Is there a time limit that the BR2 can be ran topside, I don’t mean with thrusters on, but I’m in the process of mapping my HCU to the Eiva software however the system seems to be getting a wee bit hot. Running around 52degrees but did go up to 70 at one stage.
I obviously know when In water the system will be a lot cooler however I’m not sure if I’ve an issue with one or more components or it’s just that I am over using the system without adequate cooling.
Hi @Davie260563,
I’d note that while my above comment is true in general, I wouldn’t expect 52-70 degrees to noticeably affect the camera stream, especially towards the lower end. A Raspberry Pi 3B will automatically throttle itself when it gets above 80 degrees, (in which case there’ll be a message that “Throttling has occurred” on the System page), but you don’t seem to have reached that point so I’d expect something else is causing the lag issues.
Beyond the (mostly hardware considerations) I mentioned several months ago, there have also been a number of software improvements. If you’re not already on the latest Companion software (0.0.30) I’d recommend you update (via the System page).
It may also be worth downloading QGC 4.1.4, which has some video decoding fixes that can reduce flickering/lag (you may need to swap between different decoding options - click the purple QGC logo in the top left, and select Application Settings)
I understand you’re in the process of switching to using Eiva’s NaviSuite, but it would be useful to understand whether the video issues are from the topside struggling to decode or whether it’s a Companion software/ROV hardware issue. If the video works fine in QGC 4.1.4 then presumably Eiva will need to fix something on their end, but if it’s just as problematic on 4.1.4 then it’s most likely a Companion or hardware problem that we can hopefully help you to sort out 
2 Likes
Thank you so much for this, I will pass this on to my team who are currently in a project it’s come at a good time as we really need to iron this issue out. I will update as soon as I know. I will say that if it’s not software what hardware components would be the probable cause? We’ve just recently replaced the pixhawk due to faulty thruster port so this one is brand new with zero use.
I’m fairly confident all software is up to date as we checked all this just couple days ago but I will double check. We’ve had a few integration issues transferring to Eiva so I’m hoping that is the case.
If we revert back to QGC is it possible to record it’s something I’ve seen mentioned but not actually trialled. If we can record could you kindly inform me of that’s set up and where the videos will be saved and in what format. Also can logos be added.
Hi Eliot,
So I do apologies I’m trying to diagnose this issue via remote spot offshore. I’m not with the equipment so I’m just relaying feedback from the guys on the job. I’ve since found out from guys @ EIVA that their Mobula software has some issues causing the lagging. Great news that it’s not hardware related or anything on BR side.
I appreciate your input regarding this issue much appreciated 
2 Likes
QGroundControl automatically records telemetry (while the vehicle is armed, or just while it’s open if you set it to). It can also record the video stream, along with a subtitle overlay of the visible telemetry overlay values. Here’s a quick video of video recording in the default mkv format, and playback with VLC media player.
QGC itself can have the ArduSub logo in the top right changed to any image you want:
For having a logo on your recordings, you can either
- screen-record the QGC window (which means you also record the telemetry and other widgets, so the base video is partly covered),
- add one to the subtitle file (some notes here), or
- do normal QGC video recording and then add a logo to your video(s) with video editing software (can be done with ffmpeg on the command-line, if you want)
Always nice to hear an issue’s not on our end. Hope they’re able to sort that out for you
1 Like
Hi Elliot,
Once again your a star fantastic feedback it’s very much appreciated.
I need to double check our cpu on our laptop to be certain it’s not our kit causing this but I’m pretty sure it’s not. We are running with Dell latitude 5424 rugged. We actually upgraded to this since our last laptop (cheap) was not up to the task and cpu was maxing out while running QGC.
Thanks Elliot
1 Like
Hi Elliot,
We seem to be going round in circles regarding the lagging of the camera. Not only does it happen with EIVA software it’s also same issue on QGC. So I’m leaning towards a hardware issue now.
So this is is our current camera settings when it’s working…
When running the system with QGC it seems fine for 20/30mins (the time does vary) until we start tilting up & dwn which initially causes the glitch then ultimately drops out displaying this…
The camera feed/information does return but camera does not reconnect. We have tried reducing camera resolution/fps which does improve things as camera does not drop out but does glitch. Once the video does drop out we have to recycle the power for the camera to come back online.
I can say that our cpu is running @ 30/40% during this time so I can’t see that being a factor.
Davie
Hi Davie, may or may not be related, but… I had a similar issue which turned out to be loose connections.
It may be worth opening the ROV and checking the physical connections at the camera, I’ve also experienced a loose esc wire which made the camera glitchy until it eventually fried a thruster.
2 Likes
If it’s tilting specifically that causes dropouts then I’d agree with @murf that this could be a loose connection. I’d suggest checking if the camera cable is strained when you tilt the camera servo fully up or down, and whether that’s able to consistently or at least regularly cause camera stream glitches/drop-outs. Opening the enclosure to check that all the wires are well-seated in the connector, and making sure the cable isn’t getting caught on anything could also be helpful.
Companion tries to re-start the camera stream every 2 seconds if it detects that it’s stopped. That means either Companion is getting valid packets from the camera and is failing to send them along (e.g. communication issues), or the connection to the camera is stable enough that the camera is detected, but the stream itself isn’t working and Companion is repeatedly restarting it (e.g. camera potentially low on power or has a loose connection).
You can check what’s happening in the video screen session by running screen -S video -r in the web terminal, and seeing if the stream is repeatedly restarting and/or if errors are appearing. Press CTRL+a then d to detach from the screen session when you’ve finished looking.