New AIS receiver: dAISy-catcher

[jvde-github]

Hi all,

just want to point out a new AIS receiver we developed together with Wegmatt, the dAISy-catcher. More information on specs and documentation can be found here. The idea was to combine the advantages of an SDR-based AIS receiver (reception quality, flexibility) with the advantages of a hardware solution (plug-and-play solution as either USB serial receiver or Raspberry Pi HAT, low power consumption, accurate signal levels and timestamps, and AIS-tuned filters for robustness).

The new device can be run with AIS-catcher using serial device as input driver.

[astuder]

Hello 👋

I worked with Jasper on this project, mainly working on the hardware while Jasper did his DSP magic.

Based on side-by-side tests, performance is comparable to running AIS-catcher with a good SDR like the Airspy HF+. At the same time, the dAISy-catcher uses about half the power of just the SDR, and that's with doing all the compute heavy work on the receiver instead of the host computer.

My favorite feature of the dAISy-catcher is the precision timestamps, though we're still looking for a good real-world application for that data. Triangulation is an obvious one, but it turned out to be trickier than expected due to the impact of topography and atmospheric conditions. The below plot shows how time-of-arrival (Y-axis) correlates with distance (X-axis), but also the differences between AIS transponders. The dotted line is expected time based on speed of light.

Happy to answer any questions.

You're also welcome to contact me by email (see profile) if you want to pitch an interesting, resource-limited project that needs a better AIS receiver, or have an application for the precision timestamps.

[ymmengin]

Hi Jasper & Adrian,

Great news. I just ordered one yesterday to replace a dAISy HAT and Uputronics LNA running on a RPi5.

Thanks,
Yves

[astuder]

This picture is with the 16mm stand-offs, which leaves a bit of room above the active cooler for the air to circulate. If the circuit board would expand over the ports on the right, it would sit flush on top of the USB ports with maybe 0.1-0.2mm to spare. The plastic body of the 2x40 header provided with the 16mm kit is the same height as the more commonly available double-shrouded stacking headers with long pins.

For comparison, the dAISy HAT sits 11mm above the circuit board of the Pi.

[jimarndt]

This picture is with the 16mm stand-offs, which leaves a bit of room above the active cooler for the air to circulate. If the circuit board would expand over the ports on the right, it would sit flush on top of the USB ports with maybe 0.1-0.2mm to spare. The plastic body of the 2x40 header provided with the 16mm kit is the same height as the more commonly available double-shrouded stacking headers with long pins.

For comparison, the dAISy HAT sits 11mm above the circuit board of the Pi.

I just ordered one yesterday for a Raspberry pi 3. I got the 11mm standoffs, should I have ordered the 16mm? Anyone know of a case for a model 3 that would fit a daisy catcher in a hat configuration?

[astuder]

11mm works fine if you don't have a heat-sink or active cooler on the Raspberry Pi CPU. The dAISy-catcher with 11mm stacking header will fit into most Raspberry Pi cases that accommodate for a HAT. Though you may have to drill a hole for the antenna connector.

I think the Raspberry Pi 4 case you ordered will also work for a Pi 3. The side panel for the Ethernet/USB jacks can be reverted to match the rearranged ports on the Pi 4 vs Pi 3.

[ymmengin]

The tallest part of the dAISy-catcher is the GPS header. With the 16mm header, the dAISy-catcher sits ~10 mm above the USB ports.
I’ll remove the fan and see how low I can get the dAISy-catcher with different header heights. The case I’m trying to use has ~2 mm to spare above the USB ports…

[jimarndt]

Thanks for taking the time to post the detailed pictures—they were very helpful. I'm planning to use a Raspberry Pi 3 since it produces considerably less heat than a Pi 4/5, and the performance should be more than adequate for running dAISy-catcher. This receiver will eventually be installed at a friend's house about 30 minutes away, so reliability is more important than raw performance. I'm running Raspberry Pi OS Lite with Tailscale for secure remote SSH access, which should let me perform software updates and maintenance without making the drive. I'm hoping that will let me keep everything in a compact plastic case without needing active cooling. Do you think a fan is necessary in the HAT configuration, or have you found

[doc-nl]

Just ordered one, should arrive any moment, looking forward to difference with RTL-SDR v4

[doc-nl]

yes, sorry I missed that. working now. If I compare my two stations I have two examples

