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

NSLU2 as datalogger For Lacrosse ws 3600

Expand Messages
  • Marco
    My intention is to use NSLU2 as datalogger for my Lacrosse WS 3600 weather Station. First I test a USB-Serial adapter + ws3600 on desktop system, with
    Message 1 of 6 , Feb 1, 2006
      My intention is to use NSLU2 as datalogger for my Lacrosse WS 3600
      weather Station. First I test a USB-Serial adapter + ws3600 on desktop
      system, with intention to use it later on my nslu2. With a USB-Serial
      adapter (with pl2303 chipset) the weatherstation have big problems to
      comunicate with PC (same bad result under windows with the original
      program and under debian-linux with open3600 suite). With standard PC-
      Serial interface there are no problems. Ws3600 have a very strange
      comunication protocol ( http://open3600.fast-mail.nl/tiki-
      read_article.php?articleId=1 ) so I'm not sure that adding a real
      serial interface to my Nslu2
      (http://www.rwhitby.net/nslu2/serial.html) could work. Ws 3600 require
      9600, 8, N, 1 com port settings. Can NSLU2 com port settings be
      modified?
      I've bought my nslu2 after reading about it in this group... great!

      Marco
    • Phil Endecott
      ... That is so weird it is worth sharing: RxD Not used TxD -- The meaning of this signal is not clear. Through TxD are sent U characters (hex: 55).
      Message 2 of 6 , Feb 2, 2006
        > Ws3600 have a very strange comunication protocol
        > ( http://open3600.fast-mail.nl/tiki-read_article.php?articleId=1 )
        > so I'm not sure that adding a real serial interface to my Nslu2
        > (http://www.rwhitby.net/nslu2/serial.html) could work.

        That is so weird it is worth sharing:

        RxD Not used
        TxD --> The meaning of this signal is not clear. Through TxD are sent
        "U" characters (hex: 55). (Apparently it drives the charge pump to
        generate the RS232 voltages -Phil)
        DTR --> Data output.
        RTS --> Clock.
        CTS <-- Data input.
        DSR <-- ? - we use it only in initialization procedure

        The serial port header inside the NSLU2 only has txd and rxd. The
        processor also has RTS and CTS, but I don't know if they are accessible
        anywhere on the PCB. The other modem control signals are not
        implemented; generally, in XScale designs, GPIOs are used if they are
        needed.

        I don't know how USB serial cables deal with the control signals; if
        they are controllable, it might be possible to get it to work, but I
        doubt it. It would certainly require quite a lot of work.

        Good luck!

        --Phil.
      • Marco
        ... Many thanks Phil, now I send a mail to lacrosse for investigating about USB - serial adapter compatible with my ws 3600 weather station.
        Message 3 of 6 , Feb 2, 2006
          > I don't know how USB serial cables deal with the control signals; if
          > they are controllable, it might be possible to get it to work, but I
          > doubt it. It would certainly require quite a lot of work.
          >
          > Good luck!
          >
          > --Phil.
          >

          Many thanks Phil, now I send a mail to lacrosse for investigating
          about USB - serial adapter compatible with my ws 3600 weather station.
        • John Bowler
          From: Phil Endecott ... U characters (hex: 55). (Apparently it drives the charge pump to ... Well, ok, but it s a serial connection with data in(RxD), data
          Message 4 of 6 , Feb 2, 2006
            From: Phil Endecott
            >> Ws3600 have a very strange comunication protocol
            >> ( http://open3600.fast-mail.nl/tiki-read_article.php?articleId=1 )
            >> so I'm not sure that adding a real serial interface to my Nslu2
            >> (http://www.rwhitby.net/nslu2/serial.html) could work.
            >RxD Not used
            >TxD --> The meaning of this signal is not clear. Through TxD are sent
            "U" characters (hex: 55). (Apparently it drives the charge pump to
            >generate the RS232 voltages -Phil)
            >DTR --> Data output.
            >RTS --> Clock.
            >CTS <-- Data input.
            >DSR <-- ? - we use it only in initialization procedure

            Well, ok, but it's a serial connection with data in(RxD), data out(TxD)
            a clock and a requirement for a square wave at, presumably, about 10kHz
            to power the thing.

            That's not RS232, and the plug isn't wired for RS232 (DB9 RxD is not
            connected to data input for example), but there are programmable
            serial adapters out there:

            http://people.omnigroup.com/wiml/soft/pic/keyspan.html

            However, isn't this just some other EIA/TIA definition with a different
            DB9 wiring?

            John Bowler <jbowler@...>
          • kevin_schuchmann
            ... I have a slug talking to a rainwise datalogger and it works fine, I added the serial port to the slug per the website.. you then need to change getty so it
            Message 5 of 6 , Feb 3, 2006
              > Ws 3600 require
              > 9600, 8, N, 1 com port settings. Can NSLU2 com port settings be
              > modified?
              > I've bought my nslu2 after reading about it in this group... great!
              >
              > Marco
              >

              I have a slug talking to a rainwise datalogger and it works fine, I
              added the serial port to the slug per the website.. you then need to
              change getty so it only runs once... the default is for a terminal to
              keep coming up on /dev/ttyS0
              then in my script for my logger I
              kill `ps aux | grep getty | grep -v grep | awk -F " " '{print $1}'`
              this kills the getty that started at boot time
              then
              stty -F /dev/ttyS0 -icrnl 9600
              sets up the com port to 9600

              after that I send the commands to start the rainwise logger and it
              works like a normal serial port

              kevin
            • tbering2002
              Hi, My apologies as this post is very late, however maybe this explanation helps. *** This is my theory of this interface. *** The TxD pin is being used to
              Message 6 of 6 , Apr 23, 2006
                Hi,

                My apologies as this post is very late, however maybe this
                explanation helps.

                *** This is my theory of this interface. ***

                The TxD pin is being used to wake up the recieving circuit. It is
                probably unconnected at the other end (as a data connection) and you
                could transmit at whatever baud rate you like. All the TxD pin is
                doing is establishing a signal to either power or wakeup the reciever
                on the other end.

                DTR --> Data output.
                RTS --> Clock.
                CTS <-- Data input.

                These 3 pins form a standard 3 wire SPI or SPI like serial
                interface. Documentation can be found in any microcontroller manual.
                (Try to use the manual from the microcontroller in the datalogger.)
                The Clock is used to strobe data one bit at a time. DTR and CTS are
                used to send and receive data.

                Under Windows, it is no problem to write an application to talk
                to the remote device. Use EscapeCommFunction() and write out data one
                bit at a time. Under Linux, try using ioctl() and look up the
                tty_ioctl(4) man page to toggle the DTR and RTS pins. Remember to
                disable hardware flow control first.

                One complication of using USB to serial adapters is that the
                hardware delay in the protocol can be much longer than if the hardware
                is using a I/O mapped (built-in) serial port. This may significantly
                degrade communications performance.

                My recommended solutions would be:

                a) if you want to use the built-in serial port, use a small
                Microcontroller like the PIC18 series to make a asynchronous to
                synchronous serial converter, or

                b) buy a data logger that uses a normal asynchronous serial protocol.

                From

                Tom

                --- In nslu2-linux@yahoogroups.com, Phil Endecott
                <spam_from_nslu2_linux@...> wrote:
                >
                > > Ws3600 have a very strange comunication protocol
                > > ( http://open3600.fast-mail.nl/tiki-read_article.php?articleId=1 )
                > > so I'm not sure that adding a real serial interface to my Nslu2
                > > (http://www.rwhitby.net/nslu2/serial.html) could work.
                >
                > That is so weird it is worth sharing:
                >
                > RxD Not used
                > TxD --> The meaning of this signal is not clear. Through TxD are sent
                > "U" characters (hex: 55). (Apparently it drives the charge pump to
                > generate the RS232 voltages -Phil)
                > DTR --> Data output.
                > RTS --> Clock.
                > CTS <-- Data input.
                > DSR <-- ? - we use it only in initialization procedure
                >
                > The serial port header inside the NSLU2 only has txd and rxd. The
                > processor also has RTS and CTS, but I don't know if they are accessible
                > anywhere on the PCB. The other modem control signals are not
                > implemented; generally, in XScale designs, GPIOs are used if they are
                > needed.
                >
                > I don't know how USB serial cables deal with the control signals; if
                > they are controllable, it might be possible to get it to work, but I
                > doubt it. It would certainly require quite a lot of work.
                >
                > Good luck!
                >
                > --Phil.
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.