use web browser like AIS-catcher main app

[g7ruh]

Jasper

I have loaded the ap and tested with an RTL-SDR dongle. Rather than use another app to view the data, is it possible to have the web server functionality from AIS-catcher added to the Android version?

If so, will it be possible to use the device GPS to provide location data for the web server map?

It would make it a "one stop shop" for AIS-catcher when mobile.

Thanks

Roger G7RUH

[jvde-github]

Hi Roger, that is a great idea. I will add it to the list but it is quite a bit of work and the app is little used.

This app also seems to be nice and is the concept you are referring to I believe: https://play.google.com/store/apps/details?id=net.videgro.ships

Jasper

[g7ruh]

Jasper,

Yes that is the concept.

I have tried using a 'Pi as a router for WiFi but I assume that AIS-catcher requires an internet connection to use e.g. JSDelivr and unpkg so AIS-Catcher will not run correctly without the internet? The idea being that I can take a 'Pi to the beach and have WiFi connectivity for a few users to access AIS-catcher web pages on the 'Pi.

I have had your Android app on my list of things to do, so after the above, I gave it a try and thought it would be a far more simple solution anyway, hence the request.

I have a USB C multi port adapter so I can use that for the RTL-SDR and also provide power for phone and dongle.

Happy to test when you are ready. Of course the app may get used far more if it has the kind of usability that the web interface provides.

Roger

[jvde-github]

Something like this. It will require an internet connection though to get the map tiles.

Will share when there is more to test, but will be basic....

[g7ruh]

Jasper,

basic is fine!!! Would be good to be able to identify the vessel name. If you are at the beach and showing sonebody the app and functionality, it is nice to point at a vessel and give it a name.

Are map tiles cached locally if previously downloaded from e.g. an earlier session?

Roger

[jvde-github]

Likely not initially (Google maps has that option but is not free).

It works, but not very happy with the quality, it will take a lot of work to get it in an acceptable form.

[g7ruh]

It will be good enough to try and test like that though

Roger

[jvde-github]

I solved it differently. The build-in webserver can be enabled via the settings menu. This will run the app as-is but if you press the Web button it will open a browser with the sever that will then display the normal webinterface.

Note that the interface will only run if decoding is active.

[g7ruh]

That looks good. I am busy for a few days, I will give a longer test later in the week. I will also do some battery life related measurements.

Roger

[jvde-github]

Also got it running nicely embedded in the App. I think it looks great :-)

[g7ruh]

Great? Nope, Brilliant is a better description. Nice work. Have you updated the app yet?

Should get to battery life related stuff at the weekend. Initial look suggests about 0.75A at 9V off the phone charger (battery fully charged), with dongle (RTL-SDR V3) using 0.28A at 5V. I am waiting for a https://www.anandtech.com/show/18944/usbc-power-metering-with-the-chargerlab-km003c-a-google-twinkie-alternative but not due until end of month (all the way from China, where else).

I will also take it to the beach and provide a suitable photo.

[g7ruh]

Is it possible to enable phone GPS to use current location so distance and bearing work too?

[g7ruh]

Battery use: (got to it earlier than planned: waiting for a delivery at home)

5V in to usb multiport adapter 0.75A to 0.85A AIS-catcher running and displaying map. about 1A when scrolling map.

RTL-SDR V3 uses 0.27A while AIS-catcher is running and 0.07A when AIS-catcher is not running, but dongle plugged in.

Phone uses about 0.45A when AIS-catcher is not running

AIS-catcher CPU use is low when monitoring the CPU use pane from Developer Options GPU Watch. Goes to about 50% when scrolling map (that is expected), but apart from that it does not show a significant difference from when AIS-catcher is not running

[jvde-github]

Thanks for sharing. Is there a big difference in consumption for different sample rates?

I have submitted an updated app to the Play store. This will automatically start the webserver at a port that is listed in the "Stat Tab". There is a tab for the map and one with the standard performance graphs. These are basically webviewers displaying one tab of the standard webclient. It is quite memory consuming so perhaps I will just create one webview and run the tabs from the standard web interface.

The problem with that is that the web interface requires a modern browser, so doing so will limit the use of the app for older Android versions.

[g7ruh]

Is there a big difference in consumption for different sample rates?

