Changes between Version 28 and Version 29 of Software/Gateway


Ignore:
Timestamp:
11/26/10 11:20:13 (13 years ago)
Author:
art
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Software/Gateway

    v28 v29  
    168168 
    169169Afterwards an update of the firmware can be initiated by the following protocol: 
    170   * send '''InitFirmwareUpdate''': ''src='f' '', ''dst='i' '' - which will cause server to initiate firmware update. The message must contain in the priority field the 32bit password which is specific to the flashed unit and the firmware.  
    171   * receive '''InitFirmwareUpdate''' - wait for max 3sec. until server response with this message indicating that firmware can be now uploaded.  
    172   * send '''UploadFirmware''': ''src='f' '', ''dst='u' '' - here the len:lenx is a 16bit number indicating the length in bytes of the data (i.e. firmware) following in the data part of the message. The priority field must contain the checksum (16 bit) delivered with the firmware data. And finally both last reserved bytes in the header must contain the firmware version we are uploading. The data field of this message must contain the full firmware data which will be directly uploaded to the unit. 
    173   * receive '''UploadFirmware''' - server responses with this message every time when next chunk of bytes has been uploaded to the device.  
     170  * send '''!InitFirmwareUpdate''': ''src='f' '', ''dst='i' '' - which will cause server to initiate firmware update. The message must contain in the priority field the 32bit password which is specific to the flashed unit and the firmware.  
     171  * receive '''!InitFirmwareUpdate''' - wait for max 3sec. until server response with this message indicating that firmware can be now uploaded.  
     172  * send '''!UploadFirmware''': ''src='f' '', ''dst='u' '' - here the len:lenx is a 16bit number indicating the length in bytes of the data (i.e. firmware) following in the data part of the message. The priority field must contain the checksum (16 bit) delivered with the firmware data. And finally both last reserved bytes in the header must contain the firmware version we are uploading. The data field of this message must contain the full firmware data which will be directly uploaded to the unit. 
     173  * receive '''!UploadFirmware''' - server responses with this message every time when next chunk of bytes has been uploaded to the device.  
    174174     * Client application can use the response in order to indicate how much of the data has been already uploaded.  
    175175     * The len:lenx field contains number of bytes already uploaded to the device.