Share this post

Link to post

Share on other sites

#define TEST would enable extra code. I used that during development for testing the NMEA code without a radio. As long as the project does not define it, the test code will be skipped. It's not enabled in the code, so you don't have to worry about that.

#define DEBUG_MESSAGES is useful to get more information about the radio communication. I would leave that in until you got the receiver working, as it will help you tracking down what's going on.

Share this post

Link to post

Share on other sites

Actually, my msp430G2553 was broken somehow. But, I have some PIC16F877A in my home. I was wondering if I can use PIC16F877A instead of msp430G2553.
What do you think? Is it feasible to use PIC16F877A with si4362 as AIS receiver? I believe converting msp430 code to PIC16F code isnt a big deal.

Share this post

Link to post

Share on other sites

But in my project, you will have to rewrite anything that's hardware dependent. From top of my mind, that's spi.c, serial.c, GPIO interrupts in packet_handler.c, plus any interaction with GPIO like LEDs etc.

You could filter messages to only receive the position messages (types 1, 2, 3, 4, 9 and 18) by evaluating the message type at line 261 and resetting the packet handler state machine in case of an unwanted message.

Keep in mind, that while the received message is converted to NMEA0183, a new AIS message may start arriving. So allocate a few bytes more for the FIFO than the minimal message length (21 bytes for the above, so maybe make the FIFO 32 bytes long). Note that due to its current implementation, the FIFO length must be a power of two.

Setting FIFO_PACKETS to 2 is the minimum, again because a new packet may arrive while the first isn't fully processed yet.

Another big chunk of memory is in the NMEA encoding section. If filtering AIS messages, you can squeeze out a few bytes by limiting the maximum size of the NMEA payload to 21 bytes (nmea.c line 19), which translates to a NMEA output buffer of 43 bytes. You could shave of a few more bytes by not storing the AIVDM lead-in in the buffer but directly outputting it on serial.

Still, squeezing everything into into 96 bytes of RAM will be quite a challenge. The MSP430G2553 has a luxurious 512 bytes.

This bandpass filter covers 6 MHz in the marine VHF band and can be found in many commercial AIS receiver and related equipment. As often with parts from specialist vendors, it is hard to come by without writing an RFQ and/or begging for samples. So I thought I'd sell some of my stash to fellow tinkerers.

Share this post

Link to post

Share on other sites

I have given up about using PIC. Now i move back to MSP430. But, there is some errors again. I didnt receive anything. I actually use my own AIS transponder. I live far away from ocean so I use my own transponder.
I start to think if I can generate a dummy AIS signal through si4362 because I am not so sure where is the problem. Do you think it is possible to generate dummy AIS signal to si4362?

Link to post

Share on other sites

1. Write something on the serial console to make sure that end works (uart_init, uart_send_string)

If that doesn't work, search this forum for tips on setting up serial output from your model of the LaunchPad.

2. Read the Si4362's part information and compare it to what's expected per datasheet (radio_setup, radio_part_info, radio_buffer.part_info.part_msb, radio_buffer.part_info.part_lsb)

If you don't get the expected values (e.g. 0x43 for the msb, 0x62 for the lsb if you're using an Si4362), then something with the SPI connections is wrong.

3. Toggle LEDs in strategic locations in the packet_handler ISR, to see whether raw data and clk bits from radio arrive at the MCU and the interrupt is invoked.

If that doesn't work, check that the correct radio and GPIO pins are connected.

If all the above works, then you're ready to worry about the actual AIS signal. That side is hard to simulate without an AIS target, but your transponder would be a good start. But be careful to not damage the Si4362 with a too strong signal. Directly connecting the transponder with the receiver will destroy the receiver.

Share this post

Link to post

Share on other sites

You can use a terminal program like Putty on Windows to connect to dAISy. Pressing ESC will bring up a debug/configuration menu. There, you can start a test mode by pressing T and then ENTER. dAISy will start outputting an AIS message every 5 seconds.

Alternatively, while in regular receive mode, you can send & to get dAISy to respond with its serial number.

Let me know if this helps.

Best Regards,

Adrian

Share this post

Link to post

Share on other sites

Really enjoy your diy approach to AIS solutions and products. I have a RPI 1 B but have failed to get opencpn or opencpn/openplotter to run so I probably need RPI 2 or 3 to get it going. However I find these tiny Linux PC's so slow booting they're not really practical. However I have worked a lot with Arduino(5v) & Esp8266(3.3v) and was wondering which AIS product of yours would you recommend for me to create a cost effective integrated standalone AIS solution ?

Share this post

Link to post

Share on other sites

All the variations of dAISy are suitable for something built around a Raspberry Pi. The HAT is the obvious fit, but the USB receivers work as well. The USB receivers have the added benefit, that you can also use them on a regular PC or laptop if you decide to move away from the Pi.

Share this post

Link to post

Share on other sites

Thanks Adrian, it appears you lean towards a RPI solution but I was wondering if I could integrate your dAISy Hat board into an Arduino or esp8266 solution via 8/9-bit serial uart at 3.3/5v signal and power supply levels. So far I have developed parsers, mux, Rx/tx wifi for Nmea & seatalk on board instrument data and was wondering if I could also integrate AIS data using your AIS radio decoder ? Once all this data is centralised maybe I could use opencpn on a small touch screen with a Linux or Windows mini PC but that's down the road a bit.