YAPP: A Sailing Raspberry Pi

OpenCPN successfully built under Raspbian ... a considerable improvement in performance, looks like it's fast enough to be usable.

Any chance of sharing a cheeky "sudo make package" to save everyone [edit: me] the tedium of having to compile themselves?
 
Last edited:
Any special additions to the command line to make it compile?

you'll need one of the Raspbian SD images (I used the Pisces image)

For fldigi there were a lot of dependencies that had to be juggled

OpenCPN was straight off their web site

The only command line parameter I used was the target directory for the install, I didn't bother using arch=native or arch=armhf, maybe next time.
 
Glad someone is looking at this! I've had the email from RS so I can place the order, looking for a nav system on the boat using a 7" lcd screen from a duel screen dvd player.
 
update

Testing wasn't as I'd hoped:

- openCPN was fine with raster charts (plug for http://www.antarescharts.co.uk/), but barfed when opening CM93 vector charts.
- fldigi seemed OK at first, but the clock was inconsistent so charts were all over the place. I don't know if the problem is with the Pi or the USB sound dongle. The first 20% of a chart was OK, but it then drifted rapidly; different results and CPU correction needed each time the program was run. CPU 100% so probably just not enough grunt.
- No success with Navtex, but not surprising according to the coastguard's nav. warnings.
- JWX worked perfectly on the reference laptop, but stuck at 100% CPU on the Pi with no output. Again, looks like it's being overworked.

Back to the drawing board and a bit of head scratching :(

Gave up and did some sailing and fishing instead .. lots of mackerel around :)
 
Testing wasn't as I'd hoped:

- openCPN was fine with raster charts (plug for http://www.antarescharts.co.uk/), but barfed when opening CM93 vector charts.
- fldigi seemed OK at first, but the clock was inconsistent so charts were all over the place. I don't know if the problem is with the Pi or the USB sound dongle. The first 20% of a chart was OK, but it then drifted rapidly; different results and CPU correction needed each time the program was run. CPU 100% so probably just not enough grunt.
- No success with Navtex, but not surprising according to the coastguard's nav. warnings.
- JWX worked perfectly on the reference laptop, but stuck at 100% CPU on the Pi with no output. Again, looks like it's being overworked.

Back to the drawing board and a bit of head scratching :(

Gave up and did some sailing and fishing instead .. lots of mackerel around :)

Vector graphics, multitasking, sound processing, video drivers, USB stack ..... not asking much from a sub £30 system are you lot?

Presumably some of these problems should be fixed when the accelerated X drivers are released?

I understand that there's also a mainstream debian hard float distro in the pipeline.
 
Vector graphics, multitasking, sound processing, video drivers, USB stack ..... not asking much from a sub £30 system are you lot?

Well, I once wrote a real-time radar digitizing system on a 4 MHz Z80 single card computer with about 2 kb of RAM and 4 kb of EPROM, so I reckon the Raspberry Pi should have no problem! Admittedly I did have some (1985) state of the art digitizing circuits as a front end. But it still shows just how much of the power of a modern computer is frittered away in operating system overheads and inefficient code. Linux is far better than Windows in this regard, but there is still a lot of overhead that (for a dedicated application) is not necessary. For example, a simple I/O routine boils down to about 10 machine code instructions when written in assembler (about 5 if you're not bothered about the code being re-entrant; most of the 10 is storing and restoring register states!); I bet the equivalent code in even an efficient OS is MUCH bigger! Furthermore, most OS use polling on interfaces rather than being interrupt driven; for real time FAST operation, interrupt driven code is much better, but requires intimate knowledge of the hardware conditions.

If we were really serious about this kind of kit as a chart-plotter or whatever, we'd probably use a real-time OS like OS-9 or QNX, or whatever opensource equivalent you fancy.
 
"fldigi seemed OK at first, but the clock was inconsistent so charts were all over the place."

With Weather fax on fldigi, there can be two problems:
* If this is a progressive slant, that is, the image is uniformously slated, then the clock should be corrected.
* If, on the other hand, there are portions of lines which are lost, so that horizontal slices of the image are randomly shifted right or left, it is because samples were lost, and this happens if the CPU was too busy.

There are some optimizations which might not be available yet for Raspberry. Please see for example the file fldigi/include/threads.h :

#if USE_TLS
# define THREAD_ID_TYPE __thread intptr_t
...
#else
# define THREAD_ID_TYPE pthread_key_t
...
#endif // USE_TLS

Could you please tell if the compile-time flag TLS is set when building fldigi ? This might explain the performance problem for this platform which is relatively new.

Thanks !
 
I've recently started exploring the R-Pi, and in the course of my investigations came across this site: http://www.robot-electronics.co.uk/

It occurred to me that using one of their compass sensors, one of their motors, and a bit of engineering, the R-Pi could be the basis of a low-cost Autopilot. I don't have time to investigate this in depth at present due to other projects, but it might be of interest for someone else.

They even give some R-Pi -specific code examples...http://www.robot-electronics.co.uk/htm/raspberry_pi_examples.htm
 
Last edited:
Vector graphics, multitasking, sound processing, video drivers, USB stack ..... not asking much from a sub £30 system are you lot?

Well the Pi is as powerful as say a PII laptop, plenty of those used for boaty stuff. Personally I'm more interested in the RISC OS port though. Not that it would be much use for sailing unfortunately.
 
Top