I will try at the weekend. My thought is that CPU usage is quite low anyway when it is running so a change in sample rates will not make much difference.

What about GPS use?

Older browsers, good point, I ran a rather old Android phone until my Galaxy Note 20 Ultra. The browser got so slow that I just had to upgrade!

Maybe you just have to live with that. How many users would you miss if you did not support older browsers?

[jvde-github]

Hi Roger, I have changed again and now the whole middle part of the screen is a permanent webview running the standard webclient. I had the impression that the Android tabs (which stop and start the webbrowsers) were causing instability. For really old versions we show a native statistics tab.

It still looks great but on older versions of Android that do not run our standard web client, the middle part of the screen might be corrupted. This actually saves a lot of development work. There are only a few users anyway.

I will look at a GPS interface soon, should not be to difficult but first trying to get this stable.

I think the majority of the power consumption comes from the RTL-SDR, and was wondering whether at a lower sampling rate this was less....

[g7ruh]

OK, understand your thinking re sample rate, I will test for that at weekend. Honey-do list takes priority though! May not be too many boats about at W/E .... strong wind warning in these parts, so it will be rather blowy and not good for a long stay at the beach. I may wait for a better day to go portable with the portable AIS-catcher setup.

[jvde-github]

No rush, it is a hobby! I can only test it on virtual devices and my phone (Galaxy S6). So any feedback on stability is welcome.

In the meantime I will clean this up and add a link with the phone GPS when available.

Cheers, Jasper

[jvde-github]

Hi Roger, also the GPS feed from the device to the web interface has now been implemented. So that means that distances are measured and available if the app gets the permission to read the location (updated every 5 minutes).

Have a good weekend, Jasper

[g7ruh]

Thanks Jasper,

re your lack of real devices for testing, I will run several longer term stability tests (i.e. several hours).

I will also do some tests for sample rate V dongle current use. I will do these on two systems, 1) my test environment which is in the house and has low message rate / sec (less than 1) and 2) also using the main antenna splitter feed where the messages / sec is typically 8 to 12 messages / sec daytime. This weekend it may be less as the weather is wet and very windy. We do need the rain, tonight is the first evening since I planted the summer bedding plants a few months ago that I have not had to water them. More time to play with radio stuff :)

initial test today suggests sample rate changes makes no difference currnet consumption wise at low message rates. Will repeat as above with high message / sec.

Have a good weekend too. Roger

[g7ruh]

Jasper,

is it possible to make the app full screen or only the web server pages?

Roger

[jvde-github]

Does it help when you click on "Web Client" and view the standard website in a browser. That has a full-screen mode as well, does not have the device start/stop bar, menu bar is collapsible, etc.

So, not yet in the app itself.

[g7ruh]

Yes web client is fine, just wondered if the main app can or will do so. OK if it is on your radar.

Getting on with testing: run the app for 4 hours (connected to power supply, of course) stable, no failures. Current consumption when 5-6 msg / sec similar to 0.5 msg/sec. Also same consumption for all scan rate settings when 5-6 msg/sec. Currently running longer test on main aerial so higher msg / sec

[g7ruh]

Jasper,

Some test results from different dongles. Using main system and both test and live connected via VHF splitter, so have the same signal.

The current consumption is the same for all sample rates.

It would be helpful for testing to reset the connect time when clearing other data, but no big deal.

Is it possible to keep the RTL-SDR setting, it reverts to TCP every time you disconnect a dongle. It gives me an error message that it cannot find TCP connection, so the same thing could happen if the dongle is not there at startup. I do like the auto start if dongle detected.

As per the table data, you will see that SN 111 has a very low rate compared with live system and SN 300 has no data. This is because the PPM as calibrated is such that it is out of range partly or totally. I think PPM correction setting is needed to allow for some wide ranges of PPM.

Current was measured at the the dongle (between the multiport usb A and the dongle). I used a USB C multiport adapter to feed power to the phone and dongle.

I cannot attach a .pdf or .ods file, I will email.

Roger

[g7ruh]

I have run AIS-catcher on the phone for about 6 hours today and at least 4 yesterday. No issues, problems or crashes so far. It seems quite stable.

