PIC-CONTROL

NB-IoT locks are digital locks that can be authenticate and unlock itself wirelessly.

NB-IoT is a communication method similar to the data network that we are using for our mobile phone. So this means that the lock can be remotely control over the cellular data network.

NB-IoT has a lower cellular cost compare to LTE-M, LTE network.

List of NB-IoT digital locks (Dated: Mar 2020)

• DigitalKeys, https://www.digitalkeys.io/nb-iot-smart-padlock
• Kalewa, https://www.iotone.com/hardware/kalewa-nb-iot-smart-lock/h83047

Difference bewteen Bluetooth & NB-IoT locks

Lock’s Communication Technology	NB-IoT	Bluetooth
Wireless distance	35km	Within metres
Communication fee	about $1/month (10mb)	Free, unlimited
Communication hacking	Difficult	Easier
Power consumption	Higher	Lower
	Requires cellular network to work	Can work Offline
	Can opens lock remotely without a smart phone	Requires a Smart Phone with bluetooth

For more information about NB-IoT technology, click here.

<- Back to Bluetooth Resources Page

Useful coding references for nRF52840 microcontrollers

Variable Declaration

Variable
signed char,   int8_t
unsigned char, uint8_t
signed short,  int16_t
unsigned short,uint16_t
signed int,    int32_t
unsigned int,  uint32_t
signed long,    int64_t
unsigned long,  uint64_t

Useful Basic Function

nrf_delay_ms(500);                 //delay in msec
bsp_board_init(BSP_INIT_LEDS);     //initialising LED
bsp_board_led_invert(0);           //toggle LED
nrf_gpio_pin_set(LED_1); or bsp_board_led_on(0);
nrf_gpio_pin_clear(LED_1); or bsp_board_led_off(0);
LED_1 = NRF_GPIO_PIN_MAP(0,13)

UART

//UART initialisation
const app_uart_comm_params_t comm_params =
      {
          RX_PIN_NUMBER,
          TX_PIN_NUMBER,
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          UART_HWFC,
          false,
#if defined (UART_PRESENT)
          NRF_UART_BAUDRATE_115200
#else
          NRF_UARTE_BAUDRATE_115200
#endif
      };

APP_UART_FIFO_INIT(&comm_params,
                         UART_RX_BUF_SIZE,
                         UART_TX_BUF_SIZE,
                         uart_error_handle,
                         APP_IRQ_PRIORITY_LOWEST,
                         err_code);

    APP_ERROR_CHECK(err_code);

uint8_t cr;           //declare byte
app_uart_put(cr);     //send byte
app_uart_get(&cr);    //get byte
printf("\r\nUART example started.\r\n");     //print to UART

nRF5x Project Structure

All the function is written in a manner that is portable and general purpose coding. This may make it very difficult to read and understand. But basically, it works like PIC microcontroller where each pin or peripheral can be individually configure.

The entry point to the program is at “main.h” -> “int main(void)”.

Hardware specific “fixed” configuration are all done in “pca10056.h“. All pins input/output definition are configured in this file which is very specific to this designed pca10056 circuit board.

“boards.c” contains generic codes for managing the LED and Push Buttons codes.

Project (Solution) specific codes will be under the Application folder. Usually consist of “main.c” where the code starts, and “sdk_config.h” where are the configuration of the application will be.

Function that starts with sd_XXXXXX(), these are the basic functions provided directly from softdevice API module.

Function that starts with nrf_XXXXXX(), these are functions by nRF encapsulation softdevice API sd_XXXXXX().

Data type naming convention ends with XXXXXX_t

sec  - security
conn - connection
lbs  - led button service
ble  - Bluetooth low energy
params-parameters
auth - authorised
evt  - event
adv  - advertisement
lesc - LE security
len  - length
gattc_evt- GATT client event
gatts_evt- GATT server event

Peripheral useful for projects

More information of the examples project can be found at
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fexamples.html

More information about the library used in the example, refer to the SDK Library reference notes,
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_nrf5_latest.html

• Digital IO pins (project “blinky“)
• Pin Change Interrupt (project “pin_change_int“)
• UART (project “uart“, “serial“)
• Timer (project “timer“, “gpiote“)
• Pin Change Interrupt (project “pin_change_int”)
• Power Management (project “pwr_mgmt”)
• SPI (project “spi“)
• PWM (project “led_softblink“, “low_power_pwm“)
• Watch Dog Timer (project “wdt”)
• Low Energy Bluetooth BLE
• USB BLE UART
• USB HID

Pin maps for the nRF52840-DK board examples demonstration

Peripherals	Pin out in the nRF52840 example demo
LED1	P0.13
LED2	P0.14
LED3	P0.15
LED4	P0.16
SW1	P0.11
SW2	P0.12
SW3	P0.24
SW4	P0.25
UART-RX	P0.08
UART-TX	P0.06

One of the more important BLE event function

This ble_evt_handler() is callback whenever the BLE events occurs. The lower level will be called and propagated up to our application level through ble_evt_handler() where we will handle the BLE message.

For interrupt there are a total of 4 levels. Highest interrupt priority is taken by SoftDevice, the next level is by the application. Followed by a lower priority SoftDevice, then the lowest priority to the application.

How interrupts are handled by SoftDevice.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fprocessor_avail_interrupt_latency%2Fexception_mgmt_sd.html

/**@brief Function for handling BLE events.
 *
 * @param[in]   p_ble_evt   Bluetooth stack event.
 * @param[in]   p_context   Unused.
 */
static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)

The path of the incoming data event (BLE_GATTS_EVT_WRITE) start from
ble_conn_params.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context),
then followed by
ble-lbs.c->ble_lbs_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
then
main.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)

