Return of the YAPP

AngusMcDoon

Well-Known Member
Joined
20 Oct 2004
Messages
9,045
Location
Up some Hebridean loch
Visit site
It's time for a new YAPP. There's not been one for a while. This one, which through lack of imagination to think of anything better, is called a boat data hub, because it’s basically a bi-directional Seatalk/NMEA-0183 converter combined with a NMEA-0183 multiplexer with a couple of other YAPPs thrown in. It is considerably bigger than all previous projects as it incorporates the functionality of at least 5 of them. This is what it looks like...

IMG_20200107_203446598.jpgIMG_20191218_220914984.jpg

First, an explanation of my current system and what the problem is. I have an old ST60 based system of instruments (depth, log, GPS mushroom, wind) and a ST2000+ autopilot (source of compass data) linked via Seatalk 1 to an RC530 chartplotter. This all works, but the GPS mushroom probably doesn't have long for this world, and the RC530 is big, heavy, slow, power hungry, uses expensive CMAP charts, cannot display AIS information, and its model of the earth’s magnetic field is seriously out of date. Also attached to my Seatalk bus, when needed, are two YAPPs - a wired autopilot remote…

YAPP Seatalk autopilot wired remote

and an anchor watcher…

YAPP New Anchor Watcher - with user interface

These have worked well, until last summer, when the autopilot remote handset got a seawater dunking coming down the Minch and promptly died, not being in a waterproof case, and having decidedly non-waterproof switches.

Standing alone I have a VHF which receives NMEA-0183 RMC position information from a Globalsat BR-355 GPS mouse and outputs NMEA0-183 VDM AIS messages from an integrated AIS receiver. As my chartplotter cannot display AIS I have to fire up a laptop with OpenCPN when I want to see what the CalMac ferries are doing. All of the above is shown on this diagram...

old_system.jpg

What I want to move to is a single integrated system that ditches my RC530 plotter and instead runs OpenCPN on a tablet. This will allow use of much cheaper charts, use less power, take less space and be able to show AIS. I want to be able to input routes in OpenCPN and send them to the autopilot via Seatalk 1. I also want to be able to display instrument data from my ST60/autopilot sources on OpenCPN dashboards.

I want the link to the tablet to be wireless, to use my now spare BR-355 GPS mouse as an alternative GPS source for the whole system, incorporate the anchor watcher functionality, add a wireless autopilot remote control receiver, use the latest 2020 World Magnetic Model for magnetic declination, and as OpenCPN can record pressure trends I might as well throw in a pressure transducer while I'm at it. The GPS mouse 5 V power will also be supplied by the new device, and will be switchable to save power when it’s not being used. This diagram shows all of the above...

new_system.jpg

Previous simpler YAPPs have used PIC 18F microprocessors, and some of those were pushing their limits. This project is way above what an 18F PIC can achieve, so I've moved to an ARM Cortex M3. This is a good compromise between price, capability and power consumption. These devices only come in surface mount package but there are plenty of dev boards available for a few pounds. One of the cheapest is the Blue Pill, so that's what I used being as parsimonious as I am, as it can be obtained for less than £2. It has 64 kBytes of flash memory and 20 kBytes of RAM…

Blue Pill

For the wireless communications the choice is limited to what tablets typically have built in, and that's Bluetooth or WiFi. Bluetooth is simpler, cheaper and less power hungry. Typically the range is 10 m but that can be extended if necessary using a different Bluetooth class device.

There's quite a bit going on in this YAPP - the comms connections are: to/from Seatalk 1 bus, NMEA-0183 to/from tablet via Bluetooth, NMEA-0183 GPS from mouse, NMEA-0183 AIS from VHF, NMEA-0183 GPS to VHF. In addition there's an I2C interface to the pressure sensor and a SPI interface to the 2.4 GHz RF module to talk to the autopilot remote handset. To be able to use the anchor watcher functionality and configure settings the following are needed: text LCD with backlight, 2 user buttons and a beeper for alarms. There’s also the magnetic model to run.

