Picaxe and Seatalk?

P

prv

Well-Known Member
Joined
29 Nov 2009
Messages
37,358
Location
Southampton
Visit site
A couple of months ago when Angus was considering new YAPP ideas, I described a gadget I'd like, to silence the depth alarm while berthing in a shallow harbour: http://www.ybw.com/forums/showthread.php?411851-YAPP-ideas&p=4990868#post4990868

The guru himself wasn't interested, which is of course his prerogative. However, while working on something else yesterday that needed the instrument power turned on, and being beeped at every twenty seconds, I decided I'd have a bash myself.

My previous attempts to program PICs the proper way have not gone well. I can crank out adequate rusty C to describe the behaviour I want, but I lack a lot of the assumed knowledge in dealing with the hardware.

However, just before Christmas I discovered the Picaxe system. It was developed for use in schools so is about my level :). The actual hardware is a PIC, but it is pre-programmed with a sort of minimal OS that accepts and runs programs compiled from a form of specialised BASIC. The OS and compiler between them handle a lot of the low-level details, so you can just say things like "read in a serial byte" without having to manually set all kinds of registers and flags first.

With this system I was able to knock up a basic but useful project in a couple of hours, and apart from a couple of syntax errors and tweaking some tone values to make nice-sounding beeps, it more or less worked first go. So, given that my needs are generally simple, I think this is what I'll stick with for now.

I just wondered whether anyone else had used Picaxe, and happened to have got it working with Seatalk? Standard serial would be easy, it's built-in, but the extra "command bit" in Seatalk complicates matters. If I can piggyback on someone else's work for that, it would be nice :)

