## @file  Eddystone_Beacon_TLM.py
##
## <!-- Copyright 2016 by NAVIA.  All rights reserved. -->
##

# Reset BlueNRG/BlueNRG-MS 
RESET()
# Set Public Address
SET_PUBLIC_ADDRESS(0x123456789AAA)
# Init GATT 
if  ACI_GATT_INIT()!=0x00:
    ERROR('ACI_GATT_INIT FAILED')

# Init GAP as peripheral device
status,_,_,_=  ACI_GAP_INIT(Role=PERIPHERAL)
if status !=0x00:
    ERROR('ACI_GAP_INIT CALL FAILED')

#Set TX power level
ACI_HAL_SET_TX_POWER_LEVEL(En_High_Power=1,PA_Level = 4) 

# Put device in non-connectable mode
status = ACI_GAP_SET_DISCOVERABLE(Advertising_Type=0x03, Advertising_Interval_Min=160, Advertising_Interval_Max=160, Local_Name_Length = 0x0, Local_Name = 0x0)
if status !=0x00:
    ERROR('ACI_GAP_SET_DISCOVERABLE CALL FAILED')

#Remove this AD type otherwise  beaconPayload exceed the maximum size
status = ACI_GAP_DELETE_AD_TYPE (ADType=0x0A)
if status !=0x00:
    ERROR('ACI_GAP_DELETE_AD_TYPE CALL FAILED')

#Eddystone-TLM
#Eddystone beacons may transmit data about their own operation to clients. This data is called telemetry and is useful for monitoring the health and operation of a fleet of beacons. Since the Eddystone-TLM frame does not contain a beacon ID, it must be paired with an identifying frame which provides the ID, either of type Eddystone-UID or Eddystone-URL. See Interleaving Telemetry for details.
#Like the Eddystone-UID and Eddystone-URL frame types, Eddystone-TLM is broadcast in the clear, without message integrity validation. You should design your application to be tolerant of the open nature of such a broadcast.
#Frame Specification
#The TLM frame is encoded in the advertisement as a Service Data block associated with the Eddystone service UUID. The layout is:

	
# Define the beacon payload to be used within the advertising data
beaconPayload = [
	0xAA, 0xfE,					# 16-bit Eddystone UUID
	0x20,						# Frame Type	Value = 0x20
	0x00,						# Version	TLM version, value = 0x00
	0xCE,						# VBATT[0]	Battery voltage, 1 mV/bit  
	0x04,						# VBATT[1]	3.3 V
	0x00,						# TEMP[0]	Beacon temperature
	0x12,						# TEMP[1]	18.00 C
	0x01,						# ADV_CNT[0]	Advertising PDU count
	0x00,						# ADV_CNT[1]	
	0x00,						# ADV_CNT[2]	
	0x01,						# ADV_CNT[3]	
	0x00,						# SEC_CNT[0]	Time since power-on or reboot
	0x00,						# SEC_CNT[1]	
	0x00,						# SEC_CNT[2]	
	0x00						# SEC_CNT[3]	
    ]	

#All multi-byte values are big-endian.

#	8.8   notation  is a 16 bit  fixed   notation , so:
#	0xFF11 is the number 255.17
#	0x0104 is the number 1.4
#	0x2356 is the number 35.86

#Field Notes
#	The length of this frame is fixed and must be truncated after the "time since power-on" bytes. The value of the Service Data Length byte must be 0x11.
#	TLM version allows for future development of this frame type. At present the value must be 0x00.
#	Battery voltage is the current battery charge in millivolts, expressed as 1 mV per bit. If not supported (for example in a USB-powered beacon) the value should be zeroed.
#	Beacon temperature is the temperature in degrees Celsius sensed by the beacon and expressed in a signed 8.8 fixed-point notation. If not supported the value should be set to 0x8000, -128 C.
#	ADV_CNT is the running count of advertisement frames of all types emitted by the beacon since power-up or reboot, useful for monitoring performance metrics that scale per broadcast frame. If this value is reset (e.g. on reboot), the current time field must also be reset.
#	SEC_CNT is a 0.1 second resolution counter that represents time since beacon power-up or reboot. If this value is reset (e.g. on a reboot), the ADV count field must also be reset.
#Interleaving Telemetry
#Telemetry frames should be interleaved with an identifying frame type (e.g. Eddystone-UID or Eddystone-URL). 
#The TLM frame depends on the client to associate it with the identifying frames via the device address (since no beacon ID exists in the TLM frame). 
#Thus it is important that a beacon that rotates or randomizes its device address uses the same device address for some period that allows for multiple ID frames and multiple TLM frames to be broadcast from the same device address.
#You may decide to interleave one TLM frame for each ID frame, or use some lower ratio depending on how critical the TLM data is for your application. 
#For example, if your application is using the TLM for fleet management, it may be satisfied receiving one TLM frame per day, so your beacons deployed in a high traffic area may broadcast TLM only once per minute or longer, 
#giving a high probability that a client receives the TLM frame and transmits it to your service once per day. In a low-traffic environment such an application may require a higher TLM rate.
#Finally, if your application uses TLM to (e.g.) supply up-to-the-minute runtime status information to an end user, you may wish to interleave TLM with ID frames 1 to 1.	

lenData= len(beaconPayload)+1

        
#AD type 0xFF = Manufacturer Specific Data ->  2 or more octets
#Description = The first 2 octets contain the company Identifier Code followed by additional manufactures specific data 
#data = [lenData , 0x16 ] + beaconPayload
#data = [lenData] + beaconPayload
data = [lenData , 0x16 ] + beaconPayload

# Update advertising data 
status = ACI_GAP_UPDATE_ADV_DATA( AdvDataLen=len(data), AdvData= data)
if status !=0x00:
    ERROR('ACI_GAP_UPDATE_ADV_DATA CALL FAILED')
## @endcond