In order to control all that lot a real time operating system has been used. The obvious choice as it's widely used, includes an ARM Cortex M3 processor port, and is free, is FreeRTOS. As multiple parts of the application (and multiple threads) need to access some of the same hardware resources concurrently this needs to be managed to avoid contention. Some processing can be performed slowly or when there is spare processor time, for example reading the pressure or calculating the magnetic declination, which are low priority activities. The firmware design used is to wrap each non-interrupt driven hardware resource in a thread listening for requests from a queue in a client/server model. The hardware resources that will be managed like this each with their own server thread and requests queue are the pressure sensor driver, the LCD driver and the 2.4 GHz RF module listening for messages from the autopilot remote handset.

Other hardware features will be interrupt driven. These are the Seatalk 1 interface which is implemented as a soft UART (taken from earlier PIC YAPPs), the 2 user buttons which are too simple to need a server thread, and 3 bi-directional hardware UARTS are used for the NMEA-0183/Bluetooth communications - 2 running at 38.4 kbaud and 1 at 4.8 kbaud. To get the throughput required without taking too much processor time these UARTS and the Seatalk soft UART will be buffered for both reading and writing.

The main processing loop continually handles Seatalk queued incoming and outgoing messages which are ready for processing. Other periodic processing is performed using FreeRTOS timers. These run at 3 rates - every 25 ms, every 1 ms and every 10 s. The timer task functions get and send messages to the hardware server tasks via their requests queues or read from and write to the communications channels’ buffers. A simplified diagram of the firmware design is shown below...

sw_design.jpg

The heart of this project is a bi-directional Seatalk 1 to NMEA-0183 converter of which there are many other incarnations available, both open source and closed source commercial variants (including my previous efforts). However, this one has its NMEA-0183 message support tailored specifically to the messages read and written by OpenCPN. This device might work with other chart plotters, but it’s only guaranteed to work fully with OpenCPN. Of all the multitude of NMEA-0183 message types and variants – if OpenCPN doesn’t support it then this device doesn’t support it.

A note on why the World Magnetic Model was included. OpenCPN has the capability to run this model to get magnetic declination for position and time, but it’s poor at sharing it. It will send out declination in RMC messages but only when a route is active. When no route is active the field is blank in the message output. I added a feature request to OpenCPN to output it at all times in RMC messages but it got classified as of no importance and unlikely to be included in my lifetime. As I want magnetic declination to go on to my Seatalk bus for the autopilot to use I included the model source and coefficients in my code. It’s more up-to-date than the OpenCPN WMM plug-in as well, as I’m using the latest 2020 co-efficients.

The hardware design is basically a main board with a power supply and some communications interfaces (Seatalk 1, NMEA0-183, RS232) with most other features implemented by bought in daughter boards. A BMP280 pressure sensor is used. This is a bit of a fiddle to use from a software perspective requiring many factory programmed calibration values to be read and applied, but once done it is remarkably sensitive and has great absolute accuracy. It’s a tiny surface mount device so the best way to get to it is to use a breakout board available for less than two pounds from Ebay.

The 2.4 GHz RF module is a cheapo Ebay one readily available using a Nordic Semiconductor NRF24L01 chip...

RF Module

The Bluetooth module is an HC-05 board. This provides a simple serial interface and appears as virtual COM ports in Windows or serial devices in Linux when paired which OpenCPN can easily connect to...

Bluetooth module

Every pin bar one is used on the Blue Pill board. This diagram shows the modules that are used…

hw_modules.jpg

This is the PCB layout - old fashioned through hole double sided board...

pcb.jpg

This is the assembled PCB with labelled parts, a bit cluttered but gives you the idea...

IMG_20200107_203225841.jpg

The Seatalk and AIS via NMEA-0183 inputs are opto-isolated. The connection to the GPS mouse is not as it's this device that is powering it - it has no external connections.

To be continued as post size limit reached...
 
