AIS Class B delays

[Roberto]

.

In post #25 you stated that there are 4000 slots per second for AIS transmission; I believe this is actually 4500 per minute or 75 per second. Taking the higher 4s transmission rate for messages gives bandwidth for up to 300 vessels. Allowing for the additional slow rate transmissions and slot finding time it's probably closer to 250. That should be plenty for even the most crowded locations.

The problem might be the class B timing: as I showed in a previous message, class B may not be continuously looking for a free spot, but just over a very short period every 30 seconds. Airwaves may be almost totally free, but if every time a class B senses the presence of a carrier it find a class A, it might postpone its message by a further 30 seconds, even if 29 of them are totally free of any ais message.

 

[GHA]

Does anyone have a list of ais messages? Working at the mo but lots downtime and a laptop/esp8266 so I could see just how quickly opencpn can keep up with incoming messages.

Or San Francisco used to have a live tcp/ip feed but I can't find the ip address, anyone got it?

TIA

 

[GHA]

Does anyone have a list of ais messages? Working at the mo but lots downtime and a laptop/esp8266 so I could see just how quickly opencpn can keep up with incoming messages.

Or San Francisco used to have a live tcp/ip feed but I can't find the ip address, anyone got it?

TIA

Don't worry, found some.
I'm sending these 4 messages every 5 seconds with a 50mS gap between each message from a esp8266 (sort of like an arduino with wifi) over usb-serial into opencpn.
!AIVDM,1,1,,A,13HOI:0P0000VOHLCnHQKwvL05Ip,0*23
!AIVDM,1,1,,A,133sVfPP00PD>hRMDH@jNOvN20S8,0*7F
!AIVDM,1,1,,B,100h00PP0@PHFV`Mg5gTH?vNPUIp,0*3B
!AIVDM,1,1,,B,13eaJF0P00Qd388Eew6aagvH85Ip,0*45

Works, one thing straight away, the opencpn dialog report age is the time since opencpn read the message, not the real age of the message. This might mean that the software is struggling to keep up in your case, not the ais system.

Edit - just tried it with a 10mS gap between each of the 4 messages, still seems to read them OK.
Hmm...

Edit again..
And sending with a 1mS delay between each message..still getting them..

 

[GHA]

OK, no waiting after the 4 messages have been sent now, so opencpn is quite happily running fine apparently reading 1,000 messages every second ( I can't count that fast )

Seems to be no difference in panning or zooming on a win7 laptop - so might not be the software after all. What you would expect, it's a robust program, something like that you would hope would have been picked up on ages ago.

Even so, still doesn't mean it's the ais system, the software looks like it works on when the report was received by the computer, not the time stamp of the message. Might be your receiver is struggling with so many messages.

edit again! Thinking about it, live the time stamp should match the time the message was received through the ether so probably of no concern. Anyway, marinetraffic will show the solent full of class B on a summer sunday so maybe it's the reciever having trouble keeping up, not the ais system itself? Interesting though.

 

[JohnGC]

Re: more information

But to refer back to my post, for commercial vessels transiting the TSSs in the North Adriatic the most likely collision risks will almost certainly be the many leisure craft crossing the lanes on passage between Italy and Croatia/Slovenia. As you say, I have no proof that those commercial vessels are monitoring Class B but they would have to be mad not to be.

Richard

Not mad, there may be good reason.

I've been reading through a thread I found on the gCaptain Professional Mariner Forum. It's a few years old but provides some interesting insights. It was started by a single handed yacht owner asking about various aspects of commercial shipping bridge practice including the monitoring of class B AIS.

The responses include those who never filter out class B and those who do. I'd say more don't filter out AIS than do but it's not a large sample.

Those who do monitor class B like the additional information it gives them; but they are still using radar as the primary tool. One chap in particular likes being able to call a small boat by name with information given via AIS.

One who doesn't monitor class B gives some detailed information about his watch keeping methods. Roughly the argument goes like this;
- Radar is the primary tool.
- AIS data is overlayed on the radar display.
- Class B data updates much more slowly than the radar return.
- Class B targets may appear on radar before AIS (surprising but in line with this threads OP's observation).
- AIS is dependent on third party equipment whereas radar is not.
- AIS class B take up is low; only a small percentage of small vessels have it. So radar must remain the primary tool.
- Sailing boats in particular can change heading through large angles while their overall course remains constant.
- Determining the actual course of such a vessel is best done by monitoring it's radar track over several minutes (10 was mentioned).
- The slow updating class B overlay on the radar screen can make it difficult to examine the radar track.
- So filtering out class B on the display makes the radar information clearer.

The thread also acknowledges that small GRP boat radar return can be poor, particularly in rain and rough seas where the small vessel's return can be lost in clutter. Transmitting class B AIS would overcome that so long as it isn't filtered out. But it seems to me that an active radar reflector or Tri-lens is a more certain way to ensure I am seen. For me AIS class B TX comes after that and doesn't add much additional safety.

Finally the other forum also has it's twits. In this thread it takes the form; I'm bigger than you, ph** *ff out of my way. I'm happy to say that the majority do not share that attitude.

[Edit] Thread link; there is some other interesting stuff and not all of it supports my argument. http://gcaptain.com/forum/professional-mariner-forum/12345-ais-small-vessles.html
[Edit] The link seems to come up on page 6 of the thread and I don't seem able to change that. Not sure if that's just due to my browsing history but my intention was to link to page 1 and the first post.

 

[JohnGC]

OK, no waiting after the 4 messages have been sent now, so opencpn is quite happily running fine apparently reading 1,000 messages every second ( I can't count that fast )

Seems to be no difference in panning or zooming on a win7 laptop - so might not be the software after all. What you would expect, it's a robust program, something like that you would hope would have been picked up on ages ago.

Even so, still doesn't mean it's the ais system, the software looks like it works on when the report was received by the computer, not the time stamp of the message. Might be your receiver is struggling with so many messages.

I may be missing something here but it looks, from the debug screen, like your just sending 4 messages every 5 seconds. Also I wouldn't be certain that the inter-message delay gets preserved through the coms stack.

What have I missed?

 

[GHA]

I may be missing something here but it looks, from the debug screen, like your just sending 4 messages every 5 seconds. Also I wouldn't be certain that the inter-message delay gets preserved through the coms stack.

What have I missed?

Post 64 Opencpn seems to happily read 1,000 a second. That's as fast as I can transmit without getting into timing interrupts and complicated stuff.

 

[JohnGC]

Post 64 Opencpn seems to happily read 1,000 a second. That's as fast as I can transmit without getting into timing interrupts and complicated stuff.

I'm still missing something.

If you are using serial coms at the standard AIS baud rate (38400) then it takes about 12.5ms to send 48 characters. There is only bandwidth for 80 messages per second. How are you sending 1000?

Your screen capture in post #63 shows 4 messages, in 3 time slots, 5 second apart. 11:41:12, 11:41:17 and 11:41:22.

I took post #64 to mean you had simply removed the 1ms inter-message delay from the 4 messages.

So it looks like you are just sending 4 messages and changing the inter message delay. With no inter message delay, the receiver only needs a 200 character buffer to cope with your 4 messages; not much for a PC.

Did you do something else?

 

[GHA]

Well spotted with the baud rate, it's actually set to 115200, I'll up it some more later to see what happens. . The program is set to send a message every 1mS, going straight back to message 1 after message 4 with no gap.

 

[JohnGC]

Well spotted with the baud rate, it's actually set to 115200, I'll up it some more later to see what happens. . The program is set to send a message every 1mS, going straight back to message 1 after message 4 with no gap.

OK I see.

You aren't really testing OpenCPN at 1 message every 1ms and you are still only tracking 4 vessels.

At 115200 baud you can't send more than 240 message per second because it takes a little over 4ms to send a message. You will simply be filling the TX buffer in your device and then when it is full you will either overwrite messages in the queue or buffer writes will fail until there is space. Do you check the return value or exception generated by the write function?

You have shown that the PC coms layer and OpenCPN can read more messages per second than AIS generates (75). But since that is only a relatively small number of characters (75 * 48 = 3600) for a PC we shouldn't be surprised.

With only 4 messages, OpenCPN doesn't really need to work very hard. There are only 4 vessels details to manage.

To discover how OpenCPN (and other plotters) handle a large number of vessels concurrently you would need to devise a test something like this;
- Generate AIS messages for 300+ vessels. (Moving would be best but I don't think it mater for this if they where not moving.)
- Schedule the transmission of the messages so that the available 75 AIS slots per second are all used.
- Class A high priority vessels transmit every 4s, so each of your 300 messages is sent one time in four (or fewer if you have more than 300 vessels).

Now OpenCPN must maintain a list of 300+ vessels, recalculate the CPA and plots for 75 of these every second. A much more CPU and memory intense task.

 

[Dockhead]

I think some of you are drawing the wrong conclusions from this phenomenon. The AIS system is designed to deal with a fair amount of congestion in the system.

The ICON displayed on the screen will be in the last reported position.

However, the CPA and TCPA calculations will be correct, to the extent that you haven't changed course or speed since the last report. It's these calculations, not the icon display, which are important to collision avoidance. Obviously more frequent reports will increase the accuracy, but the accuracy will be more than enough for effective collision avoidance even in the worst conditions.

And even at its worst, AIS gives far more accurate CPA and TCPA than any other method available on a yacht. So AIS is absolutely the killer app for collision avoidance.

 

[GHA]

The ICON displayed on the screen will be in the last reported position..

Actually, the last *received* position by the software, may or may not be the last message transmitted by the target.

 

[Dockhead]

Actually, the last *received* position by the software, may or may not be the last message transmitted by the target.

Yes, good point.

But still -- the OP, and then a bunch of other posters in this thread, got quite alarmed about the ICON POSITION, when that is actually a relatively trivial function of the system.

My point was that AIS does not need extremely frequent updates to be nevertheless very effective in calculating CPA and TCPA. So all this alarm is not justified. The only loss of fidelity comes from changes of course or speed since the last RECEIVED report.

Even a report every several minutes will give better CPA and TCPA data than other methods available to us, including MARPA. How the accuracy of AIS compares to the accuracy of big ship ARPA is, I don't know, but I'll bet that even poor AIS calculations will still be better than most ARPA calculations.

 

[GHA]

OK I see.

You aren't really testing OpenCPN at 1 message every 1ms and you are still only tracking 4 vessels.

At 115200 baud you can't send more than 240 message per second because it takes a little over 4ms to send a message. You will simply be filling the TX buffer in your device and then when it is full you will either overwrite messages in the queue or buffer writes will fail until there is space. Do you check the return value or exception generated by the write function?

You have shown that the PC coms layer and OpenCPN can read more messages per second than AIS generates (75). But since that is only a relatively small number of characters (75 * 48 = 3600) for a PC we shouldn't be surprised.

With only 4 messages, OpenCPN doesn't really need to work very hard. There are only 4 vessels details to manage.

To discover how OpenCPN (and other plotters) handle a large number of vessels concurrently you would need to devise a test something like this;
- Generate AIS messages for 300+ vessels. (Moving would be best but I don't think it mater for this if they where not moving.)
- Schedule the transmission of the messages so that the available 75 AIS slots per second are all used.
- Class A high priority vessels transmit every 4s, so each of your 300 messages is sent one time in four (or fewer if you have more than 300 vessels).

Now OpenCPN must maintain a list of 300+ vessels, recalculate the CPA and plots for 75 of these every second. A much more CPU and memory intense task.

Looks like the receive rate might be even slower on this machine, the esp8266 with a timer is showing 17mS to generate 6 messages (4 ais, a counter and a time in mS) but the terminal takes a good few seconds to scroll through a block of 1000.
No matter really, it's just a bit of fun, though if someone was to come up with a list of ais messages as you described it would be interesting to see what happens.
Back to the OP, it seems unlikely that the delays are inside opencpn, so...
could it be the receiver? Dunno.
That would be a harder one to test, the RF format of ais messages seems to be shrouded in secrecy.
All good fun though

edit:
Forgot to post this...
https://www.youtube.com/watch?v=w8BjxopbJEs
played around with gps messages a while ago, from memory the screen updates would be quite slow.

Also, not sure I agree with dockhead, where this behavior has been seen by the OP, coming into a bay or port, is where it's really nice to know what other class B fishing boats or whatever are up to. Even though we no doubt will be busy with visual it's nice to have them update frequently on ais as well when courses will often be erratic. And conformation of where this weeks deep water is in unknown entrances

 

[Dockhead]

Also, not sure I agree with dockhead, where this behavior has been seen by the OP, coming into a bay or port, is where it's really nice to know what other class B fishing boats or whatever are up to. Even though we no doubt will be busy with visual it's nice to have them update frequently on ais as well when courses will often be erratic. And conformation of where this weeks deep water is in unknown entrances

I definitely agree -- I didn't say that the icon display is useless. It's definitely useful, and it's definitely nice to be able to see other vessels graphically in something like real time.

But I think that some of the early posters thought that ALL of the information provided by AIS is invalidated by this phenomenon, and several of them even said that they thought AIS itself was not useful as a result. I think that this is a mistake caused by some confusion about how AIS works.


Further comparing AIS to radar, it should be kept in mind that the radar image is only updated at the scan rate of the radar, and only when the radar receives a valid return. It should also be kept in mind that radar, while accurate for range, is not very accurate for bearing, especially small radars like we use on yachts. Even very poor AIS data is going to be better than most radar data, in most cases.

 

[JohnGC]

Yes, good point.

But still -- the OP, and then a bunch of other posters in this thread, got quite alarmed about the ICON POSITION, when that is actually a relatively trivial function of the system.

My point was that AIS does not need extremely frequent updates to be nevertheless very effective in calculating CPA and TCPA. So all this alarm is not justified. The only loss of fidelity comes from changes of course or speed since the last RECEIVED report.

Even a report every several minutes will give better CPA and TCPA data than other methods available to us, including MARPA. How the accuracy of AIS compares to the accuracy of big ship ARPA is, I don't know, but I'll bet that even poor AIS calculations will still be better than most ARPA calculations.

The discussion in the thread with slowly updating class B signals has revolved around commercial shipping being able to detect small boats using their class B transmissions. I don't think anyone is suggesting AIS receivers on small boats is a bad idea.

Icon position can be plotted with very little CPU time. Calculations for CPA are more complex. Unless we wrote, tested or examined the plotter software we do not know how closely linked these 2 functions are. Loss of fidelity can also result from faulty TX equipment on the target vessel. On a recent passage the Dublin to Hollyhead fast cat was not transmitting AIS at all; they did fix it after we told them.

AIS calculations may well be better than MARPA in the sense that they are derived from accurate GPS positions. But MARPA is certainly accurate enough for the job. If I see a CPA of 20m I don't really care if the calculation has a 5m error or a 50m error; my action will be the same. So for a large vessel, I can still see why collision avoidance with a small vessel may be done best with rapidly updating information provided by radar. Rather than slowly updating class B.

"Several minutes" is enough time for a 20kn ferry to travel "several miles" / 3. So long as "several" is quite a small number then I agree.

 

[Dockhead]

. . .
Icon position can be plotted with very little CPU time. Calculations for CPA are more complex. Unless we wrote, tested or examined the plotter software we do not know how closely linked these 2 functions are. . . . .

We do know that CPA and TCPA are based on course, speed, and position with a precise time stamp. So we do know that these calculations will be valid to the extent that course and speed are not changed after the report, and so different from icon position, which is not updated based on assumed continuation of the vessels course and speed.

It's very hard to imagine a scenario where any kind of radar calculation will be more precise than even a poor AIS calculation. Because you have a slow update rate with radar, which will be slower than even quite bad AIS reports, and then you have a much less accurate calculation of position, compared to self-reported GPS position obtained via AIS, principally due to lack of accuracy of the bearing reported by radar.

 

[GHA]

But still -- the OP, and then a bunch of other posters in this thread, got quite alarmed about the ICON POSITION, when that is actually a relatively trivial function of the system.

My point was that AIS does not need extremely frequent updates to be nevertheless very effective in calculating CPA and TCPA. So all this alarm is not justified. The only loss of fidelity comes from changes of course or speed since the last RECEIVED report.

Maybe a bit less than *alarmed* , imho anyway

In the example of the OP, entering a Spanish Ria, the frequently changing COG of targets means any CPA & TCPA calcs will be updated pretty much constantly. I find COG & SOG of targets much more useful is such situations though eyeball is the main stay for sure. Still, when the ais target is half a mile behind the boat you are looking at you'd rather it wasn't

 

[JohnGC]

We do know that CPA and TCPA are based on course, speed, and position with a precise time stamp. So we do know that these calculations will be valid to the extent that course and speed are not changed after the report, and so different from icon position, which is not updated based on assumed continuation of the vessels course and speed.

It's very hard to imagine a scenario where any kind of radar calculation will be more precise than even a poor AIS calculation. Because you have a slow update rate with radar, which will be slower than even quite bad AIS reports, and then you have a much less accurate calculation of position, compared to self-reported GPS position obtained via AIS, principally due to lack of accuracy of the bearing reported by radar.

I accept your point on the calculations although I do have concerns about the update rate.

I have no experience of small boat or commercial radar. If you are correct about the slow radar update time then I agree with you. But that doesn't correlate with what some of the professionals on the other forum where saying happens in practice with class B targets. These are low power and only transmit every 30s at best and can show up after radar has already detected the vessel.

 

[Dockhead]

I accept your point on the calculations although I do have concerns about the update rate.

I have no experience of small boat or commercial radar. If you are correct about the slow radar update time then I agree with you. But that doesn't correlate with what some of the professionals on the other forum where saying happens in practice with class B targets. These are low power and only transmit every 30s at best and can show up after radar has already detected the vessel.

The fact that AIS, even Class "B", is really good, compared to no AIS, does not mean that Class "B" is as good as it should be. For anyone who sails a lot in the shipping lanes (like me), a Class "A" set probably makes a lot of sense. They can now be had for reasonable money.

The problem for Class "A" for short handed pleasure vessels is that you have to program voyage data into them, every time you go out. Solution to that might be switchable "A" and "B" -- "B" for knocking around the coast, and "A" for more serious voyages. Quite a bit of complexity but maybe worth it on a large voyaging yacht.