OpenCPN for Android Beta test 4.1.718

[Hakan]

Peter...
The Net segment you're using is working well for me to transfer between Windows and Linus PCs.
Have you checked that your net, wifi etc, really use the 192.168...... segment? Check an IP address on one, or several, of your equipment.
Håkan

[ejs]

Peter,

I also use that type of config to get data to OpeCPN, I think you need to check your IP addresses, the 0.0.0.0 doesn't look right to me for input as that number is usually non-routable and used for errors etc.

Eric

[Neptune's Gear]

Peter, Eric is correct, 0.0.0.0 is not a valid address. Networking 101...


So, first, find out what address your Wifi is using. - the subnet (first 3 groups of numbers between the dots. eg 192.168.0.x Forget the X for now. In windows you can use ipconfig /all from a command prompt to get this info.


Then, if you want the transmitted data to be available to all the devices on that subnet, you want to use the broadcast address for that subnet - so change the last set of numbers in your OPCN setup to .255 - so in the case above 192.168.0.255 - in your case ?.?.?.255 depending on your subnet.


You can use this address for both send and receive, and on multiple devices. It is a broadcast address that will send to/receive from any device on that subnet.
If you have multiple NICs on a PC this is how you tell OCPN which NIC and Subnet to use. :-)
Good Luck

[petter5]

Originally Posted by Neptune's Gear

In windows you can use ipconfig /all from a command prompt to get this info.

And in linux, you can use from a terminal:

ifconfig eth0

if you have more than 1 network card, to show info for these cards, increase the number after eth, like eth1 eth2 etc

ifconfig eth1

,,,,
/P

[ejs]

Peter, Neptune,

Peter is using UDP so I don't think using the broadcast address 255 is a requirement. My system uses 10.0.0.1 (1 may be another special address, but I don't think so) Is there an advantage to using the 255 broadcast address when using UDP?

Eric

[Wrong]

These little devices do not have the raw horsepower of a modern x86 machine. They don't have the RAM capacity, they run many many background tasks/threads which cannot be eliminated, and their bulk storage (sdcard) is not particularly fast. OCPN has to share these limited resources with everything else that is running on the device.

Two apps downloadable from Google Play, 'Advanced Task Killer' and 'App Quarantine' are very effective at controlling tasks that self launch and 'run in the background'.

Highly recommended!

[RSkillings]

Originally Posted by Wrong

....from Google Play, 'Advanced Task Killer' and 'App Quarantine' are very effective at controlling tasks that self launch and 'run in the background'.

Sounds like the Android equivalent to Windows' Task Manager ?

If so, this would be a quick way to check for unwanted apps taking up CPU cycles and would keep the Android 'focused' on O-A tasks.

I'll check it out, thanks.

[Peter McNamara]

Eric, Matt and Hakan


I have only cloned the UDP config already recommended by yourself Hakan (and Dave from memory), in another thread started by me on this forum. The setup already works as demonstrated between the 2 Windows 7 Notebooks, so today I have experimented with turning off firewalls and security apps on both peers in case that was the cause. No luck. I am now wondering if this is a permissions issue regarding the network devices used by the WiFi since I have not gone to the trouble of "rooting" either Android device so the user that has installed the OpenCPN app may not have read/write access to the necessary WiFi devices within the OS?


Other comments are:


The install on the Lollipop HTC One appears unstable particularly when accessing the network setup screens. The HTC app does not appear to be able to access the internal GPS. I have read other threads regarding security features implemented in Android 5.0 that may be the cause.

[Neptune's Gear]

Peter, First, I must admit I don't have a lot of experience with UDP!


However my OCPN works on a 3 NIC pc with broadcast on UDP on the wifi subnet. I can connect any device (PC, Andriod, IPAD all work)


Here is my current understanding.


UDP can be point to point, or point to multi point (Broadcast). If you use 10.0.0.1 that is a private IP, but it most likely the IP of the NIC in your source PC. If there is only one NIC, this will likely work.


Copying someone's config may or may not work - it depends on the settings on YOUR system. Common addresses are 192.168.x.x (The X.X does not mean type in X, it stands for an unknown number 1-254) This, and the 10.0.0.x are common private IP addresses. Addresses and your network are also controlled by the mask. It is too complex for me to try to explain here, but if you Google IP subnetting, you can find everything you may want to know!


IMO it is good practice to use the correct broadcast address (normally, but not always x.x.x.255) if your intention is to broadcast data. I simply don't see a reason not to.


If you have more than 1 NIC in your PC, you will NEED to have the addressing correct to ensure that the data is broadcast on the right subnet. If it is wrong, your receive devices will receive nothing. First though, check that the data is going out with the NMEA monitoring window - it should show the data as "out" and show the ip and port it's sent on.


Others, who understand this more than me might contribute some more...


Matt

[Hakan]

Peter...
I've used that UDP concept also trough a wifi net as a "one to several" - setup.
I should have checked first that your wifi net is working between Win/Linux and if so connected also the Andriod. I've no experiences of tablets or phones so it may be different there? (BTW, was the Android IP address in the correct segment, e.g. 192.168..?)
Håkan

[Peter McNamara]

Hakan and Matt

If I use the actual DHCP service assigned IP address viz 192.168.137.1 assigned by the PC to localhost (itself) on both the Android and Windows OCPN it works. I wish I had not slept through the lecture on UDP networking back at Uni now :-(

The setup that I had been using with the PC's was exactly as I have stated above (ie. literally including the x.x bit). Anyway I have a solution I suppose. Would be good to know what's going on though.


Here is a link to the original thread:


http://www.cruisersforum.com/forums/...ws-134073.html

Thanks for your interest.

Cheers

Peter Mc

[rgleason]

I recently compiled for windows and got v4.1.718 so that I could test ovpn_draw. This weekend I found that version crashed several times while using for nav on the boat. Went back to v4.0 and had to rebuild all the charts. I have found v4.1.602 to be stable enough on a long cruise. Is this version 4.1.718 not one I should be using for nav on the water yet?

[CarCode]

The actual v4.1.718 has some code changes which might have been tested for Raspberry Pi and Android but obvious not for any other OS. Especially the new compass/gps status window code crashes. So don't use it.

Gerhard

[ploubaz22]

I have lot off crash this week with thé version 4.1,718 if I change thé date to first july I have no crash open cpn work fine

[pbenaben]

Hello,

I'm using with lenovo TAB 2 A7-10F
Android 4.4.2
Opencpn is not on SD card. install from scratch.

I find the following issues:
In OpenCPN Settings, impossible to save Display options. The workaround is after changing the display option, go in the chart options, configure install chart file, press ok (even with no changes), then press back until coming back on the main screen.

I could not load a gpx file. I didn't find a workaround (except rekeying the waypoints).

but rest works well. great job !

regards.

Philippe