Last edited:
Part 2

Mechanicals is always a problem for home projects. Custom circuit boards are cheap, custom plastic is not. I've gone down the previous route of using an off the shelf enclosure with 3D printed panels for some small parts. Previously I was using SLS printed parts but that's now considerably more expensive. FDM is cheaper to get done and is adequate. This is the enclosure which has a front and back removable panel which I have had 3D printed…

Box

These are the 3D parts modelled in Sketchup…

boat_data_hub_front_panel.jpgboat_data_hub_rear_panel.jpg

The wireless autopilot remote handset has changed from the previous YAPP by adding a 2.4 GHz wireless board, changing the power supply to a coin cell and mounting in an IP67 box with IP68 buttons, but it still uses a PIC 18F as that's what I have the code for already. The processor spends most of its time asleep but is woken by a button press, sends data, and then goes back to sleep. Expected lifetime on a CR2050 coin cell is 3 years. Here it is…

IMG_20200105_150633192.jpg

The main difficulty of this project was getting all the code to fit in to the 64 kbytes of flash space on the Blue Pill board’s processor. Settings are also stored in the same flash as the code and the flash sector size (the minimum that can be erased) is 1 kbyte, so that left 63 kbytes. To get the code in took considerable effort in space optimization. Getting the compiler to optimize for space wasn’t enough – a lot more manual work had to be done. The World Magnetic Model’s coefficient file for example is space inefficient as it comes from NOAA, so that was manually shrunk by changing its format. The use of volatile variables, while necessary, is carefully controlled to the absolute minimum as that’s a feature that can rapidly expand compiled code size. There is now only about 1400 bytes of flash space free – not much for bug fixing if required or new features. The board has the mounting holes and connections for fitting an external 8 kbyte EEPROM chip which could be used for settings and the coefficients file freeing up 2.5 kbytes of flash. Because of code space limitations the old ST Standard Peripheral Library has been used rather than the new bloated ST HAL. The old library does everything needed.

There's a variety of open source code/design in this project that should be acknowledged. These are...

World Magnetic Model (World Magnetic Model | NCEI)
FreeRTOS (FreeRTOS - Market leading RTOS (Real Time Operating System) for embedded systems with Internet of Things extensions)
printf.c by Marco Paland (mpaland/printf)
nrf24l01.c RF module driver by Brennen Ball
Seatalk reverse engineering by Thomas Knauf (Thomas Knauf SeaTalk Technical Reference)

Development environment

Atollic TrueStudio
This compiles the main Blue Pill code. This is deprecated now being replaced by the STM32Cube IDE but this runs slowly on my weedy old computer, so I’m still using the old version. The project files can be imported into STM32Cube IDE, converted, built and debugged without problem however (apart from the UI being slow).

Sketchup
I use Sketchup Make 2017, the last free version available for download. Since then Sketchup has gone online with Sketchup Free. You can upload my .skp files to Sketchup Free but you have to create an account first. You can still download Sketchup Make 2017, but it’s a bit hidden on their website.

MPLAB-X/C18
The autopilot remote handset uses a PIC processor. This is a rehashed project from years ago and the PIC18 development tools I used have been deprecated, both the MPLAB IDE and the C18 compiler. I’ve converted the project to use the latest IDE (MPLAB-X) but could not get the code to run using the latest compiler (XC8). Therefore it still uses the old compiler (C18, version 3.47) which for now is still available on Microchip’s website.

Programmers

The Blue Pill has no on-board ST-Link, unlike the ST development boards. However, ST-Link/V2 programmers are available on Ebay for under £3. The autopilot remote handset needs a PIC programmer. I have an old PICKit 2, available on Ebay for under £4. The PICKit 2 software is still available on Microchip’s website, although it needs an updated data file to program the PIC18F26K22 processor.

