# Ping1D causing "Throttling" and "Under-Voltage" on Raspberryi Pi 3B resulting Lag on QGC **URL:** \ **Category:** Ping Sonar Devices\ **Created:** [June 14, 2021, 1:07pm UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906 "2021-06-14T13:07:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![FerdiCakmak](https://avatars.discourse-cdn.com/v4/letter/f/a9a28c/32.png) [@FerdiCakmak](https://discuss.bluerobotics.com/u/FerdiCakmak)\ **Post date:** [June 14, 2021, 1:07pm UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/1 "2021-06-14T13:07:02Z")
Hi, I have - Ping1D Echosounder Firmware v3.28 auto - PingViewer v2.1.0 - Companion Computer Firmware v0.0.26 - ArduSub v4.1.0b4 - QGC v.4.0.11 I have Ping Sonar Echosounder connected to Raspberry Pi 3B+ via USB over TTL/USB adapter. - PingViewer shows measurements without issues. - QGC shows “Rangefinder” value from Ping with lag and momentary losses. - Companion-\>System interface shows status: 55degC, “Throttled” and “Currently Under-Voltage”, CPU Load: %90-100. (When Ping Sonar Echosounder is not connected status is allways “OK”. CPU Load:50) ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/5/58bbc888ae90e59140bdfbae97b96e8a36da8cae.jpeg) I have measured 5.03Vdc for RasPi and 0.07-0.12Adc to Ping1D but I cannot measure the transients. I think the lag while updating RangeFinder value on QGC is caused by throttling or under-voltage status of RasPi. How do you think I can resolve this problem? Best Regards. ---
**Author:** ![jwalser](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/jwalser/32/2234_2.png) [@jwalser](https://discuss.bluerobotics.com/u/jwalser)\ **Post date:** [June 16, 2021, 1:51am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/2 "2021-06-16T01:51:57Z")
Please open a terminal on the raspberry pi by visiting [http://192.168.2.2:8080](http://192.168.2.2:8080). Type the command `dmesg -w` and show us the output. This will tell us if the ping is causing any problems on the usb bus. Is this a BlueROV2, or a custom build? When did you purchase your ROV? We’ve updated [our 5V supply](https://bluerobotics.com/store/comm-control-power/elec-packages/bec-5v6a-r1/) for the Raspberry Pi, which you should get if you’ve got one of the [previous models](https://bluerobotics.com/store/retired/bec-5v3a-r1/). Do you have anything else connected to the ROV? I’m curious why you are running ardusub 4.1.0, unless you also have a waterlinked DVL attached. ---
**Author:** ![FerdiCakmak](https://avatars.discourse-cdn.com/v4/letter/f/a9a28c/32.png) [@FerdiCakmak](https://discuss.bluerobotics.com/u/FerdiCakmak)\ **Post date:** [June 16, 2021, 6:08am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/3 "2021-06-16T06:08:00Z")
Hi @jwalser , I realized that heat is causing throttling, and throttling causing clock frequency down to 0.6MHz, frequency down causing processing load to increase and this causing lags and drops mavlink telemetry packages probably due to unprocessed services. As a solution I have put some heatsink on RasPi and changed RasPi settings so that frequency does not drop to 0.6MHz. This seems to have solved this problem for now. I am using Ardusub v4.1.0 because it supports LUA scripting. Best. ---
**Author:** ![jseifert](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@jseifert](https://discuss.bluerobotics.com/u/jseifert)\ **Post date:** [July 24, 2021, 6:40pm UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/4 "2021-07-24T18:40:24Z")
Dear Blue Robotics Team, This is kind of urgent because I am currently doing fieldwork in Curacao and fail to get my BR fully operational. I still struggle with the above mentioned overheating problem, although I installed the new BEC 5V 6A Power Supply ([https://bluerobotics.com/store/comm-control-power/elec-packages/bec-5v6a-r1/](https://bluerobotics.com/store/comm-control-power/elec-packages/bec-5v6a-r1/)). If I keep the Ping 1D connected, the Companion CPU load increased within a few minutes after booting to more than 100% and the BR is no longer maneuverable (more than 30 secs delay on the companion side in receiving commands from topside). Terminal messages seem to indicate ([http://192.168.2.2:8080](http://192.168.2.2:8080)) that the boot process doesn´t conclude (bcm2835-v412: error 0 waiting for frame completion; see oldBEC\_withPing.pdf attached). The Ping itself, gives reasonable readings. Even with the new BEC, the system shows the same behavior (newBEC\_withPing.pdf). (Dis-)connecting the Waterlinked GPS doesn’t have any effect. If I disconnect the USB cable from the Ping 1D BLUART USB to TTL Serial and RS485 Adapter, the system works well, and CPU load is around 50%. The booting sequence ends with “random: cnrg init done” (attached: message\_end\_noping.png, attached). I tried to update the Ping 1D firmware using the new PingViewer version 2.2 but run into new problems. The automated update returns: “It’s only possible to flash via serial.” And the Ping communication / update procedure freezes (Ping\_firmware\_update\_auto1/2.png). The manual update doesn’t work either. So I cannot update the Ping. As I am currently supposed to map coral in Curacao and already lost one week of two trying to get the BR2 operational, I am running out of options. I really do need the altimeter. Any thoughts how to make it work? I got the following hardware: BR2 (rev 1, I suppose, bought in 2016) Ping1D Echosounder Altimeter (bought in 2019) with Firmware v3.26 New BEC 5V 6A Power Supply PingViewer v2.2.0 WaterLinked UnderWater GPS G2 Companion Computer Firmware v0.0.26 with heat sink and small fan (disconnecting the fan, doesn’t solve the problem, either). ArduSub v4.0.3 QGC v.4.1.3 Any help or advice is highly appreciated. Best regards, Jörg [newBEC\_withPing.pdf](https://discuss.bluerobotics.com/uploads/short-url/vJpMmXeiPNvMjGgUni1iaaJonEl.pdf) (3.3 MB) [oldBEC\_withPing.pdf](https://discuss.bluerobotics.com/uploads/short-url/fGraVxUGPkHCLnAXWb3Lzhwyq93.pdf) (2.7 MB) ![message_end_noping](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/6/6ceab76d197d66273dcb8ad928543485747f0e19.png) ![Ping_firmware_update_auto1](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/5/5e6651597952cc97442fec823047b7528f652b47.jpeg) ![Ping_firmware_update_auto2](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/4/4d794e335f64c63f0e5d288d480a04f2961dd001.jpeg) ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [July 26, 2021, 2:25am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/5 "2021-07-26T02:25:02Z")
Hi @jseifert, welcome to the forum 🙂 Sorry to hear you’re having issues with your ROV. > [@jseifert](#): > > If I keep the Ping 1D connected, the Companion CPU load increased within a few minutes after booting to more than 100% and the BR is no longer maneuverable (more than 30 secs delay on the companion side in receiving commands from topside). That’s definitely not normal, and indicates something is going wrong. > [@jseifert](#): > > Terminal messages seem to indicate ([http://192.168.2.2:8080](http://192.168.2.2:8080)) that the boot process doesn´t conclude (bcm2835-v412: error 0 waiting for frame completion; see oldBEC\_withPing.pdf attached). The Ping itself, gives reasonable readings. Even with the new BEC, the system shows the same behavior (newBEC\_withPing.pdf). `bcm2835-v4l2` is a Raspberry Pi kernel module that allows `v4l2` (video-for-linux-version-2) to work, so that USB cameras can be connected to. I’m curious as to whether it’s somehow trying to connect to the ping device as though it’s a camera, or if you have some issue with your actual camera. > [@jseifert](#): > > If I disconnect the USB cable from the Ping 1D BLUART USB to TTL Serial and RS485 Adapter, the system works well, and CPU load is around 50%. The booting sequence ends with “random: cnrg init done” (attached: message\_end\_noping.png, attached). This would imply there’s at least something funky going on with respect to the ping, although it’s unclear whether it’s related to the camera module error. I just went through your oldBEC and newBEC terminal outputs and they appear to be exactly the same other than minor differences in the timestamps. Do you have a USB camera connected (it’s not detecting one), or are you using a separate IP camera or something? If you’re not using a USB camera I’d suggest you try commenting out the lines that start the `video` and `audio` services in companion. To do that, when you open the web terminal you can run `nano companion/.companion.rc` to edit the relevant file with the nano editor, then use the arrow keys to get to the relevant lines, and put a hash (`#`) in front to comment them out: ![disable-video-audio](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/4/421d9cf09d3c747fc3068d5b911fbd6fc1789ee1.jpeg) Then press `Ctrl+X` then `y` to save, and `Enter` to exit the editor. Reboot the companion and see if the `waiting for frame completion` error goes away, and hopefully also the issues with unexpected high CPU usage (although they may be unrelated). > [@jseifert](#): > > The automated update returns: “It’s only possible to flash via serial.” And the Ping communication / update procedure freezes (Ping\_firmware\_update\_auto1/2.png). The manual update doesn’t work either. So I cannot update the Ping. This is telling you that updating with PingViewer can only be done if the Ping1D is directly connected to the device running PingViewer - you need to plug the USB cable into your topside computer, not the companion computer. It’s technically possible to update the Ping1D through the companion web interface `/ping` endpoint, but that requires downloading the firmware manually onto your topside computer and uploading it through the web interface, which is a bit more troublesome and has more scope for issues than the auto update through PingViewer. As a note, the command prompt message log that comes up when you open the new PingViewer isn’t meant to be there - that should be fixed if you re-download PingViewer 2.2.0 🙂 ---
**Author:** ![jseifert](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@jseifert](https://discuss.bluerobotics.com/u/jseifert)\ **Post date:** [July 26, 2021, 5:47am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/6 "2021-07-26T05:47:26Z")
Dear Eliot, thank you very much for getting back to me - on Sunday! I really appreciate your commitment. I modified companion.rc as recommended and the final error (“bcm2835-v412: error 0 waiting for frame completion”) disappeared, but so does the video stream in QGC. So I reloaded the Default gstreamer options in the web GUI ([http://192.168.2.2:2770/camera](http://192.168.2.2:2770/camera)), reloaded the page, and applied them. This move made the error reappear (see messages below and screenshot) and the system started to heat again: [26.560572] random: crng init done [231.526773] media: Linux media interface: v0.10 [231.546109] Linux video capture interface: v2.00 [231.606800] bcm2835-v4l2: scene mode selected 0, was 0 [231.607934] bcm2835-v4l2: V4L2 device registered as video0 - stills mode \> 1280x720 [231.612765] bcm2835-v4l2: Broadcom 2835 MMAL video capture ver 0.0.2 loaded. [234.487347] bcm2835-v4l2: error 0 waiting for frame completion My video device is the original Raspberry Pi Camera Module: mmal service 16.1 (Raspberry Pi Camera Module). I wonder if the streaming script or service expects the new low-light camera module? Then, I set the MAVProxy --streamrate to 2 Hz ([http://192.168.2.2:2770/mavproxy](http://192.168.2.2:2770/mavproxy)), and the system cooled down. I tried to update the Ping1D firmware directly connecting its UART interface to the topside using an USB cable (COM7, 115,200 bits/sec) and PingViewer 2.2 (downloaded again 2 hours ago), but couldn’t establish the connection (and the command prompt message log still comes up). I didn’t manage to establish a direct connection with version 2.1 either. But the Ping sends data via the companion. I’ll give it another try today and hope the systems will operate. Otherwise, I would have wasted a lot of time and money for field work in the Caribbean. ![2021-07-26 00_27_13-Clipboard](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/e/e7c99bc263493c089b4f762c32a50a67fd15f540.png) ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [July 27, 2021, 2:17am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/7 "2021-07-27T02:17:39Z")
> [@jseifert](#): > > I modified companion.rc as recommended and the final error (“bcm2835-v412: error 0 waiting for frame completion”) disappeared, but so does the video stream in QGC. > … > My video device is the original Raspberry Pi Camera Module: mmal service 16.1 (Raspberry Pi Camera Module). I wonder if the streaming script or service expects the new low-light camera module? The video streaming functionality should work fine for the Raspberry Pi camera - it’s an option I’d forgotten about, which isn’t an IP camera but also isn’t a USB camera. It does go via the companion computer though, so at least the `video` service should remain. You can comment out the `audio` one if you want, but it likely won’t have much if any effect. > [@jseifert](#): > > reloaded the Default gstreamer options in the web GUI ([http://192.168.2.2:2770/camera](http://192.168.2.2:2770/camera)), reloaded the page, and applied them. This move made the error reappear I believe the camera error is likely just from some probing the camera streaming script does to determine appropriate camera settings - if the video is coming through correctly then it’s likely not an issue. > [@jseifert](#): > > Then, I set the MAVProxy --streamrate to 2 Hz ([http://192.168.2.2:2770/mavproxy](http://192.168.2.2:2770/mavproxy)), and the system cooled down. > … > I’ll give it another try today and hope the systems will operate. Otherwise, I would have wasted a lot of time and money for field work in the Caribbean. Did you manage to get this working? We’re working on a companion update at the moment that should reduce CPU usage and will hopefully solve this and a few other issues people have been having, but I can’t guarantee a release time for it (we’re hoping for tomorrow). Would be great if the streamrate reduction has helped enough for your current work 🙂 > [@jseifert](#): > > I tried to update the Ping1D firmware directly connecting its UART interface to the topside using an USB cable (COM7, 115,200 bits/sec) Can you confirm you were trying Ping1D → USB-Serial converter (e.g. BLUART) → microUSB to USB cable → computer running Ping Viewer? > [@jseifert](#): > > and the command prompt message log still comes up Apologies - it seems there was an issue with an automated build not happening properly. If you download again now you should get version 2.2.1, which should fix the command prompt issue. ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [August 5, 2021, 1:47am UTC](https://discuss.bluerobotics.com/t/ping1d-causing-throttling-and-under-voltage-on-raspberryi-pi-3b-resulting-lag-on-qgc/9906/8 "2021-08-05T01:47:38Z")
> [@EliotBR](#): > > We’re working on a companion update at the moment that should reduce CPU usage and will hopefully solve this and a few other issues people have been having Companion 0.0.27 is now available: > [@Companion 0.0.28 Update!](https://discuss.bluerobotics.com/t/companion-0-0-27-update/10349): > > Hi everyone, We’ve just released a new stable version of the Companion software! smiley For a formal summary check the [release notes](https://github.com/bluerobotics/companion/blob/master/release-notes.txt#L174-L183), but here are the main points explained: Reduced CPU usage (should reduce/fix video dropouts/poor quality) Fixed bug stopping the heartbeat failsafe from working correctly Fixed bug causing [missing Wifi SSIDs](https://discuss.bluerobotics.com/t/can-not-find-wifi-network/9996) (\*see below) change default waterlinked underwater gps hostname from waterlinked.local to 192.168.2.94 Normal Update If you don’t have missing wifi SSI…