Announcement

Collapse
No announcement yet.

Winbutton Pushes not Being Received/Transmitted

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Winbutton Pushes not Being Received/Transmitted

    Dear Forum,

    I am currently using a uLCD-70DT with an Arduino MEGA 2560 and xBEE Pro S3B. I designed my project in Visi-Genie. I basically press Winbuttons, move sliders, and keypad entry on the uLCD-70DT and report message, transmit the message wirelessly to the Arduino MEGA 2560 via xBee, and then decide what to do based upon the 6 bytes received by the serial port on the MEGA 2560.

    I have used the Workshop IDE GTX tool to determine the 6 bytes that are transmitted from the uLCD-70DT(Serial1 on Arduino) to my Arduino. I wrote about 50 lines of code in C with switch/case statements to determine whether it is a button press, slider movement, keypad input, etc. All of this seems to work quite well with one exception.

    Some of the button presses and slider movements are changed on the uLCD-70DT, but they do not always get transmitted to the Arduino MEGA 2560. I know this because I use the serial monitor in the Arduino IDE to output all received bytes, and sometimes no bytes show even when I press a Winbutton or move a slider, etc. Sometimes I have to press a button 2-3 times to see the received bytes on the serial monitor. I am 100% sure that the xBEE radios are working properly as I set these up with tech support from Digi International.

    I have already recalibrated the uLCD. I have also tried sending each command 3 times to ensure that the bytes are sent, but I do not check to see if the bytes are received. This may be my problem. In other words, I do not check to see if I have received and ACK or NACK, but the uLCD-70DT does send them back to the Arduino MEGA 2650. It took me a while to see that the first 3 bytes ight be 06,06,06 and the next 3 bytes might be 07,06,01. I finally realized that the uLCD-70DT was sending some bytes back to the Arduino MEGA 2560, and these bytes were being received on Serial1 I believe that an ACK or NACK is returned with every single byte sent. So essentially flush the Serial1 port after every time I get an ACK or NACK.

    How SHOULD I handle this?


    Any thoughts?


    ONE MORE THING. I also use another serial port on the Arduino MEGA 2560 to receive GPS data(Serial2 on Arduino). As I receive the data, I parse it, convert it to decimal degrees latitude and longitude, and then transmit these values to the uLCD-70DT. This created a problem because some of bytes transmitted ACK and some transmitted NACK. These values started to fill the receive buffer and they started to conflict with the values that I was receiving from button presses.

    What a mess!!! Thoughts?

    You will probably say that I should use the 4DSystems library. I recently read, "If you download some code and understand it, then use it. If you don't understand it, then do not use it." So this is why I wrote my pretty simple code.

    TIA,
    --Neal
    TIA,

    Neal

  • #2
    Hi Neal,

    Can you check if you are seeing the correct message when using the GTX Tool? If yes, then there might be some problem when you are trying to receive the data from the display to the Arduino. Can you share the code you use when you receive the data from the display? I will run some tests.

    You need to handle both receiving and sending of data to the display. The library helps you process this in the background. It also minimizes the apparent delay during transfers.

    Best Regards,
    Kevin

    Comment


    • #3
      So I took a more detailed look at what I am receiving on the host microcontroller (Arduino MEGA 2560) from the uLCD-70DT after I send my write string command.

      In the GTX tool, I explicitly sent "+26.16187" to the uLCD-70DT and this is how the uLCD-70DT responded. Also see the attached MS Word document.

      Set String Text Value 17:15:15.466 [02 00 0D 32 30 31 30 2B 32 36 2E 31 36 31 38 37 34]
      ACK 17:15:15.528 [06]
      2010+26.16187

      So I wrote a function in C to write strings (Refer to 3.1.3.3 Write String (ASCII) Message) like updateCoordinates(byte CMD, byte ID, byte STRLENGTH, array of bytes of string, byte CHECKSUM).

      When I explicitly send the data in the GTX tool, the GTX tool sends the following to the serial monitor in the GTX tool:

      CMD 0x02
      ID 0x00
      0x0D stringlength 10 which is the stringlength of "+26.16187" plus the null character plus the 3 extra preceding bytes 02 00 0D
      ...then almost like a repeat of the same commands
      0x30 plus CMD 0x02
      0x30 plus ID 0x00
      stringlength of 10 (0x30 + 0x01 and 0x30 + 0x00) which is the stringlength of "+26.16187" plus the null character
      beginning of string....the PLUS sign 0x2B
      2
      6
      the period 0x2E
      1
      6
      1
      8
      7...end of string
      checksum

      I do not know why the GTX tool appends 0x30 to the beginning of all numerical values, not the "+" and "." and not on the 3 preceding bytes.

      So with all of this occurring, I cannot seem to get the proper checksum value. The function that I wrote only sends CMD, ID, STRINGLENGTH, STRING, and CHECKSUM bytes, NOT this weird combination of 17 bytes.

      I tailored my function to produce the exact same XOR checksum and this still produced all kinds of NACK's from the uLCD.

      Any explanation of this anomaly would be much appreciated.

      See the screenshot in the attached MS Word document

      I tried sending both "+26.16187" and "26.16187\0"

      Also, can I turn off the ACK and NACK on the uLCD?

      TIA,

      --Neal
      Attached Files
      TIA,

      Neal

      Comment


      • #4
        Hi Neal,

        Looking at the document you attached it seems that when you are sending a string from the GTX Tool, you are receiving a correct response from the display.

        Without providing your C function to write strings, I cannot really tell how/why it is behaving that way.

        0x0D stringlength 10 which is the stringlength of "+26.16187"
        Also, '0x0D' is 13 in decimal. The '+26.16187' has a length of 9 bytes. The '0x0D' comes from you writing 13 bytes which are - '2010+26.16187'.

        After sending a string command, the display will reply with a single byte (ACK/NACK).

        Also, can I turn off the ACK and NACK on the uLCD?
        You can't. The ACK/NACK is the reply of the display when a command is issued by the host. It is important to wait for the ACK before sending another command to avoid any issues.

        Best Regards,
        Kevin

        Comment

        Working...
        X