The cost of the whole project, both the hub and the handset, comes in at just under £85 for parts, buying in small numbers. Surprisingly, the enclosures and connectors are nearly £35 (the IP67 handset enclosure wasn't cheap). It's all open source released under a MIT license - basically do whatever you want with it but don't claim it's your property or you developed it. If anyone wants any of the files let me know. I'll stick it on a website some time. I'm not going to be assembling these for people as it takes too long but I have spare PCBs and 3D printed panels if anyone wants some. I could possibly put together kits as I have identified a source for all the parts. It's been tested on both my simulated Seatalk network at home and on board, apart from sending real routes and waypoints from OpenCPN to the autopilot. For that to be tested properly I need to be at sea and try out some routes, but that won't happen until the Spring.
 
Last edited:
John

Great for you to be back and keep up the good work.

The bits you supplied to me some time ago are still working great.

I started using the PIC but moved on to the arduino nano as made up boards are easy available.
 
Fantastic!! :cool:

Quick question, AFAIK seatalk needs 9 bit serial - does the STM32F do both 9bit seatalk and 8bit NMEA/RS232?

And nice write up, must have taken a while, THANKS!!

looks like JLCPCB do PICs and STM32f as basic surface mount components now, which means pennies on top of the chip cost to get them already soldered on, Which you probably knew anyway :)
PCB Prototype & PCB Fabrication Manufacturer - JLCPCB
 
Fantastic!! :cool:

Quick question, AFAIK seatalk needs 9 bit serial - does the STM32F do both 9bit seatalk and 8bit NMEA/RS232?

And nice write up, must have taken a while, THANKS!!

looks like JLCPCB do PICs and STM32f as basic surface mount components now, which means pennies on top of the chip cost to get them already soldered on, Which you probably knew anyway :)
PCB Prototype & PCB Fabrication Manufacturer - JLCPCB

I use a soft UART for Seatalk. It's only 4.8 kbaud so plenty of time to do it.
 
