Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 08-10-2015, 09:51   #16
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Navico RADAR Plugin Optimization

Quote:
Originally Posted by NahanniV View Post
Some suggestions:

-First make sure it works with the inbuilt emulator (may not load the system like the real RADAR).
The emulator works
Quote:
-Use your CubieTruck.
I am not so eager to plug my hardware in other boats now
Quote:
-Use TcpReplay to replay captured RADAR data;
Either get a pre-captured file or make your own with WireShark.
I will try this.
Quote:
-Try it with WiFi, apparently some routers will pass the traffic OK.
Maybe can try too.
Quote:
Hopefully your HDMI monitor wasn't damaged ?
Well luckily is is not my hdmi monitor. Anyway, it appears the monitor is ok, but only tested in vga mode as this guy doesn't use it in hdmi anyway.


Anyway, I fixed the problem with dropouts and put all the heavy lifting in the receiver thread, then switched to vbo model so it should be much faster. I also implemented support without opengl, and was considering using gradual colors rather than fixed ones.
__________________

__________________
boat_alexandra is offline   Reply With Quote
Old 08-10-2015, 11:22   #17
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Navico RADAR Plugin Optimization

How do I invoke tcpreplay?

I have
Code:
sudo tcpreplay -i wlan0 dump.pcapng
I can see the packets in wireshark but nothing in opencpn.
__________________

__________________
boat_alexandra is offline   Reply With Quote
Old 08-10-2015, 20:54   #18
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: Navico RADAR Plugin Optimization

Quote:
Originally Posted by boat_alexandra View Post
How do I invoke tcpreplay?

I have
Code:
sudo tcpreplay -i wlan0 dump.pcapng
I can see the packets in wireshark but nothing in opencpn.
I think you have it correct, I'm using:
sudo tcpreplay --loop=0 --intf1=eth0 XXXX.pcapng

Perhaps it's a problem using wlan ?

From: FAQ – Tcpreplay

Quote:
Can tcpreplay send packets over WiFi?

This turns out to be very OS/hardware dependent, but in many cases, the answer is yes. In order for things to work, you generally must do the following:

Put the WiFi card in managed mode
Your pcap files need to be DLT_EN10MB (Ethernet) and have a valid 803.2 header
The source MAC of the packets need to match the MAC of your WiFi card
__________________
NahanniV is offline   Reply With Quote
Old 09-10-2015, 00:33   #19
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Navico RADAR Plugin Optimization

Quote:
Originally Posted by NahanniV View Post
I think you have it correct, I'm using:
sudo tcpreplay --loop=0 --intf1=eth0 XXXX.pcapng

Perhaps it's a problem using wlan ?

From: FAQ – Tcpreplay
Well I have tried with both wlan and lo. I don't physically have an ethernet port. Who designed this radar anyway? It is nearly impossible to configure over a network properly when it is broadcasting udp packets from several ip addresses.

I don't understand why the radar doesn't run a small web server which hosts an image of the radar automatically refreshing. Next, I should connect to the radar using tcp and be able to configure it and receive data this way.

A udp mode could be allowed but it really isn't needed. Maybe it is theoretically better for this but in practice it just isn't easier to use. At least the control socket should be tcp, then it can transmit udp packets for data or something.
__________________
boat_alexandra is offline   Reply With Quote
Old 09-10-2015, 04:21   #20
Registered User

Join Date: Oct 2011
Location: Apeldoorn
Boat: Ovni 385
Posts: 91
Re: Navico RADAR Plugin Optimization

The Lowrance 4G radar only has one IP address. When you use a DHCP server it will get an IP address from that server in the assigned range. However for the UDP broadcasts it uses broadcast addresses, each broadcast address is connected to a specific port number. The client (user) can subscribe to one or more of these addresses and listen on the specific ports. I have no opinion if this is a good design, we only have to work with it. Douwe Fokkema
__________________
Douwe Fokkema is offline   Reply With Quote
Old 09-10-2015, 05:59   #21
Registered User

Join Date: Oct 2011
Location: Apeldoorn
Boat: Ovni 385
Posts: 91
Performance of OCPN with radar_pi

Regarding performance of the radar_pi, this is more complicated than it seems.

To start with, there is the load of OCPN. But all loads are very much system dependent.
Say on a given machine the basic OCPN CPU load is 1 %. Running full refresh speed (30 refresh / second), this will increase to 30%. If load of the radar_pi is 10%, total would be 40%. So we can only influence the last 10% of the 40%.

Real example: Fast I7 Windows 10 machine with Geforce video card.
OCPN CPU load incl. radar_pi (according to Resource Monitor) 15%. Running maximal refresh, actual 30 refresh / second. For the number of refreshes I included a counter.
Then I modified the radar_pi to use OpenGL Vertex Array Buffers, filling the buffer with vertices directly from the receive thread. Result: CPU load and number of refreshes exactly the same.

Then I tried cutting out DrawRadarImage to eliminate all load of the display process.
Result: OCPN CPU load goes up to 24%. Still running 30 refresh cycles / second. So please understand I am puzzled.

