Asynchronous SeaTalk

Guys,
Nick is right, i should be able to read with Nick's hardwareserial and write to softwareserial and it IS working, but there seems to be a synchronization issue (mine not Nick's) - might need to jiggle the delay(). I'm having some trouble with vision and some of my problems are with hardware misconstruction. My drive to make compact hardware seems to be in direct conflict with getting it right. I suspect that I'm going to build my hardware interface bigger and more spread out so i can better see misconnections. then when I'm sure i have it running right, build the final box for installation.

This evening's discovery was that the 5 volt supply from the Uno isn't quite enough for the max232, the compass, and the gps module (Duh). The voltage drop was enough to make it intermittent the way I have it hooked up, so tomorrow a 5 volt regulator get's hung off the 12 volt feed from the seatalk system and I should be back to solving software problems.

john

hi Dave,
After the convulsions attendant on discovering that the loader routine for the Mega 2560 doesn't work quite right on Ubuntu 10.10, but does on Windows, that the Sparkfun UNO shield i was using also doesn't work quite right with ports used for softwareserial, and making headers to connect to the mega, AND getting it to work, I'm back to seatalk. I'm going to try migrating the listen parts of Frank Wallenwein.s code to the 2560. I need the collision detection and this seems the most efficient way to get it given that i don't know what i'm doing. I have two seatalk devices and so have to deal with collisions.

have you enjoyed any progress with any of this?

john

John,

I'm still very keen on this project but you are way ahead of me -- work and family have limited my ability to do much of anything this week and I'm traveling next week so I am going to be useless for a while.

In fact, I'm a bit clueless about the need for collision detection. I would have thought that the SeaTalk bus would have a string of statements that could be read and parsed to find the ones you want but obviously that isn't correct.

So, I offer encouragement but contribute nothing!

Cheers,

David

If you are using the Mega, can't you connect different units to different serial ports?

Nick, yes. different things on different ports, but the odd thing was that ubuntu 10.10 arduino 1.0 iDE worked fine with the UNO but wouldn't correctly program the MEGA. Windows arduino 1.0 does program fine. I reloaded every conceivable part of the software but no joy - so 2 or 3 days lost. I don't like windows much, but I'm glad I kept it for the two things that ubuntu doesn't do well.

Now I'm going to build a simpler level changer for the incoming seatalk sentences and then mess with your software til i get it right. it will take a few more days. I am retired, but still have other obligations and sometimes i just fall into a no-progress loop.

hardware fixed. board DOES need the 12 volts it would have gotten if the + lead had not become disconnected.

Since we only need to read seatalk, I need to better understand how Nick's code reads. Right now I'm seeing lots of zeros and an occasional 40 which suggests that there is still a problem with collision detection and beginning of datagram identification.

john

David,
you don't need to buy dfrobot's lcd to get buttons and resistors. make your own. you can download their schematic to see how they did it.

my repeater is going to be in the v-berth where we sleep. it will have a 4x20 line serial lcd and the buttons. the arduino will be up near the helm where the seatalk signals are, the compass will be compensated, and the gps gets good signal.

I'm planning a small 12 volt to 5 volt power supply for the repeater for the lcd and the buttons thinking that the 2 way voltage drop running from the bridge to the v-berth and back may be a little much. I'm assuming that the logic signals to the lcd can stand the distance.

john

David,
I'm giving up on the SeaTalk interface. Since I have Wallenwein's NMEA-SeaTalk bridge, I need only bring in the rs-232 output with its NMEA sentences and siphon the wind, and depth data from that. I had thought it would be more elegant to monitor the seatalk bus directly, but am completely unable to get usable datagrams which i can see.

I built the level changer and it does work, I think. I would have thought i could read the seatalk datagrams with the level changer, which after much fussing, I'm certain is built correctly. they could very well have been received but not being able to output them to a terminal where I can look at them, means that I cannot concoct the code i need to parse them. The problem could well be the limitations of the terminal programs I'm using Terraterm on the pc, Moserial and Serialport terminal on Ubuntu Linux. Maybe there's another one which is more amenable to 9 bit/ 11 bit bytes.

