Loading ...
Sorry, an error occurred while loading the content.

Possible Future Developments?

Expand Messages
  • ve6fd
    Just some thoughts/questions about possible developments of the OT1+/OT1-USB & OT2m. 1) Any chance we ll see an OT2m model with GPS input via some form of USB
    Message 1 of 2 , Nov 20, 2011
    • 0 Attachment
      Just some thoughts/questions about possible developments of the OT1+/OT1-USB & OT2m.

      1) Any chance we'll see an OT2m model with GPS input via some form of USB connector? USB output is becoming common on puck-type GPS receivers.



      2) Same question for future OT1+/OT1-USB series, or successors?



      3) Might future OT1+/OT1-USB models accept Garmin proprietary input?
    • Scott Miller
      ... Here s some information on why it s not so easy: http://www.argentdata.com/support/usb.html The T3 does theoretically have some capability for acting as a
      Message 2 of 2 , Nov 20, 2011
      • 0 Attachment
        > 1) Any chance we'll see an OT2m model with GPS input via some form of
        > USB connector? USB output is becoming common on puck-type GPS receivers.

        Here's some information on why it's not so easy:

        http://www.argentdata.com/support/usb.html

        The T3 does theoretically have some capability for acting as a USB host,
        but it's not going to have the code space to be practical, and it can't
        really support both a host and device USB connection.

        > 2) Same question for future OT1+/OT1-USB series, or successors?

        The dual-port tracker/TNC I'm working on will have more USB host
        capabilities. Support for USB GPS receivers will still be limited by
        what I can reverse engineer without access to driver documentation.
        Anything that is supported with open source drivers (e.g., on Linux) is
        at least a candidate. I suspect that supporting two or three serial
        emulation modes will cover the majority of devices out there, but I
        can't be sure until I test a bunch of them. It will probably require
        maintaining a list of VID/PID numbers for supported devices, too.

        Supporting serial I/O on a typical micrcontroller takes a few lines of
        code to send and receive data. To support various serial-over-USB
        devices, check out how much code the Linux kernel uses:

        http://lxr.linux.no/#linux+v3.1.1/drivers/usb/serial/

        Supporting ALL of those devices would probably take more code space than
        the device will have.

        > 3) Might future OT1+/OT1-USB models accept Garmin proprietary input?

        Never for the OT1+. It just doesn't have the RAM. And it's about out
        of code space, too. The product is basically end of life - we're going
        to keep the kits in stock and make maintenance updates to the firmware,
        and maybe some minor feature additions, but I wouldn't expect any major
        updates on it.

        The OTUSB is actually part of the T2/T3 family. Digipeater and Garmin
        support *can* be compiled in, but there's no room to fit it all. I'm in
        the process of making the code even more modular, so you could more
        easily exclude other portions (scripting and weather, for example) or
        add in seldom-used modules (e.g., Nonin pulse oximeter support) so it's
        certainly possible, but I don't really want to try to support 2^n
        different firmware versions.

        It's worth noting that the OTUSB and T3 processors are pin-compatible.
        The only hardware difference that would cause a problem (so far) is the
        RS-232 transmitter polarity, and I will probably try to add a hardware
        detection feature for that. So any board designed as an OTUSB could be
        produced as a T3 variant - though at the moment that means 2-3x the
        power consumption. That may change as I get more power management code
        written, but I would expect the T3 to always have higher power requirements.

        Scott
      Your message has been successfully submitted and would be delivered to recipients shortly.