Project 59 NMEA for the DashPIC

Trying to make 16F57's Rx, reformat, and pass on NMEA information
  The DashPic  project is evolving, and now seems a good time to get on with the NMEAPIC's programming. The program is kind of strange and bizarre as I didn't use any conventional methods to get the NMEA data (i.e. an RS-232-like loop)
I wanted the chips to be able to send data while still receiving it, so the loop had to include sending data to the DashPIC, waiting for the DashPIC, and encoding the sentence prefix (i.e.$xxxxx,) into something that the dash pic could read quickly, a single byte. This all created a timing nightmare, so I decided to use the TMR0 module. It simply waits for the startbit, then once detected, waits for 104 uS (1/2 the full width of 208 uS) then resets the TMR0 module to count to 208. The numbers are nice because the Xtal frequency is 16 MHz /4 then /4 in the prescaler. The other routines, while is there loops, check the count or TMR0, and if >207, return control to the NMEA RX routine. 208 is subtracted instead of clearing the register, which makes things accurate enough. Because NMEA, like RS-232 in most cases, has a start bit and stop bit for every byte, re-syncing is easy.
  The output to the DashPIC is where the problems started. Originally, as I said, the program was written to do as stated, and the DashPIC would need to vigilantly watch the input for a low on the clk. After an ack signal on the data line, the data could be clocked out. Problem is there are 3 other NMEA PICs trying to do the same thing. Timing, and each chip getting held up became an issue, and for reasons beyond how much typing I'm going to do today, the whole thing seemed to create more problems than it solved.

  I fine tuned system would be able to do it, but I want to be able to make changes in the future without having to worry about messing up the timing of this and that. If I was going to manufacture these, the whole thing would be very different, but one must work with what one has right?

  Anyway, this is all pretty boring for you probably, so I'll get to the good stuff. I decided to set the NMEA PICs up to "spurt" data on to the bus, without any regard as to whether the DashPIC was listening or not.
This sounds pretty reckless, but really it's not. As can be seen in the scope comparison, the "spurt" is quite small in comparison to the "giant" NMEA data coming through. That's because my bitwidths are <4uS each compared to the 208uS of NMEA.


NMEA VS. S-BUS CHAOS
 There still is a chance some of this data may scramble together simultaneously, so I have added a CRC checksum to the end, just like *some* NMEA senders do. (I say some because none of our old equipment does, nor does the fairly new (>2005) stuff, just the really new USB  Zenstar GPS does, even though all of the ancient NMEA guidelines include the "*xx" at the end of each sentence!)  The startbit (low) is longer than anything else on the clock line, so easy for the DashPIC to "see". The first byte is the "ID code" I created for each sentence that I care anything about that comes from a GPS, Wind speed ind, Depth Sounder etc, and will let the DashPIC decide to "take it or leave it" right away.

  Now the DashPIC can come and get data whenever it wants to. If it needs lots of data, it can continually poll, if not then the occasional peek is ok. After all, how many times a minute does one need to update their position, heading, etc. Even in this crazy way, the DashPIC will still process 10's of sentences a second, (Don't forget, there will be 5 or 6 units feeding data in) as in human time all of this is still pretty fast.

  A  conditional "poll" will suffice:
-casual = If clk is High, check/wait for 100uS. If active (low) but too short widths, then already started so come back later.
-need *this* now! = wait, wait and wait, pickup everything that comes along, checkit and chuckit if not *this*

nmeaExperiment-v1.2.ASM is the listing for the NMEA-PIC's, this has dual input, the second hasn't been tested yet, so if you wire this up on a board, pull Port A,0 up. The input (A,0) is inverted so use an opto-isolator or a transistor to turn it around. It's always a good idea not to shove an NMEA or RS-232 signal/voltage directly into a processor with no protection. Practice "Safe circ's"  kids LOL.
The other listing, which outputs data to an LED via a 7447 decoder, only because I have a board all made for that from the 1900's, is pretty simple. 2 inputs 4 outputs. I ran the oscillator input off of the output from the NMEA PIC just because I don't have another 16 MHz xtal around here at the house. The code for that is testRXer.ASM and may have something interesting in it for someone. It is pretty cool to see info for a time display on my (very) old LED board fed through from another chip, then from an RS-232 from a network of virtual ports brought in from a USB, then a RXer RXing satellite signals from space. Kinda makes it more real for me.

Until next time, more updates to come on the NMEA subject

Updated Nov 6th 2008

 

 


 

March18, 2009
During the last week I managed to do some tests while we were on the boat. The NMEA (high speed/coded) needed fixing. It was mostly to do with timing. Also the NMEA code $0D needed to be removed from the NMEApic's as it was causing inadvertant carriage return situations, thus no data was following. $0D is, of course, the wind speed and direction. The one I really need for the simple auto-pilot routines!
It is now code $16 instead. ($0D) is GPXXX if a car. ret is needed for whatever) The main NMEA routine is now in dashPIC.asm (always up-to-date)

The multiple NMEA signals didn't appear to cause a traffic jam on the 2 wire bus to the PIC17F74, but I'm sure there were a few collisions. Thanks to CRC's though none got through to the display the whole time I was testing it. The "spirt" system seems to work quite well!

The Pedistal Original display was connected directly (via RS232) to the dashpic for monitoring, and modified to accept the $$ headers just to try it out. I chose the wind NMEA to display as there was a storm that night!

The video is on youtube.com, but can be seen here --->>

The compass underlay is to see true wind direction as the plate will be showing heading and the "windex" will be showing the wind relative to it. Because I couldn't hook up the compass(need cable yet!) I couldn't show it.

The alternate  (#5) NMEA input was tested and performed as expected, but can only be used as an override, i.e. DGPS will override Furuno GPS. While the Alternate has signal, the other is ignored unless there is a space between sends.(>8 seconds, which could be modified to, say, 1 second) in which case the original input will have control again.

This was done because when the dash PC is on, the Fugawi program sends Zenstar USB DGPS data to the comPort, which is more accurate but more power consumption. The difference is noted by setting bit 6 in the NMEA PICs type header code.

Other parts were tested as well, but before I could test the WindGen, Solar and waterGen charge Amps inputs and the "real" Ruddim inputs we had to go back to Alberta.

 

 

 
Disclaimer: The software offered herein is presented with no warranty or guarantee of any kind, so if it doesn't work, it's something you did, I said, or both. If you are using this with AIS, it won't work (but it'll be a future subject here) and if you are using this with anything other than 4800 baud (ie the new 38,400 baud rate)  it won't work, unless I update it after acquiring a new equipment that would have to be donated to us ( full color display if it's a radar ok?) because we're not buying any more electronics stuff!
 


to Individual projects main page

Forum <- - -> Boatcam