-11 for RTL-SDR v4 and -85 for dAisycatcher for a ship a couple of km's away
-2,5 for RTL-SDR v4 and -47 for dAisycatcher for a ship about 200m away

[astuder]

I was looking for the plot, to see the lower bounds of signal level to get an idea of the noise floor (technically the signal strength of the weakest AIS messages received, actual noise floor is a few dB lower). With a high noise floor, a more sensitive receiver wouldn't improve results. The lower bound of the signal level plot should be below -100 dBm, ideally below -105 dBm in an RF quiet setup.

(here a change in the setup introduced a lot of noise, which bumped up the weakest signal levels by over 10 dBm)

Though your strong signal reminds me, that I should cut a new firmware version for the dAISy-catcher. There's a bug in v1.0 where very high signal levels (-43 dBm) can be reported as a very low signal level (-114 dBm).

[doc-nl]

Here is the plot of the daisy-catcher

And this of the rtlsdr v4, so that plot is a bit weird, those values can't be correct

[astuder]

Looks like your weakest messages with the dAISy-catcher are around -97 dBm, with the peaks below that every few minutes due to the bug I've mentioned above.

You also have a lot of traffic with very high signal strength. I guess you're located right at a harbor. An alternative explanation is, that a strong local transmitters keeps the 16 dB front-end attenuator permanently enabled, which will impact sensitivity at the low end. Is the red CH2 LED turned on permanently, or only flickering occasionally?

Do you use an external amplifier? If so, try without.

I'd like to send you an external filter to see if that improves things. If you're up for it, send an email to the address in my profile.

I found the signal level chart not very useful for the RTL-SDR. I think in this case the chart just represents the magnitude of the IQ data as received by AIS-catcher, not accounting for any amplification and (automatic) gain control happening in the SDR hardware. With the dAISy-catcher, the magnitude of the IQ data is corrected for the amplification, attenuation and automatic gain control happening in the frontend, representing the signal strength at the antenna port within about +/- 1 dB.

[doc-nl]

I don't see the red CH2 light on, the red CH1 does flash sometimes. I've done some testing with the antenne a bit more outside and that helps a lot in the distance, would have to check that with the RTL side by side to make a fair comparions. I'm in a quite busy environment indeed, station ID 3321/Kogeka

[ymmengin]

Same antenna. Top is dAISy-catcher, bottom is Nooelec NESDR SMArTee v2 SDR + Uputronics 162MHz Filtered Preamp.

[astuder]

Interesting distribution. Looks like most targets are far away, mixed with a few local ones at -60 dBm.

[jimarndt]

Still testing before I move the AIS station to it's permanent location, but saw some impressive Tropospheric Ducting this morning, 450+ miles. The daisy-catcher is exceeding expectations. Rasberry Pi 3 with ais-catcher and daisy-catcher, temporarily connected to my roof top comet GP-3 dual band ham radio antenna. I'm blocked to the west/ocean by hillsides, but do have a path to the ocean down a narrow valley to the south. I'm seeing ships 450 miles away, AIS is only 5 watts! There was a heavy overcast this morning, ideal conditions for tropospheric ducting.

[jimarndt]

Really looking forward to see what coverage you get from that tower.

Do you have a RF spectrum/waterfall from that location? Are there any continuous transmitters on that tower? And if so at what frequencies?

I'm heading up to the tower tomorrow, for a couple hour test run. If you can provide the command line syntax, I can capture a RF spectrum/waterfall.

Before I can install the Pi permanently at the location, I will need to have custom length cables made up, to connect to the hardline from the antenna to the rack location where I will install the Pi.

[astuder]

Sorry for my slow response.

No commands. I was thinking of using an SDR to record the spectrum/waterfall.

[jimarndt]

I was able to capture a 10 minute waterfall. There is about 6 towers on the site, with many microwave, cellular base stations, and radios mainly in the UHF band. Of the about 10 abandoned antennas and Hardline, all failed an antenna analyzer with swr over 10 to 1. The best one (shown in the pic), had a swr of 2.9 to 1 at 162Mhz, I think the hard-line failed or had water ingress after likely decades on the tower. My best testing was a 2m ham magmount stuck on the roof, it captured about 3x more AIS packets then the antenna 100 feet up in the tower. I'll post the waterfall tomorrow night, as I have to ftp it off the Pi.

