https://github.com/jons/libnmea

nmea 0183 tools
https://github.com/jons/libnmea

Last synced: 18 days ago
JSON representation

nmea 0183 tools

• Host: GitHub
• URL: https://github.com/jons/libnmea
• Owner: jons
• License: other
• Created: 2011-06-24T21:05:23.000Z (over 13 years ago)
• Default Branch: master
• Last Pushed: 2011-07-26T16:54:01.000Z (over 13 years ago)
• Last Synced: 2024-07-31T22:56:52.980Z (3 months ago)
• Language: C
• Homepage:
• Size: 129 KB
• Stars: 14
• Watchers: 9
• Forks: 23
• Open Issues: 0
• Metadata Files:
  • Readme: README
  • License: LICENSE

Awesome Lists containing this project

README

        
libnmea

nmea 0183 stream tools

[email protected]

FOR MAINTAINERS

  run ./bootstrap.sh after checking out the project.

  or, bootstrap it yourself.

IMPLEMENTATION

  you can use this library to manage NMEA streams from a device, however you

  happen to get them. use nmea_concat to add any new input to the buffer

  manager, partial or not. then use nmea_scan and nmea_parse to trigger your

  event, foo, on the presence of a message boundary.

  here's an example of an event driver that never terminates.

  {

    nmeamsg_t  msg;         /* libnmea message context */

    nmeabuf_t  nbuf;        /* libnmea read buffer state */

    char       src[SRCSZ];  /* source stream buffer */

    char     rxbuf[BUFSZ];  /* read/recv chunk */

    size_t   rxlen;

    char     evbuf[MSGSZ];  /* complete message "$...*xx\r\n" */

    size_t   evlen;

    nmea_ctor(&nbuf, src, SRCSZ);

    for (;;)

      if (poll(fd, ...))

        if (rxlen = read(fd, rxbuf, BUFSZ))

          if (nmea_concat(&nbuf, rxbuf, (size_t)rxlen))

            while (nmea_scan(&nbuf, &msg))

            {

              evlen = nmea_parse(evbuf, MSGSZ, &msg);

              foo(txbuf, txlen);

            }

  }

  the buffer sizes will vary depending on the device you're dealing with and

  your intentions for it, but, MSGSZ should always be at least as big as the

  longest possible sentence used to communicate with the device.

  SRCSZ should be big enough to hold several messages if they cannot be serviced

  rapidly enough.

  depending on whether you are performing a blocking read/recv or not, BUFSZ

  should be tuned somewhere near the size of the most common messages, or the

  average of all possible message sizes, or some such heuristic.

  one way to tune it in realtime would be to measure the number of read/recv

  calls, R, and foo() events raised, E, over some period of time. if the real

  value E/R approaches one, then BUFSZ is doing fine. as it heads towards

  zero, however, it takes too many read() calls to raise one foo(), which we

  can assume means that BUFSZ is too small.