Ciao Angus, I found your project only now and it seems interesting to me. If the google translation is correct, I understand that you can possibly have a kit with all the components. The files for programming (I'm not a technician) can also be obtained ... therefore as an old stubborn one and a lot of time available, I'd like to try the assembly. Can you get me a quote for everything? even in private if you want. I await your news and ... good wind!
 
Hi John,

I am really impressed by all the projects you put up on the forum. I would like to ask you about the first YAPP on seatalk to NMEA through USB, I really hope you dun mind if I track your masterpiece to its origin but I am working on some backup solutions that I would like to keep very simple so be built (or easily fixed) when on long routes.
Long to short: can you help me to get the scheme and documentation (if any update from what is still here online) of your first YAPP, the on of 2011 (homemade seatalk to usb)?
Hope you do not mind if I posted here but I thought that YAPP maybe still of fundamental interest for who like many here has to face the issue of seatalk-Nmea-PC connection.
Thanks a lot,
Michael
 
It's time for a new YAPP. There's not been one for a while. This one, which through lack of imagination to think of anything better, is called a boat data hub, because it’s basically a bi-directional Seatalk/NMEA-0183 converter combined with a NMEA-0183 multiplexer with a couple of other YAPPs thrown in. It is considerably bigger than all previous projects as it incorporates the functionality of at least 5 of them. This is what it looks like...

View attachment 83343View attachment 83344

First, an explanation of my current system and what the problem is. I have an old ST60 based system of instruments (depth, log, GPS mushroom, wind) and a ST2000+ autopilot (source of compass data) linked via Seatalk 1 to an RC530 chartplotter. This all works, but the GPS mushroom probably doesn't have long for this world, and the RC530 is big, heavy, slow, power hungry, uses expensive CMAP charts, cannot display AIS information, and its model of the earth’s magnetic field is seriously out of date. Also attached to my Seatalk bus, when needed, are two YAPPs - a wired autopilot remote…

YAPP Seatalk autopilot wired remote

and an anchor watcher…

YAPP New Anchor Watcher - with user interface

These have worked well, until last summer, when the autopilot remote handset got a seawater dunking coming down the Minch and promptly died, not being in a waterproof case, and having decidedly non-waterproof switches.

Standing alone I have a VHF which receives NMEA-0183 RMC position information from a Globalsat BR-355 GPS mouse and outputs NMEA0-183 VDM AIS messages from an integrated AIS receiver. As my chartplotter cannot display AIS I have to fire up a laptop with OpenCPN when I want to see what the CalMac ferries are doing. All of the above is shown on this diagram...

View attachment 83336

What I want to move to is a single integrated system that ditches my RC530 plotter and instead runs OpenCPN on a tablet. This will allow use of much cheaper charts, use less power, take less space and be able to show AIS. I want to be able to input routes in OpenCPN and send them to the autopilot via Seatalk 1. I also want to be able to display instrument data from my ST60/autopilot sources on OpenCPN dashboards.

I want the link to the tablet to be wireless, to use my now spare BR-355 GPS mouse as an alternative GPS source for the whole system, incorporate the anchor watcher functionality, add a wireless autopilot remote control receiver, use the latest 2020 World Magnetic Model for magnetic declination, and as OpenCPN can record pressure trends I might as well throw in a pressure transducer while I'm at it. The GPS mouse 5 V power will also be supplied by the new device, and will be switchable to save power when it’s not being used. This diagram shows all of the above...

View attachment 83337

Previous simpler YAPPs have used PIC 18F microprocessors, and some of those were pushing their limits. This project is way above what an 18F PIC can achieve, so I've moved to an ARM Cortex M3. This is a good compromise between price, capability and power consumption. These devices only come in surface mount package but there are plenty of dev boards available for a few pounds. One of the cheapest is the Blue Pill, so that's what I used being as parsimonious as I am, as it can be obtained for less than £2. It has 64 kBytes of flash memory and 20 kBytes of RAM…

Blue Pill

For the wireless communications the choice is limited to what tablets typically have built in, and that's Bluetooth or WiFi. Bluetooth is simpler, cheaper and less power hungry. Typically the range is 10 m but that can be extended if necessary using a different Bluetooth class device.

There's quite a bit going on in this YAPP - the comms connections are: to/from Seatalk 1 bus, NMEA-0183 to/from tablet via Bluetooth, NMEA-0183 GPS from mouse, NMEA-0183 AIS from VHF, NMEA-0183 GPS to VHF. In addition there's an I2C interface to the pressure sensor and a SPI interface to the 2.4 GHz RF module to talk to the autopilot remote handset. To be able to use the anchor watcher functionality and configure settings the following are needed: text LCD with backlight, 2 user buttons and a beeper for alarms. There’s also the magnetic model to run.

In order to control all that lot a real time operating system has been used. The obvious choice as it's widely used, includes an ARM Cortex M3 processor port, and is free, is FreeRTOS. As multiple parts of the application (and multiple threads) need to access some of the same hardware resources concurrently this needs to be managed to avoid contention. Some processing can be performed slowly or when there is spare processor time, for example reading the pressure or calculating the magnetic declination, which are low priority activities. The firmware design used is to wrap each non-interrupt driven hardware resource in a thread listening for requests from a queue in a client/server model. The hardware resources that will be managed like this each with their own server thread and requests queue are the pressure sensor driver, the LCD driver and the 2.4 GHz RF module listening for messages from the autopilot remote handset.

Other hardware features will be interrupt driven. These are the Seatalk 1 interface which is implemented as a soft UART (taken from earlier PIC YAPPs), the 2 user buttons which are too simple to need a server thread, and 3 bi-directional hardware UARTS are used for the NMEA-0183/Bluetooth communications - 2 running at 38.4 kbaud and 1 at 4.8 kbaud. To get the throughput required without taking too much processor time these UARTS and the Seatalk soft UART will be buffered for both reading and writing.

The main processing loop continually handles Seatalk queued incoming and outgoing messages which are ready for processing. Other periodic processing is performed using FreeRTOS timers. These run at 3 rates - every 25 ms, every 1 ms and every 10 s. The timer task functions get and send messages to the hardware server tasks via their requests queues or read from and write to the communications channels’ buffers. A simplified diagram of the firmware design is shown below...

View attachment 83338

The heart of this project is a bi-directional Seatalk 1 to NMEA-0183 converter of which there are many other incarnations available, both open source and closed source commercial variants (including my previous efforts). However, this one has its NMEA-0183 message support tailored specifically to the messages read and written by OpenCPN. This device might work with other chart plotters, but it’s only guaranteed to work fully with OpenCPN. Of all the multitude of NMEA-0183 message types and variants – if OpenCPN doesn’t support it then this device doesn’t support it.

A note on why the World Magnetic Model was included. OpenCPN has the capability to run this model to get magnetic declination for position and time, but it’s poor at sharing it. It will send out declination in RMC messages but only when a route is active. When no route is active the field is blank in the message output. I added a feature request to OpenCPN to output it at all times in RMC messages but it got classified as of no importance and unlikely to be included in my lifetime. As I want magnetic declination to go on to my Seatalk bus for the autopilot to use I included the model source and coefficients in my code. It’s more up-to-date than the OpenCPN WMM plug-in as well, as I’m using the latest 2020 co-efficients.

The hardware design is basically a main board with a power supply and some communications interfaces (Seatalk 1, NMEA0-183, RS232) with most other features implemented by bought in daughter boards. A BMP280 pressure sensor is used. This is a bit of a fiddle to use from a software perspective requiring many factory programmed calibration values to be read and applied, but once done it is remarkably sensitive and has great absolute accuracy. It’s a tiny surface mount device so the best way to get to it is to use a breakout board available for less than two pounds from Ebay.

The 2.4 GHz RF module is a cheapo Ebay one readily available using a Nordic Semiconductor NRF24L01 chip...

RF Module

The Bluetooth module is an HC-05 board. This provides a simple serial interface and appears as virtual COM ports in Windows or serial devices in Linux when paired which OpenCPN can easily connect to...

Bluetooth module

Every pin bar one is used on the Blue Pill board. This diagram shows the modules that are used…

View attachment 83339

This is the PCB layout - old fashioned through hole double sided board...

View attachment 83354

This is the assembled PCB with labelled parts, a bit cluttered but gives you the idea...

View attachment 83350

The Seatalk and AIS via NMEA-0183 inputs are opto-isolated. The connection to the GPS mouse is not as it's this device that is powering it - it has no external connections.

To be continued as post size limit reached...

Hello, is this your personal project or also available for others to buy / try?

Wouldn’t it be easier to calculate magnetic variance in the plotter software and include it in the RMB/APB sentence instead of doing it in the yapp?
 
Hello, is this your personal project or also available for others to buy / try?

Wouldn’t it be easier to calculate magnetic variance in the plotter software and include it in the RMB/APB sentence instead of doing it in the yapp?

It's my personal project but it's open source. You can grab all the files and try anything you like yourself. There's nothing to buy, I'm not making anything.

miniwinwm/BoatDataHub

This project is designed to interact with OpenCPN. OpenCPN does calculate magnetic variation but the problem is that it doesn't send it out in the RMC message unless a route is active, so my device is not receiving it. OpenCPN is not my software so I can't change it easily (although it is open source as well). I requested that it was modified in the next release to send magnetic variation in RMC messages at all times but it got classified as unimportant and time frame to fix set as 'probably never'.
 
Last edited:
Bit of drift here. Great project. I am a staunch supporter of people making stuff.

I came to YAPPs late. I understand Yet Another Pointless Project but how did the name come about?

I like to think it came from some nitwit moaning about making things: that you could "easily" buy for a thousand pounds.

Is that correct?
 
Hi John,

I am really impressed by all the projects you put up on the forum. I would like to ask you about the first YAPP on seatalk to NMEA through USB, I really hope you dun mind if I track your masterpiece to its origin but I am working on some backup solutions that I would like to keep very simple so be built (or easily fixed) when on long routes.
Long to short: can you help me to get the scheme and documentation (if any update from what is still here online) of your first YAPP, the on of 2011 (homemade seatalk to usb)?
Hope you do not mind if I posted here but I thought that YAPP maybe still of fundamental interest for who like many here has to face the issue of seatalk-Nmea-PC connection.
Thanks a lot,
Michael

They are all here...

miniwinwm/YAPP
 
Bit of drift here. Great project. I am a staunch supporter of people making stuff.

I came to YAPPs late. I understand Yet Another Pointless Project but how did the name come about?

I like to think it came from some nitwit moaning about making things: that you could "easily" buy for a thousand pounds.

Is that correct?

It's a modification of this after someone called one of my first projects pointless many years ago...

Yacc - Wikipedia

I think it was the outboard engine rev counter I created that was helpfully pointed out by a poster that it was possible to buy one and I need not have bothered making one.

Someone then created a good backronym - Yacht APP.
 
As an alternative, which covers some of this and your other current project (NMEA data to website), did you think about compiling @laika's kplex on a router and using that as an interface to OCPN ? I did that with Tomato on an ASUS R16 about 7 or 8 years ago but not using that OS or router anymore. Currently using ROOter, an offshoot of OpenWRT, because it deals with modems well, the author has also recently been playing with MQTT for remote reporting. I havent compiled kplex for that environment but its been done. Given I have a router on the boat anyway, that direction seems to save some duplication but perhaps isnt as much fun :)
 
As an alternative, which covers some of this and your other current project (NMEA data to website), did you think about compiling @laika's kplex on a router and using that as an interface to OCPN ? I did that with Tomato on an ASUS R16 about 7 or 8 years ago but not using that OS or router anymore. Currently using ROOter, an offshoot of OpenWRT, because it deals with modems well, the author has also recently been playing with MQTT for remote reporting. I havent compiled kplex for that environment but its been done. Given I have a router on the boat anyway, that direction seems to save some duplication but perhaps isnt as much fun :)

Part of the motivation for doing these projects and making them open source is that they are self-training for my day job - embedded software development. The recent Seatalk/MQTT/website project, for example, was to learn ST's new IDE STM32CubeIDE and the new CMSIS RTOS v2 API. My work (when I do it, which is not very often) uses STM32 and Renesas RX processors running real time OS's. I don't do much with Linux, don't own a RPi, and therefore my projects don't use Linuxy type stuff. That doesn't mean that they are not good solutions, just that I'm not motivated to learn how to use them.
 
They are all here...

miniwinwm/YAPP
Sadly, what's not there are the schematics.

I've built a number of your projects over the years, and as a poor sailor, they have been invaluable. Many many thanks!

I now need to build another project, your SeaTalk Simulator, as I wish to inject some messages into my SeaTalk bus and see how the various displays respond.

Specifically, I want to display the temperature of the coolant in the engine. I have a conventional gauge with resistive sensor, but the gauge is small and mounted low, at an awkward angle. I'd like to have it displayed in large numbers on one of my existing Raymarine displays, as several purport to display water temperature.

(I don't need to know the temperature of the water I'm sailing in. The water here is either cold, or very cold, and I don't need a display to tell me just how cold. A warning sticker that says Don't Fall In is entirely adequate.)

My plan is to read the voltage across the existing engine sensor and from a lookup table, determine the temperature. Then I create a SeaTalk water temperature message and place it on the bus.

But before I go to all that trouble, I want to make sure my displays will actually show something.

So, your SeaTalk Simulator seems perfect.

I'm writing because the page from your old (OLD) website does not include a schematic, it says to just use the SeaTalk2USB circuit.

However, that circuit is read only; it does not write to the SeaTalk bus.

Do you have a schematic somewhere that does write to the bus?

Thanks in advance for any thoughts or assistance.

Alan
 
Top