[jimarndt]

Really looking forward to see what coverage you get from that tower.

Do you have a RF spectrum/waterfall from that location? Are there any continuous transmitters on that tower? And if so at what frequencies?

Here is a RF spectrum/waterfall I collected, I only let it run for 10 minutes. There is about 6 towers at this site within a 200' radius, a lot of microwave and a 300w FM radio transmitter at 103.1. When viewing the image, you must zoom in very close to the yellow line, I capture the entire spectrum.

[astuder]

Ok, that is somewhat unwieldy :)

Looks like besides FM there are also more transmitters across the range. For example around 750MHz. There's also some lower power "smear" above 162 MHz. The SAW filter after the LNA should take care of most of that. The high-pass filter before the LNA should take care of the FM, unless it's coming in super strong (very scientific :) )

Hard to predict what's going to happen. The main concern is that the LNA gets overloaded by a local transmitter.

If you don't have the time to experiment on site with and without filter, I'd opt for adding the external SAW filter.

If you have time for experimentation, I'd watch the following:

• The red LED for CH1 should not light up, especially that far away from AIS targets. The LED indicates that the automatic gain control (AGC) applies attenuation to keep the signal within the ADC's dynamic range.
• The red LED for CH2 should definitely not light up. It indicates that the 24dB of attenuation available to the AGC is not sufficient to tame the input signal.
• Look at the weakest signal level reported by AIS-catcher. When comparing with/without filter, keep in mind that the external SAW reduces signal strength by about 3dBm.
• The Python script I posted about below gives some real-time insights in signal quantity. Interference from nearby transmitters likely will show up as elevated noise floor and/or spurs. Adding the filter should clean that up.

[doc-nl]

A friend of mine printed a nice case! But what screws should be used? I couldn't find it in the manual :)

[g7ruh]

@doc-nl Any chance of sharing the .stl file for the case, then I can print one for my shiny new dAISy-catcher?

[astuder]

STL and CAD files for the official case are available here, though not with that fancy logo:
https://wegmatt.com/files/daisy-catcher-case.zip

[g7ruh]

Thanks, I really think the fancy logo is great maybe @doc-nl will provide the goods. I am looking forward to double the range, that is why I would like it lol.

[doc-nl]

I'll ask the guy who made the print for me :)

[Phil353556]

Hello,

• May I kindly suggest, if the guy agrees of course, to share on this platform: https://www.thingiverse.com
• examples of what it can be found on this platform: https://www.thingiverse.com/search?q=raspberry+pi+4+with+hat&page=1

Thanks / regards / Phil

[astuder]

Here's something to play with for the nerds: The dAISy-catcher has a debug mode that outputs power levels and frequency spectrum. Resolution is quite coarse as USB bandwidth is limited, but it can give some insight into the noise floor as well as the general RF environment as seen by the decoder.

I posted a Python script that visualizes the data here: https://wegmatt.com/files/stats.py
It requires the Python libraries mathplotlib, numpy and pyais. I think everything else should be standard with Python 3.

Run the script with python stats.py your_serial_port

Two examples of what to expect:

Kirkland, WA


Cape Perpetua, OR

[ketilmo]

Hi!

Congratulations on an exciting new product! I received it in the mail earlier this week and am setting it up now. Excited to see how it will perform!

I ordered it with the GPS option and am mounting the device as a Pi HAT on an RPI 5 with the following init sequence, as per the instructions from here:

AIS-catcher -e 115200 /dev/ttyAMA0 -ge init_seq co2,v

This appears to work, and I see traffic. I was just wondering if I need to modify the init sequence to use the GPS, or if that is enabled automatically. Reading the PDF doc, I think this might be the way to do it:

AIS-catcher -e 115200 /dev/ttyAMA0 -ge init_seq co2,v,cg1

Is this correct?

Kind regards,
Ketil

[astuder]

Yes, the toa field in the output of the dAISy-catcher indicates that GNSS is working.

Note that rxuxtime in the AIS-catcher output is the system time the message got processed on the Pi, while toa is the timestamp as reported by the receiver. I don't think AIS-catcher is currently doing anything with toa. I wrote this Pythons script to play with logs that include toa timestamps:
https://wegmatt.com/files/timestamp.py