(The actual behaviour will be pretty simple - as long as it has power, the device will watch for message 00, and if it sees one with the "Shallow Depth Alarm is active" flag set, it will output message 68 (or possibly 70 if that doesn't work). Rinse and repeat.)

Pete
 
Yes, I've been working with Picaxes for a while. I think it's fantastic. Very adaptable and simple to program. For the interested amateur with limited understanding of processors, it is ideal.

The strongest point in its favour is the very helpful Users Forum at http://www.picaxeforum.co.uk/

As for Seatalk, I don't know enough to be sure but I believe that if it's similar to NMEA 0183 then the Picaxe Serial in and out commands should be able to cope. I know some other Picaxe users have succeeded with NMEA 0183.

Here are some projects that I reported some time ago. The capability of Picaxes has improved considerably since these were devised so there will be much better ways to do these now.

http://www.picaxeforum.co.uk/showthread.php?9544-Boat-project-1-Fridge-controller

http://www.picaxeforum.co.uk/showthread.php?9545-Boat-project-2-Barograph possibly my favourite

http://www.picaxeforum.co.uk/showthread.php?9547-Boat-project-4-Battery-load-tester I also made a NASA BM1 type version of this but I haven't written it up.

A problem has been keeping up with developments in their products but thankfully everything so far has been backward compatible so old programs will still work on newer chips.

Derek
 
cpedw said:
As for Seatalk, I don't know enough to be sure but I believe that if it's similar to NMEA 0183 then the Picaxe Serial in and out commands should be able to cope.
Click to expand...

Sadly not, as alluded to in my second-to-last paragraph. Seatalk has an extra bit in each character which is set to indicate the start of a new command. The standard Picaxe serial commands don't work with this.

I have found a forum thread in which someone was able to POKE the underlying PIC config and make it work with the DMX lighting control protocol, which has a similar extra bit. I haven't examined that code properly yet. And there's always the option of bit-banging it directly.

Pete
 
Not having the slightest clue about this microcontroller stuff I can't contribute anything positive, but on the negative side I should probably raise the issue that if you're going to be writing back to the network you probably want to also be thinking about collision management: that may affect what approach you take to writing the data.
 
laika said:
Not having the slightest clue about this microcontroller stuff I can't contribute anything positive, but on the negative side I should probably raise the issue that if you're going to be writing back to the network you probably want to also be thinking about collision management: that may affect what approach you take to writing the data.
Click to expand...

Hmm, good point, and not one I'd thought about.

I believe Seatalk is collision-detect with a random backoff, a bit like classical ethernet. So if my little box just rudely barges onto the network at infrequent intervals, it won't disrupt anything else - there might be a collision, but if so the other device will detect it and try again shortly. But it may well be that the collision mangles the box's own output, in which case the "shut up" message won't get through. However, that in turn will mean the depth alarm remains active, and on the next trip round the loop the box will notice this and send its message again. Provided I don't get locked into repeated collisions with some other device, I think it'll work ok. I might add a short quasi-random sleep into the main loop to help deconflict things.

Cheers,

Pete
 
I've used Picaxes a lot but never tried sending anything more than simple strings and data over the serial link, however, from memory can't you send 16 bit values and would this cover the 11 bits you need for Seatalk even if you have to compact it? Just an idea... Also there's a pretty good Picaxe forum on the picaxe.com website so your problem might interest one of the resident nerds there.
 
whiteoaks7 said:
I've used Picaxes a lot but never tried sending anything more than simple strings and data over the serial link, however, from memory can't you send 16 bit values and would this cover the 11 bits you need for Seatalk even if you have to compact it? Just an idea... Also there's a pretty good Picaxe forum on the picaxe.com website so your problem might interest one of the resident nerds there.
Click to expand...

Thanks - I've already posted there and it looks like the idea's a goer. The underlying PIC does have a 9-bit mode in its serial hardware; the Picaxe system doesn't expose it but it can be accessed via PEEKs and POKEs.

This is very much a back-burner project so don't expect to see rapid progress :)

Although if someone can suggest a good interface circuit I'd be obliged. On the web I can only find ones for PC serial ports, and I suspect they're not quite right for a PIC. I was planning to borrow the hardware design from one of Angus's YAPPs, but I don't have the software to read whatever format his schematics are in.

Pete
 
prv said:
I believe Seatalk is collision-detect with a random backoff, a bit like classical ethernet.
Click to expand...

I understand that NMEA 2000 (so includes the Seatalk versions derived from that) uses the ID of the transmitter to resolve collisions, rather than both transmitters randomingly backing off. Because of the nature of the bus architecture, the lowest ID always wins and continues transmitting.

Not sure at all about the original Seatalk.
 
fwiw in an exchange I had with Frank Wallenwein a couple of years ago he said that the design on the thomas knauf site was not so good at higher data rates and he now used an alternative (although I didn't find out what that was). ISTR NigelMercier posted a circuit which was apparently what Raymarine used (or at least closer to it) a few years back. A bit of googling suggests the input needs to be translated to the 0-5v range but you probably already knew that and certainly want to hear it from someone who knows more about this than me :-)
 
laika said:
fwiw in an exchange I had with Frank Wallenwein a couple of years ago he said that the design on the thomas knauf site was not so good at higher data rates and he now used an alternative (although I didn't find out what that was). ISTR NigelMercier posted a circuit which was apparently what Raymarine used (or at least closer to it) a few years back. A bit of googling suggests the input needs to be translated to the 0-5v range but you probably already knew that and certainly want to hear it from someone who knows more about this than me :-)
Click to expand...

Indeed, and I think Nigel may have come up with a design. The Raymarine one is quite complex and not what I want to build, but maybe there's something in between that and the basic Knauf version. I suspect a Max232 chip might be part of the solution.

Pete
 
laika said:
fwiw in an exchange I had with Frank Wallenwein a couple of years ago he said that the design on the thomas knauf site was not so good at higher data rates.
Click to expand...

I've heard this before, and never understood it. There's no such thing as a higher data rate in Seatalk - it's always 4800 baud, which is very low. The Knauf interface circuit has always worked well for me. I've looked at the waveform on a scope, and it's as clean as a very clean things. Seems to handle collisions well also.
 
AngusMcDoon said:
Wrong voltage levels for Seatalk from a MAX232, or any RS232 driver chip.
Click to expand...

I think prv was talking about the other side: the design he's got is for seatalk -> rs232. I believe he wants seatalk -> [whatever is suitable for the picaxe thingy: 0-5v?] and I'm guessing the max232 was an idea for converting between the rs232 and 0-5v if that's what the picaxe needs, i.e. seatalk <=> rs232 <=> 0-5v
 
whiteoaks7 said:
I've used Picaxes a lot but never tried sending anything more than simple strings and data over the serial link, however, from memory can't you send 16 bit values and would this cover the 11 bits you need for Seatalk even if you have to compact it? Just an idea... Also there's a pretty good Picaxe forum on the picaxe.com website so your problem might interest one of the resident nerds there.
Click to expand...

Every 8 bit value is sent as more bits, because there are start, stop and possibly parity bits. You can't combine 2 8 bit values, because then you'd get spurious start/stop/parity bits in the middle. The UART hardware adds these wrapper bits automatically.

The problem with using a UART for Seatalk transmission is you can't read back each bit as it is transmitted for collision detection, because the write is under hardware control, and you can't stop a write mid-byte if a collision is detected. That's why I used a soft UART. I'm not sure if using PICAXE whether the level of timing and control required to implement the soft UART is available. The soft UART code needs to be called 38400 times per second (8 time slices per bit), and to achieve this rate on a small processor it needs to be slick code and run at a higher priority to everything else.
 
Last edited:
laika said:
I think prv was talking about the other side: the design he's got is for seatalk -> rs232. I believe he wants seatalk -> [whatever is suitable for the picaxe thingy: 0-5v?] and I'm guessing the max232 was an idea for converting between the rs232 and 0-5v if that's what the picaxe needs, i.e. seatalk <=> rs232 <=> 0-5v
Click to expand...

Ok. MAX232 good for RS232. The PIC needs 0-5V or 0-3.3V depending on the chip. Running them at 3.3V uses considerably less juice.
 
AngusMcDoon said:
I've heard this before, and never understood it. There's no such thing as a higher data rate in Seatalk - it's always 4800 baud, which is very low. The Knauf interface circuit has always worked well for me.
Click to expand...

Just rummaged through my various mail archives and found Frank's mail and apologies: I mis-quoted him. It's not data rate but number of devices on the bus. He said it was fine with "just a few" but would fail (either some loss or total bus failure) with "many" instruments on the bus. His example for "a few" included AP, plotter, wind, tridata and "a few others", so heaven knows what "many" is. No more detail, sorry.
 
You must log in or register to reply here.

Other threads that may be of interest

wonkywinch
Interlinked Carbon Monoxide alarms
Replies
12
Views
308
PaulRainbow
PaulRainbow

Share this page

Top