I am not able to see anything using Knauth's dos monitor program. Maybe this suggests that I've screwed up the converter- don't know. In any case, Wallenwein's bridge can read the seatalk ok, so I know the wiring is ok.

Using SerialPort, I was able to record a stream of hex data from the Seatalk bus. There were sufficient repetitive byte sequences to make me think that real data are going by but the actual hex codes don't appear to be seatalk - nothing recognizable.

The Wallenwein code is voluminous and written for the atmega16. I at first thought I would go through it and change the various atmega16 specific elements to mega 2560. This doesn't look impossible, but after doing a couple of the library files, i realized that this could take a lot of time and for me, with my profound ignorance, maybe way too much time.

I'd love to find someone who has built the level changer, run Knauth's dos monitor on a seatalk line connected to more than one sender and had it work.

I even keep an old Compaq M300 around just so i can have a (gasp) real rs-232 port.

In any case, good luck with your project. Thanks, Nick for your efforts.

oops. I built another level changer and this one works with the dos programs which Thomas Knauth has on his site, so back to experimenting with Nick's 9 bit reader. maybe i will get it eventually. No, i have no idea what was wrong with the first two converters i made, possibly bad transistors?

One other thing. The SeaTalk bus shouldn't have anything else connected to it (the NMEA Bridge for example). It looks like this is where the signals were going. It should be ok if it is powered up, but in my testing it wasn't.

jferg:
In any case, good luck with your project. Thanks, Nick for your efforts.

My pleasure. Hopefully it will come in handy one day.

Meanwhile in your case I would be throwing hardware debugging at it, like a logic analyzer. You will see clearly what is being sent. Possibly supplemented with a scope to make sure the voltages are correct.

Ah but Nick,
I live on a boat. We've had to raise the bootline three times since we moved aboard 8 years ago. it isn't all electronics. I know i can get scopes which use pcs for displays, but that might be a bit much for the local Chancellor of the Exchequer.

I'm beginning to have more confidence that I'll be able to make something work. Until I saw the dos program printing out datagrams and realized that i couldn't have both the bridge and the converter on the seatalk bus and still have enough signal to read, i was just flailing.

it is useful to know that one's hardware is percolating before all sorts of time is spent troubleshooting software that will never work before a signal shows up.

it's all fun. once this project works and I've made final hardware, it's on to using an accelerometer to provide altitude leveling for the tv satellite antenna. It has great azimuth control, but to keep the costs down no altitude. idea is you set it for the latitude you're at which here in NA in the lower lattitudes works great - farther north the twitchier.

best regards, john ferguson

I think I've got it. I very carefully built the hardware seatalk-rs232 converter - used a better PNP transistor - it's listen only. Then I built a better rs232 to ttl converter with a max232 AND built a 12 volt to 5 volt supply - 5 volts from arduino isn't enough to drive the max232. I'm bringing the ttl data into my Mega on Serial1 and it's displaying.

I'm getting good SeaTalk data coming into the Arduino, and it looks like an UNO would be fine assuming it can hold the code. All I need now is to parse the two datagrams I'm interested in.

my recommendation to anyone thinking of doing this is FIRST get the hardware sorted out. Build the SeaTalk to RS 232 converter shown on Thomas Knauf's site, and using Seamon1.exe in DOS, (you'll need a machine with a real serial port for this) keep working on your wiring until you get recognizable datagrams. An unbelievable amount of time can be wasted in tail-chasing if you aren't getting a signal. :smiley: - I know, I've already wasted it.

Nick,
in reviewing older comments, you asked why not just connect the seatalk devices to separate ports, if i understood you correctly. their output wouldn't change and the collision and retransmission events when they are on a single bus do not prevent an adequate flow of data. Seatalk runs at 4800 bps. Getting a usable sentence every few seconds is plenty good enough for this application - movement of a boat at anchor. likely also good enough for 6 knot boat underway.

