Announcement

Collapse
No announcement yet.

Visi genie communication protocol

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

  • Visi genie communication protocol

    Hi,

    We have an application where we send data from a microcontroller to the screen every 100ms. We wrote our own library and we wrote it in such a way we do not wait for ACK from a command before allowing to send the next command. This seemed to work in most cases but occasionally we start receiving NAKs from the screen and once that happen we get NAKs for every command we send. This problem was particularly evident once we tried to send data to a scope. Are we sending too much data? I have seen videos where the screen seems to be able to handle much more data than what we are trying to display, is it because we are using the visi genie environment?

    Thanks!

  • #2
    Sending data without waiting for the ACK will be fraught with issues such as this.

    You can bank commands up to the display until its serial buffer is full, once it is, all hell will break loose and you will start getting all sorts of unexpected results.

    So the simplest and easiest thing to do is wait for the ACK.

    Commands won't really go any faster if you don't wait for the ACK.

    You could 'enhance' things a bit by sending the command, but not wait for the ACK until you are ready to send the next command. Of course this assumed that all you are waiting for is the ACK and not some important response.

    You could potentially go even further and track the fullness of the buffer in the display and only hold up commands when the buffer is near full. But this seems pointless as the display could be a long way out of sync with the host which would only lead to confusion.
    Mark

    Comment


    • #3
      How are you guys able to display the spectrum like the one 40" in this video

      https://www.youtube.com/watch?v=9eAmGiVLNw4

      there are 22 columns in the spectrum, it looks like they all change at the same time so that must be 22 commands one right after the other I cannot see any lag.

      What is the size of the buffer on the display side?

      Comment


      • #4
        Hi,

        That project was made using ViSi-Genie-Arduino-Library that performs proper handling of ACK. The display will be able to perform best when handling the protocol that it is designed to use.

        I wrote a sample Arduino code similar to that one. You can find it as an attachment here: spectrum.zip

        Also, have you looked at this: http://forum.4dsystems.com.au/forum/...ectrum-arduino ?

        This might also help you. This one uses Magic feature.

        Regards,


        Juniel
        Juniel Cruz

        Comment


        • #5
          Hi Juniel,

          We basically re-wrote the arduino library for our platform in C. We do not see any error handling or ACK handling like you mentioned in the code. If you look at the Genie::WriteObject method we do not see any special things to handle NAK from previous write commands. This is what appears to happen:

          WriteObject method -> Waits for display to be idle -> which basically means all the events from display are handled before a write operation -> return to wait for idle -> write object function is executed. None of the errors are handled in the library including a NAK.

          What do you mean by proper handling of ACK?

          Please let us know what we are missing.

          Thanks.

          Comment


          • #6
            Hi,

            Have you checked the DoEvents function?

            It is getting a byte from the Serial port. If a byte is received, the function continues and check what is the current state of the link.

            If the link is currently waiting for an ACK or a NAK, and it got one of those, it will simply toggle the state. Furthermore, if what the function got is a NAK, an error handling function is called. However the library uses that function only as a debugging aid but it can be further enhanced to help recover from errors if you want.

            Best Regards,

            Juniel
            Juniel Cruz

            Comment


            • #7
              We found the bug. Thanks.
              Last edited by r2r; 23 August 2016, 12:21 AM.

              Comment


              • #8
                If the display really cannot handle it's own buffer limits then it is at least essential to define the maximum latency between command and ACK/NACK to be able to setup a proper timeout to not have a infinite loop waiting for a response if the display didn't receive one of the bytes. So could you tell us please after what delay the communication will be reset if the display did receive a partial command?

                Comment


                • #9
                  Interesting first post, can you elaborate on just what you are trying to say?
                  Mark

                  Comment

                  Working...
                  X