No announcement yet.

Calculating the delay caused by genie.writeObject

  • Filter
  • Time
  • Show
Clear All
new posts

  • Calculating the delay caused by genie.writeObject

    I am trying to look at the communication delay caused by "genie.WriteObject(GENIE_OBJ_GAUGE, 0, gaugeVal)".
    I wanna make sure I am looking at this correctly. My serial baud rate is set 115200 bps, therefore if I do 1/115200 , it will give that I have 8.68 Microseconds per bit. Then based on the information from the "Diablo16 Serial Commands Reference Manual" on page 9 the Diablo 16 used a Serial data format of 8 bits, no parity bit, and 1 stop bit. Then referring to the "ViSi-Genie Connecting a 4D Display to an Arduino Host" page 16 the Write Object sends the Command byte, has 4 parameter bytes, and then a checksum byte. With the information that 1 byte is 8 bits, we can say that we have to have 48 bits to send a Write Object command.
    With all of this information we could then say the delay for a write object would be .41667 milliseconds ( 48 bits * 8.68 Microseconds per bit) .

    Am I calculating this all correct?

  • #2
    dont calculate the delay of traffic, calculate the delay of processing as well. different objects of different sizes can take different amount of microseconds to respond with ACK on completion, you can verify that simply via a time check

    uint32_t _time = micros();
    //writeobject command

    that would tell you how long it took to process that widget, in microseconds


    • #3
      Ahhhh thank you! So just for my knowledge though, if I wanted to get the traffic delay, would my calculation be correct? I feel like it’s not because I feel like I wasn’t accounting for the stop bits in the Serial transmission.


      • #4
        ideally you can go higher baudrate provided your microcontroller has precision bus scale, on mine i run the diablo at 625,000 baudrate, but i must assure you this is only for transfer of packets, widget processing completion wont be affected

        For every byte of data transmitted, there are actually 10 bits being sent: a start bit, 8 data bits, and a stop bit. So, at 9600 bps, we’re actually sending 9600 bits per second or 960 (9600/10) bytes per second.

        so, 115200/10 == 11,520 bytes per second / 1000ms in 1s

        0.01152ms /byte x 6 bytes == 0.06912ms to transfer 6 bytes at 115200.
        you must always include the stop start parity bits


        • #5
          wait i probably got that wrong too


          • #6
            according to, it’s 0.416667ms, so you are correct yes


            • #7
              Hi maxfitz11,

              I calculated the traffic similar to what you did with few additional data.

              Needed data:
              • If set to 115200 bps serial baud rate
                • theoretically data streaming is at 1/115200 sec per bit (approx. 8.68µS per bit)
              • Serial Transmission format is N-8-1 (No Parity, 8 Data Bits, 1 Stop Bit)
                • 10 bits are sent over the serial link — 1 start bit, 8 data bits, and 1 stop bit
              • Write Object Value Message
                • has 6 bytes - (CMD,OBJ-ID, OBJ-INDEX, MSB, LSB, CHKSUM)
              • ACK/NAK
                • 1 byte

              Estimated Traffic = 8.68 µS per bit * Total number of bits

              Total number of bits = (MSG bytes + ACK/NAK byte) * 8 + Total start and stop bits
              = [ (6 + 1) * 8] + [(6 + 1) *(1 + 1) ]
              = 56 + 14
              = 70 bits
              Estimated Traffic = 8.68 µS * 70
              = 607.6 µS

              This computation is least traffic delay that you could theoretically get if the ACK/NAK is sent by the display instantaneously when the packet is received.

              Also, as tonton81 said, you can go to higher baud rate to reduce delay. The highest baud rate that you could use is 625000. (Refer to DIABLO16 PROCESSOR - Internal Functions Reference Manual)

              Each Baud Rate corresponds to different Baud Rate Error which will affect the data transmission.