i apologize for being a little slow, but it appears that setting arduino Serial1 (seatalk listener port) to 9 bit and then reading the 9th bit has nothing to do with parity. If the 9th bit is up, then the byte is a "command" byte and the first byte of a datagram. If there is only a space there, then the byte is not a command byte and is either nothing, or a databyte.

this is very hard for me.

True, it looks like they are using the 9th bit in that way. However that bit is in the "place" where parity bits used to be (and still are). It appears that you either can use the 9th bit for data, or parity, but not both (which would require a 10th bit, if you had 9 data bits AND parity).

it's amazing how limiting nomenclature can be. As soon as i realized this the 9th bit didn't have any other name if I was reading 9 bits, it got a whole lot simpler. Just look in the 9th bit's place - now i have to figure out how to do that. i have a bunch of suggestions including the ones in the manual. I need to run the seatalk bus back to where i can sit down while i'm running trial and error. the joy of the arduino is how quickly you can interate code.

it's funny that sampling a datastream is a bit like sticking your toe in the water, you don't need to know how cold a specific pint of water is only any pint that is there when you touch it. this must be completely different for the people who have to deal with every byte and cannot miss any.

best regards, john

jferg:
Just look in the 9th bit's place - now i have to figure out how to do that.

Yes. In the modified serial code I posted the 9th bit's place is the 0x100 bit (in hex). Or in binary: 0b100000000 (1 followed by 8 zeroes, the 9th bit).

Bingo!

Output from Arduino mega2560 with Raymarine ST40 Depth and Anemometer connected via Signal Convertor (See Thomas Knauth) and max232 (with 5 volt power supply) to reduce 12 volt signals to ttl, connected to RX1 on mega and read by code which follows. See Knauth's website for datagram translation.

1002206E0;
1101015;
1111C4;
1002206C0;
1101035;
1111C3;
1002206C0;
1101023;
1111B7;
100220700;
UPDATE: (following wrong, it is there) note that I appear to be losing one byte on the windspeed datagram. should be another one at end. ???

Code:

 // simple port reader for seatalk
// runs on mega2560
// 9th bit leads first byte such that "00" becomes "100" 2/26/12 j ferguson

void setup()
{
  Serial.begin(115200) ;
  Serial1.begin(4800,true) ;
  Serial.println("this is the start of simple seatalk passthough") ;
  delay(2000) ;
}
void loop()
{
  if (Serial1.available ()) 
{ int inbyte = (Serial1.read());
   if (inbyte >= 0x100)
   Serial.println (";") ;
   
   Serial.print (inbyte, HEX) ;
}  
 
}

This uses Nick's modified HardwareSerial. h to see the 9th bit. David, if you are still following along here, and would like very specific description of hardware, let me know. Now on to the parsing.

if (inbyte >= 0x100)

Serial.println (";") ;
 
Serial.print (inbyte, HEX) ;

I'm not sure if it will make much difference but I would "and" out that command bit, like this:

if (inbyte & 0x100)
   Serial.println (";") ;   // got command bit
   
 Serial.print (inbyte & 0xFF, HEX) ;

Also changed your test to be a bit more "logical".

thanks much Nick. It turns out I wasn't losing the last byte of the windspeed datagram - one beginning with "111" I was fooled by the printer dropping leading zeros in hex print. It won't matter though because now that I've got reliable reading, I just need run these strings into a buffer, extract the bytes which have the data, do the math, and then cook up the display routines for the LCD.

i had been reading these data from an NMEA stream, but for some reason thought it was worth the several weeks of fussing with this to just get the data directly from the SeaTalk instruments. I see I need to become comfortable with bitwise manipulation. I can vaguely remember using this sort of thing writing Z80 assembler for modem routines on the old Osborne. I didn't know what i was doing then either, but eventually i got it to work.

best regards and thank you again.

john ferguson