For translating time to (relative) distance, the trick is to convert the timestamp into time since the start of the current AIS time slot. This is done with this line:

# Slot timing from timestamp, reference at expected ToA (T2 = 3.333ms)
slot_time_us = int((((toa % 60) * (9600.0/256.0)) % 1.0) * (256.0/9600.0) * 1000000 - 3333.33 + 0.5)

T2 refers to the position in the message where the dAISy-catcher takes the timestamp (end of preamble, start of sync word)

[ketilmo]

Awesome! A big thanks to both of you!

Ketil

[astuder]

As I always have to puzzle together how I came to this convoluted formula, here's what it does:
toa % 60: timestamp relative to start of the minute (AIS restarts counting slots at the top of each minute)
* 9600/256: express time in number of slots, a slot is 256 bits, transmitted at 9600 baud
% 1.0: only take the fraction of the slot (e.g. if slot time is 2.5, use 0.5)
* 256/9600: convert slot number back to time
* 1000000: convert from seconds to microseconds
- 3333.33: adjust from where in the slot toa is measured to the start of the slot
+ 0.5: some ham-fisted rounding, should probably use the proper math function, but it's just half a microsecond

[ketilmo]

Fascinating, good to know. Thank you again!

[ketilmo]

Updating to the latest build worked like a charm. Thanks again!

[jvde-github]

yes, I suspect so. You can also run with share_loc on:

AIS-catcher -e 115200 /dev/ttyAMA0 -ge init_seq co2,v  -o 5 -v 30 -M DMT -N 8081 REALTIME on SHARE_LOC on

this allows AIS-catcher to share the location with the in-build web viewer. You should now see your location on the map at 8081 and also distance metrics are calculated.

Hope that helps!

[ymmengin]

Since swapping out a SDR + Uputronics LNA/Filter for a dAISy-catcher, the station range and vessel count has increased dramatically! AIS-catcher was set up again using the managed mode this time.

[g7ruh]

@astuder You were right.... the nerd in me just had to try stats.py while testing a new dAISy-catcher. My noise floor is lower and more stable than expected (at least with a short test to test stats.py)

Very useful little tool. Now back to setting things up. After testing, I too will likely be replacing a RTL-SDR V3 and Uputronics LNA / filter. initial impression is maybe 7-10% more messages and 5-15 more vessels. Weather is sunny and a little windy (near Southampton UK). I have spent a long time setting up the RTL-SDR V3 and think I squeezed as much performance from it as I could. Discussion #75 refers.

[g7ruh]

@astuder I modified the top part of the case by adding a clear panel for LED viewing and a small hole for the reset button. Printed on a multi-material printer.

And to show it is not just green filament :) here it is with LED off:

[Phil353556]

hello,
just received the hw, connected on pi4, using GPIO (so not USB) , follow official documentation and here too https://jvde-github.github.io/AIS-catcher-docs/configuration/input/daisy-catcher/
screen /dev/serial0 115200
works perfectly I can see NMEA data

when configured on AISCatcher UI

There is an error message displayed: "Failed to open serial port /dev/serial0 at baudrate 115200"

and of course there is no screen session to be resumed
Does the owner or rights on /dev/serial0 which is link to /dev/ttyS0 should be modified ?

Thanks for your help

[g7ruh]

@Phil353556
Hi Phil,

When I did my install, I used the instructions in the manufacturer's pdf https://wegmatt.com/docs.html and download the dAISy-catcher instruction manual. In Section 3.3 Linux and Pi it refers to "screen" as a way to test the basic functions. That way I knew the hardware was working OK. I used GPIO connectivity to test it.

I then moved on to section 4 to further test it.

That way I could be satisfied that serial port stuff was working. My photo of the case was from when I was testing the Pi on the USB port.

Hope that help you test some more.

Roger

[Phil353556]

Hello @g7ruh,
Many thanks for your answer.
Yes, I follow the documentation as written the wegmatt and aiscatcher (jvde doc)

I found the issue, my bad :-)
As I shared, this is a docker configuration ... so the contents of the file docker-compose.yaml must be modified, of course, as this is no more an usb device but a serial one. The daisy aiscatcher is connected via GPIO
/dev/serial0 is a link to /dev/ttyS0 , so the line was modified as follow:
devices:
- /dev/ttyS0:/dev/ttyS0

docker stop aiscatcher
docker compose up -d
and it is ok, see below.

