Announcement

Collapse
No announcement yet.

uLCD-70DT ACK/NACK's

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

  • uLCD-70DT ACK/NACK's

    Dear Forum,

    When I send a command to the uLCD-70DT, does the device send an ACK/NACK back to the host microcontroller?

    Please see the attached image.

    ***** I POSTED THIS ON THE SPARKFUN FORUM AS WELL, BUT THIS QUESTION MAY BE MORE 4DSYSTEMS SPECIFIC *****

    I am currently trying to connect an Arduino MEGA 2560 to a 4DSystems uLCD-70DT.

    I successfully completed this using wires (tx and rx wires), and now I want to remove the wires and replace them with XBEE PRO S3B modules. See the attached image see the BIG PICTURE of what I am trying to do.

    When I run the "wired" version of my system, I had no problems whatsoever. I essentially send commands from the MEGA2560 to the uLCD-70DT and then immediately clear the receive buffer and thus ignoring any ACK/NACK's.

    I am now using a SparkFun XBee Explorer Regulated (WRL-11373) to manage the voltage level shifting between the 5V MEGA2560, 5V uLCD-70DT, and 3.3V XBEE PRO S3B. I am running the XBEE PRO S3B in transparent mode.

    So with the "wireless" version, the first command I send from the MEGA2560 to the uLCD-70DT is a command to reduce the contrast on the uLCD-70DT. This works fine.

    The next command is to change to a different form on the uLCD-70DT. This never happens. It worked perfectly with the "wired" version, but not with the "wireless" version.

    With the (wireless) XBEE version, I am not sure if maybe the issue is with ACK/NACK's from the 4DSystems uLCD-70DT. I am thinking that maybe the uLCD-70DT is sending an ACK back to the MEGA2560 after I send commands from the MEGA2560 to the uLCD-70DT. I do the same thing in this "wireless" version that I did in the "wired" version as I clear the receive buffer as soon as I send the command from the MEGA2560 to the uLCD-70DT. My code may be clearing the receive buffer so fast that my code is actually ahead of the ACK reception and the receiver buffer is being cleared before the ACK is even recieved...if this is what is actually happening.

    I am also looking at the XBEE PRO S3B and think that another cause of my problem may be with an ACK/NACK coming from the XBEE and possibly with latency. The configuration option for disabling the ACK on the XBEE is in the TO (transmit options) configuration for the XBEE using the XCTU software. I am not sure whether or not this is the right approach.

    I have read a few posts about ACK/NACK, and I now believe that I SHOULD NOT be ignoring it. I just have to know where it is coming from....if this is even the case....????

    Any thoughts?
    Attached Files
    TIA,

    Neal

  • #2
    Hi Neal,

    We don't think you need the level shifter between the display and XBee since the display processor already outputs up to 3.3V in the UART.
    Click image for larger version

Name:	image_2019_11_20T01_55_08_294Z.png
Views:	7
Size:	69.2 KB
ID:	70366
    You could also debug the XBee(Display side) to make sure if it is really receiving/sending UART transmission properly.

    Hopefully, this helps. Please do let us know.

    Best regards,
    Sherwin
    Attached Files

    Comment

    Working...
    X