Same experiment on small laptop, Intel Atom, integrated Intel video, Win7. Running the version with Vertex Array Buffers.
CPU load 43%, running 10 refresh / second. Good radar image.

Cutting away the DrawRadarImage:
CPU load 34%, running 30 refresh cycles / second. So yes, on small machines the display process might be improved. So may be using VBO will improve things. I tried to implement. But I could not add the glGenBuffersARB call, as the libraries to be loaded are dependent on the manufacturer of the video card. This is not practical for a distributed program. Is there a better solution?

Douwe Fokkema
__________________
Douwe Fokkema is offline   Reply With Quote
Old 09-10-2015, 06:37   #22
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: Navico RADAR Plugin Optimization

Quote:
Originally Posted by boat_alexandra View Post
Well I have tried with both wlan and lo. I don't physically have an ethernet port.
"lo." do you mean local ? If so: From the TcpRelay FAQ:
Quote:
Can I send packets on the same computer running tcpreplay?

Generally speaking no. When tcpreplay sends packets, it injects them between the TCP/IP stack of the system and the device driver of the network card. The result is the TCP/IP stack system running tcpreplay never sees the packets.
Quote:
Originally Posted by boat_alexandra View Post
Who designed this radar anyway? It is nearly impossible to configure over a network properly when it is broadcasting udp packets from several ip addresses.

I don't understand why the radar doesn't run a small web server which hosts an image of the radar automatically refreshing. Next, I should connect to the radar using tcp and be able to configure it and receive data this way.

A udp mode could be allowed but it really isn't needed. Maybe it is theoretically better for this but in practice it just isn't easier to use. At least the control socket should be tcp, then it can transmit udp packets for data or something.
Frustrating, but no hope of changing it, they will not even consider releasing an interface document.

Cheers,
JM.
__________________
NahanniV is offline   Reply With Quote
Old 09-10-2015, 13:18   #23
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Performance of OCPN with radar_pi

Quote:
Originally Posted by Douwe Fokkema View Post
Regarding performance of the radar_pi, this is more complicated than it seems.

To start with, there is the load of OCPN. But all loads are very much system dependent.
Say on a given machine the basic OCPN CPU load is 1 %. Running full refresh speed (30 refresh / second), this will increase to 30%. If load of the radar_pi is 10%, total would be 40%. So we can only influence the last 10% of the 40%.
With fbo support the load to opencpn should be minimal even at 30 frames a second. Perhaps with additional plugins it could be a problem.
Quote:
Real example: Fast I7 Windows 10 machine with Geforce video card.
OCPN CPU load incl. radar_pi (according to Resource Monitor) 15%. Running maximal refresh, actual 30 refresh / second. For the number of refreshes I included a counter.
Then I modified the radar_pi to use OpenGL Vertex Array Buffers, filling the buffer with vertices directly from the receive thread. Result: CPU load and number of refreshes exactly the same.

Then I tried cutting out DrawRadarImage to eliminate all load of the display process.
Result: OCPN CPU load goes up to 24%. Still running 30 refresh cycles / second. So please understand I am puzzled.

Same experiment on small laptop, Intel Atom, integrated Intel video, Win7. Running the version with Vertex Array Buffers.
CPU load 43%, running 10 refresh / second. Good radar image.

Cutting away the DrawRadarImage:
CPU load 34%, running 30 refresh cycles / second. So yes, on small machines the display process might be improved. So may be using VBO will improve things. I tried to implement. But I could not add the glGenBuffersARB call, as the libraries to be loaded are dependent on the manufacturer of the video card. This is not practical for a distributed program. Is there a better solution?

Douwe Fokkema
First of all, where is your code? I want to play with it.

Simply glDrawArrays can be used. The idea is the small slower computers have multiple cores, so they can assemble the geometry in ram in a background thread. Even if the cpu percentage isn't reduced, it improves things by freeing up the main thread.

Now, it may be possible to push only the pieces of the vbo that actually updated with incoming scans, and this may or may not be faster depending on implementation and driver.

Finally, I still believe the ultimate solution is to just stick the raw data into a single channel (luminance or alpha) texture and upload it. This is going to be relatively fast. Then render a quad to cover the entire radar area and write a fragment shader to convert the texture coordinates from rectangular to polar. This method also would improve image quality, but would require shader support.
__________________
boat_alexandra is offline   Reply With Quote
Old 09-10-2015, 14:24   #24
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 9,398
Re: Navico RADAR Plugin Optimization

Sean try

https://github.com/douwefokkema/BR24radar_pi
__________________
rgleason is offline   Reply With Quote
Old 10-10-2015, 12:03   #25
Registered User

Join Date: Jan 2010
Location: Harlingen, NL
Boat: KMY Stadtship 56
Posts: 205
Re: Navico RADAR Plugin Optimization

I have just pushed Douwe's optimizations to the main branch and released v1.3 based on this.

See the main BR24 thread for the rest of the cool features that are in this release.
__________________
merrimac is offline   Reply With Quote
Old 10-10-2015, 12:10   #26
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Navico RADAR Plugin Optimization