Starting receivers
Serial: init command sent "co2"
Serial: init command sent "v"
Device    : Serial Port
Settings  : rate 288K format TXT baudrate 115200 flowcontrol none port /dev/ttyS0 dump OFF
Model #0-0 -> (Src: 1, Grp: 1): [NMEA input] channel AB nmea_refresh OFF crc_check OFF VDO ON
TCP (178.162.215.175:32199): connected.
TCP (127.0.0.1:30005): connected.
Control: engine started
Device    : RTLTCP
Settings  : protocol BEAST lossless OFF rate 288K format BEAST
  TCP: host 127.0.0.1 port 30005 timeout 0 persist ON keep_alive ON

Model #1-0 -> (Src: 2, Grp: 2): [ADSB input] channel AB 
Entering main loop
[SERIALPORT]: dAISy-catcher Firmware v1.0.0+f88208d PROD (HAT v1.0)
[NMEA input #0-0]                       received: 7 msgs, total: 7 msgs, rate: 1.73829 msg/s
[NMEA input #0-0]                       received: 11 msgs, total: 18 msgs, rate: 3.66012 msg/s

will see the performance tomorrow
Regards
Phil

[Phil353556]

@astuder
May be a tiny typo in the documentation

I chedked on pi3, pi4 and pi5, all using OS Trixie (13), this is I6 and not I5
I6 Serial Port Enable/disable shell messages on the serial connection

Best regards
Phil

[astuder]

Thanks!

[Phil353556]

to be complete typo on both document:
https://wegmatt.com/files/dAISy%20HAT%20AIS%20Receiver%20Quickstart.pdf
and
https://wegmatt.com/files/dAISy-catcher%20AIS%20Receiver%20Manual.pdf

[T-F-0319]

@astuder
Hello Adrian,

I recently came across this product and placed an order. It arrived very quickly. Thank you for the prompt shipping!

I immediately installed the dAISy-catcher on my Raspberry Pi 5 and took it out to the coast for a test.
Since I was using a simple antenna, the reception range was not particularly impressive. However, I found the TOA timestamps very interesting, as they showed a clear correlation with the speed of light. I've also attached two graphs similar to the ones you shared in an earlier discussion.

There were some deviations from the theoretical values, but the accuracy was sufficient to identify the Slot No. of each AIS sentence. This means I should now be able to achieve my goal of creating a "slot map."
In the future, I would also like to try using multiple dAISy-catcher units to estimate vessel positions based on differences in radio signal arrival times.

Thank you very much for developing the dAISy-catcher!

By the way, I have a question about the specifications of this product. I would appreciate it if you could clarify the following.

With my previous receiver, even malformed AIS sentences were passed through as received. For example:

• Sentences with payloads that did not have the required number of bits
• Sentences with Message IDs outside the range of 1–27
• Sentences with empty payloads

How does the dAISy-catcher handle these malformed sentences? Are they also output as NMEA messages without any filtering?

[astuder]

Thank you :)

We think that most invalid messages are due to multiple bit-flips that accidentally line up so that the CRC is still valid. Though we also saw broken transmitters that consistently send invalid messages. dAISy-catcher does discard messages that don't pass a few basic sanity checks like invalid message types, zero-length messages, and invalid message length for message types with fixed length. These checks can be disabled with the command cv0 (default is enabled, cv1).

The checks are very basic and mostly targeting violations of the AIS protocol. They won't catch transmitters that send garbage data in well-formed messages.

We're still experimenting with using timing data to calculate location by TDOA. One challenge is, that TOA reported by dAISy-catcher can be off by up to -15us (estimate is up to 15us early) for signals distorted by multi-path propagation. This mostly applies to targets with no direct line of sight to the receiver.

Targets where this is a problem can be spotted by a consistent gap in timing and signal power between channels A and B. In these cases, the timing of the channel with higher signal power typically seems to be closer to the real TOA.

[T-F-0319]

Thank you for your reply. I wasn't aware that there was a command to enable the validation of AIS messages. I'll try disabling it next time.

It seems that multipath propagation is indeed a significant challenge for TDOA.
Thank you for pointing out that comparing the signal strengths of channels A and B might help address this issue. I don't fully understand why this is the case yet, but I'd like to investigate it myself as well.

Best regards,
Taketo