Weather still not sutable for a visit to the seaside! So have not verifed works when I move. It gives me distance and bearing so it is working.

[jvde-github]

Hi Roger,

Thanks for your testing and ideas. It definitely has become a more robust and interesting app over the last few days.

just uploaded the latest version with a few small changes:

• if an RTL-SDR is connected when the program is open, it will automatically set that as source
• when the user presses clear, the running time is reset
• fix to show the range on the map

You mention the SN 111. For information, the PPM can be set in the Settings menu and the decoder is the latest version with the increases frequency stability. So in theory can perform similarly to the RPi version but quality of the USB hardware can play a role.

Interesting that the sample rate and data flow do not impact the power consumption. Did not expect that. I might then change the default to 1536K which gives better results.

I will have a closer look at your PDF. Thank you!

[g7ruh]

Jasper, am I being silly? I cannot find a App version number anywhere? I have looked. Edit: I see it on the web page stats, but not on the app page stats. Roger

[jvde-github]

Thanks, good point! I have added it to the About dialog and also added a Logs menu item to help troubleshoot if and when needed. Once approved by Google will be available in the store.

[g7ruh]

Jasper I repeated the tests with PPM set, used all 4 dongles so comparable with previous tests for SN 444 and SN1000 as they are temp compensated.

SN 300 is a little 'deaf' and never gets as many vessels as the other ones. I use it for testing as it has a huge PPM difference.

All devices showed maximum deviation of +1 to -1 on the Freq Shift (ave PPM / min) graph.

When testing dongles on the 'Pi I have consistently found better performance when gain is set manually and the automatic gain is OFF.

The method I use to set is: use the App Signal Level min / max dB per min graph. Increase gain until max is over 0dB, then back it off slowly until the max is about 0dB during daytime over an hour or two. That seems to give a good minimum of -40 to -50. If auto gain is on, the range is much less (base is e.g. -35dB) so get less of the weaker signals, I suspect.

The conclusion from these tests is that the Android App is not (yet) as sensitive as the 'Pi app using the same aerial via a splitter. In percentage terms, the App is about 10% lower. No big deal for occasional use (my use case) the biggest feature is using it portable e.g at the beach or near the docks.

Dongle serial numbers in below tables 444 (RTL-SDR V3), 1000 (FlightAware Orange), 111 (RTL-SDR V2) and at the bottom 300 (RTL-SDR V2)

I will email the spreadsheet, Sheet 1 is the main data, Sheet 2 has percentages added.

Data from both tests below:

I hope that gives you a better idea of performance. Pretty good I would say.

Roger

[g7ruh]

There are a few differences between the Summary page on the App and on the web page. The App Summary screen starts at "Sampling rate"

The web page has Station down to Memory and then the data the same as the App.

However, on the Web Page, the device information is not populated.

Another minor issue:

If I go from Summary to Plots and do not scroll plots and return to the Summary screen it goes to the same place (top of page).

If I go from Summary screen to Plots and scroll down (a little or a lot) and then return to the Summary page, it returns a few lines down, with the Last Day line appearing at the top of the page. Both Ships and Map pages return to the top of the Summary page.

[Taxom]

The auto gain in a dongle not intended to work with narrow band periodic short digital packages. Therefore, it is trying to adjust the gain by the sum of the signal with the background noise.

[jvde-github]

Hi Roger,

Thanks for extensive testing. At first sight it looks pretty good and stable! Might be small losses due to quality of USB port on Android and OTG cable so pretty happy with this.

It is intentional that the app and the webclient have slightly different screens. The webclient now shows the device that is running (vendor and serial to follow). I also made some other smaller fixes. Including embedding all icons in the program. Some of them have to be re-aligned now but this is more robust.

I understand where the issue with the scrollbar is coming from. Add it to the list to fix.

[jvde-github]

Also cleaned up the scrollbars (which are now independent per tab) and some other tidying up of the UI. Should be in the Play store later today.

Thanks for flagging!

Edit: had to reverse the scrollbar fix, had more issues than it solved, to be continued :-( Edit2: I think it is solved now :-) The other reason for the difference might be the settings including the sample rate, which is 288K default for Android and 1536K for the command line version.

[jvde-github]

Since this has been implemented, I am closing this item so we can put new issues in new threads.