Protocol 7.00 Screenstreaming communication flows¶

Screenstreaming with Protocol 7.00 involves a sender and a receiver. The objective with this protocol is for the sender to be able to send frames as they are produced to the receiver.

Except for a conditional acknowledgement at the beginning of the flow, the receiver does not send anything, and in case of invalid checksum, it discards such packets.

The communication schema is the following:

        sequenceDiagram
    Participant sender as Sender<br />(Calculator)
    Participant receiver as Receiver<br />(PC, ...)

    Note over sender,receiver: Initialize the link

    alt Sender requires acknowledgement from the Receiver
        sender->>receiver: Check packet
        receiver->>sender: Acknowledgement packet
    end

    loop Screenstreaming is active
        sender->>receiver: Frame packet
    end

Warning

Sometimes, due to the high volume of data, a few bytes can be skipped here and there, leading to a desynchronization on the input stream. It is recommended, on the receiving function, to add an option to find the beginning of the next screenstreaming packet, to fix such desynchronized inputs.

Initialize the link¶

There is no specific initialization within the application protocol.

However, when used over USB links, some devices may freeze up until the receiver / host runs a special USB control flow; see Device enabling control flow for more information.

Acknowledge a Sender¶

On certain conditions, such as when the ScreenRecv(XP) mode is used on the fx-CG50, the sender requires acknowledgement from the receiver. As such, it will continuously send check packets, such as the following one:

16 43 41 4c 30 30 44 30  .CAL00D0

In such cases, the receiver must answer with the following acknowledgement packet:

06 30 32 30 30 31 30 44  .020010D

Once the sender has received acknowledgement, it will start sending frame packets.

For more information, see 0x16 – Check packet and 0x06 – Acknowledgement packet.