For the event object p_ble_evt, the data structure is very large. But not all data in the structure are valid. It depends on the event that had took place. Read only that section of the structure. nRF simply lump everything into this single data structure. In actual fact the data communication isn’t so large.

nRF Object Class Documentation

Application Level
---------------------------
ble_lbs_c.c
- LED Button Service modules

Middle Level
---------------------------
nrf_ble_gq.c
- GATT request queue module. Commands from application to SoftDevice are put to a queue system here

Close to SoftDevice Level
---------------------------
nrf_sdh.h

Low Level (Hardware)
---------------------------
boards.h, pca10056.h, bsp.h
- hardware board related. Board Support Package

nRF Singleton Object Instance

m_ represent singleton object.

m_ble_lbs_c
- LED Button Service object for the Central device

m_scan
- BLE scanning object

m_gatt
- GATT object

m_db_disc
- DB Discovery object

m_ble_gatt_queue
- GATT queue object

p_ represent pointer to object

//Explore Variable p_ble_evt
    //  p_ble_evt
    //      header
    //          evt_id          //type of Bluetooth events
    //          evt_len
    //      evt
    //          common_evt      //common event
    //              conn_handle
    //              params
    //                  user_mem_release
    //                  user_mem_request
    //          gap_evt         //GAP originated event
    //              conn_handle
    //              params
    //                  adv_report
    //                  adv_set_terminated
    //                  auth_key_request
    //                  auth_status                     //(ble_gap_evt_auth_status_t)
    //                      auth_status                 //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
    //                      error_src                   //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
    //                      bonded                      //< Procedure resulted in a bond.
    //                      lesc                        //*< Procedure resulted in a LE Secure Connection.
    //                      sm1_levels                  //< Levels supported in Security Mode 1.
    //                          lv1
    //                          lv2
    //                          lv3
    //                          lv4
    //                      sm2_levels                  //< Levels supported in Security Mode 2.
    //                          lv1
    //                          lv2
    //                          lv3
    //                          lv4
    //                      kdist_own                   //< Bitmap stating which keys were exchanged (distributed) by the local device. If bonding with LE Secure Connections, the enc bit will be always set.
    //                          enc
    //                          id
    //                          link
    //                          sign
    //                      kdist_peer                  //< Bitmap stating which keys were exchanged (distributed) by the remote device. If bonding with LE Secure Connections, the enc bit will never be set.
    //                          enc
    //                          id
    //                          link
    //                          sign
    //                  conn_param_update
    //                  conn_param_update_request
    //                  conn_sec_update
    //                  connected
    //                  data_length_update
    //                  data_length_update_request
    //                  disconnected
    //                  key_presed
    //                  lesc_dhkey_request
    //                  passkey_diplay
    //                  phy_update
    //                  phy_update_request
    //                  qos_channel_survey_report
    //                  rssi_changed
    //                  scan_req_report
    //                  sec_info_request
    //                  sec_params_request
    //                  sec_request
    //                  timeout
    //          gattc_evt       //GATT client
    //              conn_handle
    //              error_handle
    //              gatt_status
    //              params
    //                  attr_info_disc_rsp
    //                  char_disc_rsp
    //                  char_val_by_uuid_read_rsp
    //                  char_vals_read_rsp
    //                  desc_disc_rsp
    //                  exchange_mtu_rsp
    //                  hvx
    //                  prim_srvc_disc_rsp
    //                  read_rsp
    //                  rel_disc_rap
    //                  timeout
    //                  write_cmd_tx_complete
    //                  write_rsp
    //          gatts_evt       //GATT server
    //              conn_handle
    //              params
    //                  authorize_request
    //                  exchange_mtu_request
    //                  hvc
    //                  hvn_tx_complete
    //                  sys_attr_missing
    //                  timeout
    //                  write
    //          l2cap_evt       //L2CAP, Logical Link Control and Adaptation Layer Protocol
    //              conn_handle
    //              local_cid
    //              params
    //                  ch_sdu_buf_released
    //                  ch_setup
    //                  ch_setup_refused
    //                  ch_setup_request
    //                  credit
    //                  rx
    //                  tx

Naming convention used in nRF SDK BLE codes

....xxx_t => the "_t" defines the data object type.

scan_evt => scan event data to the main application

nrf_ble_scan => Bluetooth scanning parameters

ble_gap_evt_adv_report => Advertise Report object
ble_evt_t -> ble_gap_evt_t -> ble_gap_evt_adv_report_t

ble_gap_evt => GAP event

//Advertise Data
p_adv_report->data.p_data => Advertising data pointer
p_adv_report->data.len => Advertising data length
Example data:
03 19 00 00 02 01 06 0E |........
09 4E 6F 72 64 69 63 5F | Nordic_
42 6C 69 6E 6B 79       |Blinky

Advertise data starts (length of 22 of the whole packet)
This advertise packet consist of 3x Advertising Data (AD) elements

First byte 03 indicates the length of the first element which is 03 19 00 00.
19 is the AD type «Appearance»
00 00 is the data for Appearance which is unknown
The next set of AD element is 02 01 06.
First byte 02 indicates the length.
01 is the AD type for «Flags»
06 is the data for flags.
It indicates that BR/EDR is Not supported, and LE General Discoverable Mode is true.
The next set of AD element is 0E 09 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79
0E is the total number of data bytes which is 14.
The AD type is 09, which stands for «Complete Local Name».
The data 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79 represent "Nordic_Blinky" which is the name of the device.

The AD type code can be found on this page, 
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/

<- Back to Bluetooth Resources Page

<- Back to Bluetooth Resources Page