I just reduced the cpu usage by a factor of 6 by programming a shader in the gpu so it doesn't need triangles anymore. Now the cpu is 4% refreshing 20 frames a second from the radar.

github.com/seandepagnier/BR24radar_pi -b shader
__________________
boat_alexandra is offline   Reply With Quote
Old 10-10-2015, 12:42   #27
Registered User

Join Date: Jan 2010
Location: Harlingen, NL
Boat: KMY Stadtship 56
Posts: 205
Re: Navico RADAR Plugin Optimization

Note that those changes make the code use vertex buffers, not shaders. So we're still eagerly awaiting your code, Sean!
__________________
merrimac is offline   Reply With Quote
Old 10-10-2015, 13:50   #28
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 2,810
Re: Navico RADAR Plugin Optimization

I just posted a link to it in the last post. Please give me feedback because I am getting 6% cpu with my shader vs 35% cpu from the vbo work which was already a great improvement from the last release.

Mine builds on the work with vertex buffers and falls back to it if it cannot create the shader (or the user can set that option in the preferences)
__________________
boat_alexandra is offline   Reply With Quote
Old 10-10-2015, 19:15   #29
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: Navico RADAR Plugin Optimization

Quote:
Originally Posted by boat_alexandra View Post
I just reduced the cpu usage by a factor of 6 by programming a shader in the gpu so it doesn't need triangles anymore. Now the cpu is 4% refreshing 20 frames a second from the radar.

github.com/seandepagnier/BR24radar_pi -b shader
Tried your version on my CubieTruck:

Lots of warnings building, mostly unused and uninitialized variables.

RADAR image is rotated +90deg. (only tested non overlay).

OpenCPN aborts as soon as "Use Shader" option is selected.

Here is DBG and Bactrace:
Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xad850270 (LWP 5505)]
memset () at ../ports/sysdeps/arm/memset.S:47
47    ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../ports/sysdeps/arm/memset.S:47
#1  0xadc8c066 in memset (__len=512, __ch=0, __dest=<optimized out>)
    at /usr/include/arm-linux-gnueabihf/bits/string3.h:84
#2  br24radar_pi::PrepareRadarImage (this=this@entry=0xad851008, 
    angle=angle@entry=1994)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:1968
#3  0xadc964ae in RadarDataReceiveThread::process_buffer (
    this=this@entry=0x59ee90, packet=packet@entry=0xad83ffec, 
    len=<optimized out>)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3565
#4  0xadc98438 in RadarDataReceiveThread::Entry (this=0x59ee90)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3387
#5  0xb6f32d16 in wxThread::CallEntry() ()
   from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#6  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#7  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Cheers,
JM.
__________________
NahanniV is offline   Reply With Quote
Old 10-10-2015, 20:47   #30
Registered User
 
NahanniV's Avatar

Join Date: Mar 2011
Location: On the Boat
Boat: Finnsailer 38
Posts: 1,144
Re: Navico RADAR Plugin Optimization

On further investigation:

The log says "shader not supported"

the crash only happens if the RADAR is sending data when the shader option is checked.

Can this be made to work on the cubietruck ?


Quote:
Originally Posted by NahanniV View Post
Tried your version on my CubieTruck:

Lots of warnings building, mostly unused and uninitialized variables.

RADAR image is rotated +90deg. (only tested non overlay).

OpenCPN aborts as soon as "Use Shader" option is selected.

Here is DBG and Bactrace:
Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xad850270 (LWP 5505)]
memset () at ../ports/sysdeps/arm/memset.S:47
47    ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../ports/sysdeps/arm/memset.S:47
#1  0xadc8c066 in memset (__len=512, __ch=0, __dest=<optimized out>)
    at /usr/include/arm-linux-gnueabihf/bits/string3.h:84
#2  br24radar_pi::PrepareRadarImage (this=this@entry=0xad851008, 
    angle=angle@entry=1994)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:1968
#3  0xadc964ae in RadarDataReceiveThread::process_buffer (
    this=this@entry=0x59ee90, packet=packet@entry=0xad83ffec, 
    len=<optimized out>)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3565
#4  0xadc98438 in RadarDataReceiveThread::Entry (this=0x59ee90)
    at /home/aruntu/seans_radar/BR24radar_pi/src/br24radar_pi.cpp:3387
#5  0xb6f32d16 in wxThread::CallEntry() ()
   from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#6  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
#7  0xb6f33118 in ?? () from /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Cheers,
JM.
__________________

__________________
NahanniV is offline   Reply With Quote
Reply

Tags
navico, plug, radar

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Radar Overlay PlugIn bdbcat OpenCPN 789 02-12-2017 04:23
Navico radar plugin hardware connection mikereed100 OpenCPN 8 07-12-2015 10:44
Bonehead Award - Navico 3G Radar Cap Erict3 Marine Electronics 30 17-07-2015 22:22
AIS Radar plugin wizard-merlin OpenCPN 1 04-08-2012 08:59
Navico BR24 Radar - Open Source protocol implementation maxxflow OpenCPN 23 30-07-2012 05:20



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 04:37.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.