Internal Knowlege Base

LM93x Programming, Trimming & Testing

During manufacturing the LM931 is programmed and tested using the CSREnder tool, a LM931 jig with the CSR USB-SPI uEnergy adapter and the CSR Reference Endpoint. For now, refer to the CSREnder tool readme in the Bitbucket Git repository for more information. Currently the msvc branch is under development, not the master branch.

Product Hardware Specification – LM951

Goals

The following are the primary goals of the LM951 product hardware design, in order of priority. It’s expected that these will be weighed-up based upon their designated priority and a reasonable balance achieved.

  1. Product must be as small as possible
  2. Product must not sacrifice RF performance
  3. Product must be of sensible layout
  4. Product must be cost-effective
  5. Product must pin-out as much IO from the IC as possible

Specification

Important Documents

  • The design shall follow, where reasonable, the guidelines provided by LM in the document
    3. Reference & Investigations\PCB Design Guidelines for contractors-v18-20150511_1614.pdf
  • The design shall use the template Altium project and stack-up located in
    6. SCH & PCB\PCB0012 CSRB5342 LM951 CHIP ANTENNA.PrjPcb
  • The design shall follow closely the reference provided by CSR in the document
    3. Reference & Investigations\CS-322155-DD-1 CSRB5342 BGA reference design module.pdf
  • The prelim example design document
    3. Reference & Investigations\CS-322707-AN-1 CSRB534x BGA prelim example design.docx‘ and example gerber layout
    3. Reference & Investigations\R13342v2_GERBER Hawkeye BGA example design v2.zip‘ provided by CSR should be considered for advice on likely challenges and good design practises

Changes from Reference

  • The design shall use the SST26WF080BT-104I/NP Quad-SPI USON Flash IC for U3 instead of the reference design, with appropriate adjustments to the application schematic
  • The design shall use IC antenna AT3216-B2R7HAATLF, instead of the reference PCB antenna, with appropriate adjustments to the application schematic
  • The design does not require dedicated test points
  • The design does not require PIO 12 to 30 (except PIO 25, 26 and 27) or AIO 4 to 25, these may be removed from the design to reduce size to meet the design goals
  • Battery charge related and USB IO towards far end of the board (away from antenna)

PCB Specification

  • Number of Layers: 4 (6 may be considered by first feeding back to LM project manager)
  • PCB Thickness: 1.6mm

 

CSR uEnergy Starter Devleopment Kit + LM931 Bluetooth 4.1 SMART (BLE) Module (NDA only)

Introduction

In order to provide early access for its new LM931 Bluetooth 4.1 SMART Module, LM has developed a daughter-board adapter for the CSR uEnergy Starter Development Kit (uEnergy DK) and pre-soldered the LM931 to the Development Kit. At a later date we will launch an Arduino compatible developer board designed specifically for the LM931.

This document describes how to:

  • Use the uEnergy DK hardware
  • Download and run the CSR uEnergy SDK
  • Load a sample application onto the module

Hardware

The uEnergy DK has been provided with the LM931 pre-soldered and jumpers pre-configured. Please see the image below for the reference setup.

LM931_CSR_DEV_800x800

I/O Pinout

The LM931 I/O is exposed on headers J101 and J102. I/O assignments are as depicted below.

image2015-6-10 16-25-9

Plugging in the dev board

Simply attach the micro USB to your PC or Laptop after installing CSR’s SDK (see below). When you run an application from uEnergy studio it will automatically detect and use the device. If it can not find the dev board check device manager for the CSR USB<>SPI Converter under USB Serial Bus Controllers.

image2015-7-15 9-5-27

Software

The LM931 is programmed using CSR’s uEnergy SDK, please obtain and install the latest version with default settings from the following link: https://drive.google.com/file/d/0B256wTxVOD-DcDMxbldjUzZ3Nnc/view?usp=sharing

The uEnergy SDK provides a full IDE environment and C API for programming and debugging the LM931, offering incredible power and flexibility, however, at the same time this can be daunting for new users. To help ease the process, CSR provide 34 sample application projects within the InstallLocation\apps folder, many of which implement the standard BLE SIG profiles. Documentation for these sample applications, general use and technical details can be found at InstallLocation\doc\support\index.html (Or click Help->Home in the IDE). Comprehensive C API Documentation is located at InstallLocation\doc\reference\index.html. These can also be accessed from within the uEnergy SDK IDE.

We STRONGLY recommend reviewing the documentation at InstallLocation\doc\support\index.html, which should also have been installed as a shortcut on the desktop, to get the most out of the development kit software.

Compiling and Debugging a Sample Application

  1. Open CSR µEnergy SDK 2.4.5.13 (xIDE).exe
  2. Navigate to Project->Open Workspace… within the top menu

image2015-6-10 13-49-54

3. Navigate to and open the sample project C:\CSR_uEnergy_SDK-2.4.5.13\apps\weight_scale\weight_scale.xiw

image2015-6-10 13-53-5

4. From the Navigator bar on the left, open file weight_scale_csr101x_A05.keyr, locate the line // (0002) – Crystal frequency trim and modify the trim frequency to the number provided in the e-mail that accompanied this document

NOTE:The .keyr files contain read-only configuration options and default values that are embedded within the application. Every individual adapter has a unique Crystal frequency trim value; normally LM inserts this when the customer application is loaded (flashed) during manufacturing, however, when using the LM931 for development, the trim value is overridden each time a new application is loaded and so it’s important to ensure the value in the application matches the individual module’s value, which should have been provided by LM over e-mail.

image2015-6-11 15-40-4

5. If you also wish to use maximum available TX power, please also add &TX_POWER_LEVEL = 7, as depicted below

image2015-6-11 15-41-49

6. Press F7 to build the active project or navigate to Build->Build Active Project within the top menu

NOTE: The weight_scale project is already configured correctly for the LM931 and includes support for over-the-air updates as well. These project settings may be used as a helpful reference later-on.

Three images will have been generated in the folder C:\CSR_uEnergy_SDK-2.4.5.13\apps\weight_scale\depend_Release_CSR101x_A05:
a. bootloader.img – Bootloader only (no default application – application must be loaded over-the-air)
b. weight_scale.img – Bootloader + Application image (this is the full image that will be flashed to the device)
c. weight_scale_update.img – Application image (this is the application-only image that is used when loading the application over-the-air)

7. To download the image to EEPROM and debug, either press F5 or navigate to Debug->Run within the top menu, with the hardware connected over USB.

You will have access to an array of standard debugging capabilities, including:

  • Code and data break points
  • Pause/play/stop/restart
  • Disassembly view
  • Register view
  • Memory view
  • Variable watch view
  • Callstack view
  • variable/static/const views

Additionally, it’s possible to send debug information over the UART to a UART-to-USB converter and view trace information from a Serial Terminal

8. The above process can be approximately repeated for any of the other sample applications. Please be aware not all applications include support for over-the-air updates, documentation to add this is provided, however. For your own application, you can either copy and modify an existing project or start a new project, using the example applications, help and API documentation to assist.

 

Crystal Trim Values – LM931

  1. 13 (-1.5dBm best, -5.79dBm aligned)
  2. 6 (-2.5dBm best, -7dBm aligned)
  3. f
  4. 5 (-1.5dBm best, -9dBm aligned)
  5. f

 

RF Certification – LM910

Many countries require products to be RF certified, as a module, the LM910-0630 may require additional certifications beyond those provided by LM Technologies, this may be the case for the following reasons:

  • LM Technologies does not currently hold a certification for its module/adapter in the specified country and that country does not recognise any of the existing certifications.
  • Please see LM Product Certifications for a list of all current certifications that LM Technologies holds for its modules and adapters.
  • Some countries do not support module-level certifications, in this case, full product certification must be performed.
  • The LM910-0630 has no metal RF shield. In this case certification standards such as FCC only support certification as an entire product or ‘Limited Certification’ where the module must be demonstrated to work in a sub-set of specified products.

To perform certifications, depending on the type of testing performed and the capabilities of the test hardware, the LM910-0630 can be placed into various test modes to aid in this process.

Device Under Test (DUT) Mode

Device Under Test Mode allows a Bluetooth-aware test unit to issue synchronised test commands remotely over a wireless link. This test mode is useful for Bluetooth SIG compliance testing and other RF testing where hardware capable of issuing Bluetooth DUT commands wirelessly.

To place the device into DUT mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable device discovery:

Opcode: 0xC1A Length: 0x01 Parameters: 0x03 (Write_Scan_Enable: Inquiry and Page Scan Enabled)

5/ Issue the following HCI command to enable device role-switching:

Opcode: 0xC05 Length: 0x03 Parameters: 0x02 0x00 0x03 (Set_Event_Filter: (Filter_Type: Connection Setup (Connection_Setup_Filter_Condition_Type: Allow Connections from all devices, Auto_Accept_Flag: Do Auto accept the connection with role switch enabled))

6/ Issue the following HCI command to enter Device Under Test (DUT) Mode:

Opcode: 0x1803 Length: 0x00 (Enable_Device_Under_Test_Mode)

TX Test Mode

TX Test Mode allows the device to transmit fixed or pseudo-random packets on either a single-frequency, fixed-pattern or 79-channel Bluetooth frequency-hopping mode.

To place the device into TX Test mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable TX Test mode:

Opcode: 0xFC51 Length: 0x10 Parameters:
 
Local_Device_BD_ADDR: 0x00 0x02 0x72 0xC9 0x14 0x9D (Example Local Device Bluetooth Address)
 
Hopping_Mode: 0x00 (79 Channel) / 0x01 (Single Frequency) / 0x02 (Fixed Pattern)
 
(IF Hopping_Mode == 0x01) Frequency: 0x00 to 0x4E (Channel 1 2402MHz to 79 2480MHz)
 
Modulation_Type: 0x00 (0x00 8-bit pattern) / 0x01 (0xFF 8-bit pattern) / 0x02 (0xAA 8-bit pattern) / 0x03 (0xF0 8-bit pattern) / 0x04 (PRBS9 pattern)
 
Logical_Channel: 0x00 (ACL EDR) / 0x01 (ACL Basic) / 0x02 (eSCO EDR) / 0x03 (eSCO Basic) / 0x04 (SCO Basic)
 
BB_Packet_Type: 0x00 (NULL) / 0x01 (POLL) / 0x02 (FHS) / 0x03 (DM1) / 0X04 (DH1/2-DH1) / 0X05 (HV1) / 0X06 (HV2/2-EV3) / 0X07 (HV3/EV3/3-EV3) / 0X08 (AUX1/PS) / 0X09 (DM3/2-DH3) / 0X0A (EV4/2-EV5) / 0X0B (EV5/3-EV5) / 0X0C (DM5 / 2-DH5) / 0X0D (DH5/3-DH5)
 
BB_Packet_Length: 0x00 (Any Length up to allowed Packet Type Length)
 
Tx_Power_Level: 0x00 (0dBm) / 0x01 (-4dBm) / 0x02 (-8dBm) / 0x03 (-12dBm) / 0x04 (-16dBm) / 0x05 (-20dBm) / 0x06 (-24dBm) / 0x07 (-28dBm) / 0x09 (Specify Power Table Index - Use this for 10dBm)
 
(IF Tx_Power_Level == 0x09) Transmit_Power_Table_Index: 0x00 (10dBm)

RX Test Mode

RX Test Mode allows the device to receive only fixed or pseudo-random packets on either a single-frequency or a fixed-pattern.

To place the device into RX Test mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable RX Test mode:

Opcode: 0xFC52 Length: 0x0E Parameters:
 
Remote_Device_BD_ADDR: 0x00 0x02 0x72 0xC9 0x14 0x9D (Example Remote Device Bluetooth Address)
 
Report_Period: 0xFA to 0x7D0 (Report Period in Milliseconds from 250ms to 2000ms)
 
Frequency: 0x00 to 0x4E or 0xF0 (Channel 1 2402MHz to 79 2480MHz or Fixed Pattern)
 
Modulation_Type: 0x00 (0x00 8-bit pattern) / 0x01 (0xFF 8-bit pattern) / 0x02 (0xAA 8-bit pattern) / 0x03 (0xF0 8-bit pattern) / 0x04 (PRBS9 pattern)
 
Logical_Channel: 0x00 (ACL EDR) / 0x01 (ACL Basic) / 0x02 (eSCO EDR) / 0x03 (eSCO Basic) / 0x04 (SCO Basic)
 
BB_Packet_Type: 0x00 (NULL) / 0x01 (POLL) / 0x02 (FHS) / 0x03 (DM1) / 0X04 (DH1/2-DH1) / 0X05 (HV1) / 0X06 (HV2/2-EV3) / 0X07 (HV3/EV3/3-EV3) / 0X08 (AUX1/PS) / 0X09 (DM3/2-DH3) / 0X0A (EV4/2-EV5) / 0X0B (EV5/3-EV5) / 0X0C (DM5 / 2-DH5) / 0X0D (DH5/3-DH5)
 
BB_Packet_Length: 0x00 (Any Length up to allowed Packet Type Length)

 

Firmware Patch Guide – LM910

The LM910-0630 features at its core a Broadcom BCM20702 Bluetooth 4.0 HCI USB IC.

The BCM20702 is shipped from the factory with a generic firmware that will allow for communication between the IC and the host via HCI commands, however, this firmware does not include design-specific RF optimisations, the latest bug fixes or additional functionality. It’s therefore important for the sake of RF testing and production that the host load onto the module a ‘PatchRAM’ firmware file.

  • It’s important to note that this patch is applied in volatile RAM memory and as such, must be re-applied each time the device is power-cycled. Needless to say the below routine should be integrated into the host solution that is to be deployed on the end-product.

This guide assumes that the user knows how and has the capability to issue a HCI command and to read a HCI event on their platform.

Overview

  • Open HCI command socket over USB or otherwise.
  • Issue the HCI reset command (OGF 0x03, OCF 0x003 or 0x0C03 together), wait for the command complete event and check that the return status code is zero.
  • Issue the vendor specific HCI command ‘Download_Minidriver’ (OGF 0x3F, OCF 0x02E or 0xFC2E together) and wait for the command complete event.
  • Wait for 50ms for the device to enter Download Mode.
  • Parse each HCI command from the HCD firmware file and send it over the HCI command socket, checking that each command is run successfully.
  • Wait 250ms for flashing to complete.

Issuing commands & command complete event

In all cases, the user should wait for the corresponding Command_Complete event when issuing a command and check the command’s return status parameter for errors.

On some platforms, there may be a convenience function which waits for the Command_Complete event, as a wait is often required with most HCI commands.

HCD file format

The HCD file consists of a set of HCI commands in the following format:

OpcodeUnsigned 16-bit integer in little endian byte orderBluetooth HCI command identifier
Parameter lengthUnsigned 8-bit integerLength of the parameter data for this command in bytes
Parameter dataByte arrayZero or more bytes as specified by parameter length

All the data is tightly packed, so each field begins directly after another as does each command.

HCD file

For the A0 revision

BCM20702A0-0a5c-21e8.hcd

For the B0 revision:

BCM20702B0-0a5c-22be.hcd (named LM_BCM20702B0_002.001.014.0592.0899_Generic_USB_Class1_20MHz.hcd in LM’s vendor’s folder)

References

BlueZ; the Bluetooth stack used by the Linux kernel contains a working example of the patchram procedure:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/btusb.c

There is also a patch ram utility for Linux/Android which can be found at the following link:
https://code.google.com/p/broadcom-bluetooth/source/browse/

 

Reflow – LM910

The LM910-0630 module is produced using standard-temperature lead-free solder. For this reason we recommend the use of a low-temperature solder (< ~217°C) to avoid causing a second reflow of the module components, increasing the likelihood of a higher yield.

We understand that some applications and manufacturer limitations prevent the use of a low-temperature solder, in this instance, please follow the below guidelines to form your own custom reflow profile:

Reference Reflow Profile (standard-temperature lead-free)

LM506_0518_reference_temperature_reflow_chart

  • If the host PCBA is double-sided and passes through reflow twice, reflow the module on the final pass only.
  • Do not exceed a reflow temperature of 250°C and refer to your solder paste vendor’s guidelines.
  • Temperature Ramp-up and Ramp-down times should be within the range of 1 to 4°C/s, attempt to not exceed 3°C/s.
  • This chart is for reference only, results will vary from manufacturer to manufacturer and machine to machine.

Customising the Reference Reflow Profile

The reflow profile shown in the above section is for reference only. It is expected that refinements and customisations to this profile will be needed during trial sampling to achieve an acceptable yield.

Moisture Sensitivity and Pre-Baking

The LM910-0630 is rated at moisture sensitivity level 3 (MSL-3). It is recommended to pre-bake the module before SMT placement.

Please see the following IPC/JEDEC J-STD-033B.1 guidelines, which offer recommended bake times dependant on the time the module packaging has been unsealed for and the baking temperature that will be applied:

Bake @ 125°CBake @ 90°CBake @ 40°C
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
9 hours7 hours33 hours23 hours13 days9 days

 

SMD/SMT Placement – LM910

The LM910-0630 is a single-sided USB module suitable for SMT/SMD placement, based around the design of the LM506 USB Nano Adapter.

Our customers often appreciate the simplistic development pipeline of moving from the LM506 Adapter for initial work to the LM910 Module for production, however, there are some additional considerations that must be made when dealing with surface-mount devices.

Recommended Placement Solution

TBC

Mechanical Specification

The below to-scale mechanical specification of the LM910-0630 can be used to aid in PCB mounting and positioning.

LM910_no_antenna

 

Using Broadcom BlueTool – LM506

Broadcom BlueTool is a testing and diagnostic program for Windows PCs that allows a friendly point-and-click method of issuing firmware updates and Bluetooth HCI commands to any Broadcom-based Bluetooth HCI module or adapter. This is also a facility for scripted automation via PERL for production testing.

Installation Notes

Please follow the on-screen instructions. Unless the intention is to provide scripted automation for production or repeated test purposes, please do not select the default installation type, instead disable the PERL module to simplify the set-up of BlueTool.

  • We have noticed some issues when using this software on a 64-bit OS with USB-based Bluetooth devices. In this instance, we recommend the use of BlueTool on a 32-bit OS only.

Issuing a HCI Command

HCI commands are used by a Bluetooth stack to communicate with a Bluetooth Radio Device, as such, HCI commands in their raw form can be difficult to read and understand from a human perspective. BlueTool allows you to issue these commands by double-clicking friendly names and by using windows forms as a simple way to enter parameter data, via drop-down lists, check boxes etc., allowing the user to take direct control of a Bluetooth Radio’s behaviour.

To issue HCI commands via BlueTool, please follow the steps outlined below:

1/ Open the HCI Control Window from the Transport drop-down menu.

LM506_using_bluetool_1

2/ Select the location of the Bluetooth Device on the PC, for PCs with a single USB-based device, this is usually ‘usb0’.
If this is not the case, please refer to the information provided by the Windows Device Manager.

LM506_using_bluetool_2

3/ Check the ‘HCI Protocol Active’ box. If a tick appears and items in the list turn from grey to black, then a HCI connection was successfully established. If not, please check the adapter’s connection and configuration details and try again.

LM506_using_bluetool_3

4/ Each name in the list that you are now presented with represents a Bluetooth HCI Command, simply double-click a command of your choice, fill in any parameters and click ‘OK’ to issue the command.
Commands are categorised by the drop-down list in the top-right corner of the window, with the exception of ‘0: Vendor Specific Commands’, each category and command directly relates to a command published in the Bluetooth SIG adopted specification.

LM506_using_bluetool_4

Downloading Firmware

Firmware files issued by LM Technologies for its Broadcom-based Bluetooth devices are typically in ‘*.HCD’ format, with the exception of production Windows drivers, which are in the ‘*.HEX’ format. HCD files contain many lines of HCI commands in raw byte format. This allows for the file to not only contain the firmware data, but also the instructions for configuring the device and loading the firmware, allowing simple integration into a Bluetooth Stack or driver.

To download a HCD firmware file via BlueTool, please follow the above steps in ‘Issuing a HCI Command’.

1/ To ensure the device is in the correct state, issue the command ‘7.3: Reset’, followed by the command ‘0: Download_Minidriver’.

2/ Open the Download Firmware/Config Window from the Transport drop-down menu.

LM506_using_bluetool_5

3/ Configure the window as pictured below, adjusting ‘Device configuration’ according to the Broadcom IC type and selecting the appropriate HCD file in the ‘Download Configuration Record’ box.

LM506_using_bluetool_6

4/ Click ‘Execute’ and observe for errors.

 

RF Certification – LM506

Many countries require products to be RF certified, as a module, the LM506-0518 may require additional certifications beyond those provided by LM Technologies, this may be the case for the following reasons:

  • LM Technologies does not currently hold a certification for its module/adapter in the specified country and that country does not recognise any of the existing certifications.
  • Please see LM Product Certifications for a list of all current certifications that LM Technologies holds for its modules and adapters.
  • Some countries do not support module-level certifications, in this case, full product certification must be performed.
  • The LM506-0518 has no metal RF shield.In this case certification standards such as FCC only support certification as an entire product or ‘Limited Certification’ where the module must be demonstrated to work in a sub-set of specified products.

To perform certifications, depending on the type of testing performed and the capabilities of the test hardware, the LM506-0518 can be placed into various test modes to aid in this process.

Device Under Test (DUT) Mode

Device Under Test Mode allows a Bluetooth-aware test unit to issue synchronised test commands remotely over a wireless link. This test mode is useful for Bluetooth SIG compliance testing and other RF testing where hardware capable of issuing Bluetooth DUT commands wirelessly.

To place the device into DUT mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable device discovery:

Opcode: 0xC1A Length: 0x01 Parameters: 0x03 (Write_Scan_Enable: Inquiry and Page Scan Enabled)

5/ Issue the following HCI command to enable device role-switching:

Opcode: 0xC05 Length: 0x03 Parameters: 0x02 0x00 0x03 (Set_Event_Filter: (Filter_Type: Connection Setup (Connection_Setup_Filter_Condition_Type: Allow Connections from all devices, Auto_Accept_Flag: Do Auto accept the connection with role switch enabled))

6/ Issue the following HCI command to enter Device Under Test (DUT) Mode:

Opcode: 0x1803 Length: 0x00 (Enable_Device_Under_Test_Mode)

TX Test Mode

TX Test Mode allows the device to transmit fixed or pseudo-random packets on either a single-frequency, fixed-pattern or 79-channel Bluetooth frequency-hopping mode.

To place the device into TX Test mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable TX Test mode:

Opcode: 0xFC51 Length: 0x10 Parameters:
 
Local_Device_BD_ADDR: 0x00 0x02 0x72 0xC9 0x14 0x9D (Example Local Device Bluetooth Address)
 
Hopping_Mode: 0x00 (79 Channel) / 0x01 (Single Frequency) / 0x02 (Fixed Pattern)
 
(IF Hopping_Mode == 0x01) Frequency: 0x00 to 0x4E (Channel 1 2402MHz to 79 2480MHz)
 
Modulation_Type: 0x00 (0x00 8-bit pattern) / 0x01 (0xFF 8-bit pattern) / 0x02 (0xAA 8-bit pattern) / 0x03 (0xF0 8-bit pattern) / 0x04 (PRBS9 pattern)
 
Logical_Channel: 0x00 (ACL EDR) / 0x01 (ACL Basic) / 0x02 (eSCO EDR) / 0x03 (eSCO Basic) / 0x04 (SCO Basic)
 
BB_Packet_Type: 0x00 (NULL) / 0x01 (POLL) / 0x02 (FHS) / 0x03 (DM1) / 0X04 (DH1/2-DH1) / 0X05 (HV1) / 0X06 (HV2/2-EV3) / 0X07 (HV3/EV3/3-EV3) / 0X08 (AUX1/PS) / 0X09 (DM3/2-DH3) / 0X0A (EV4/2-EV5) / 0X0B (EV5/3-EV5) / 0X0C (DM5 / 2-DH5) / 0X0D (DH5/3-DH5)
 
BB_Packet_Length: 0x00 (Any Length up to allowed Packet Type Length)
 
Tx_Power_Level: 0x00 (0dBm) / 0x01 (-4dBm) / 0x02 (-8dBm) / 0x03 (-12dBm) / 0x04 (-16dBm) / 0x05 (-20dBm) / 0x06 (-24dBm) / 0x07 (-28dBm) / 0x09 (Specify Power Table Index - Use this for 10dBm)
 
(IF Tx_Power_Level == 0x09) Transmit_Power_Table_Index: 0x00 (10dBm)

RX Test Mode

RX Test Mode allows the device to receive only fixed or pseudo-random packets on either a single-frequency or a fixed-pattern.

To place the device into RX Test mode, please take the following steps:

1/ Connect the device to a PC or microcontroller capable of issuing Bluetooth HCI commands and provide power.
2/ Follow the Firmware Patch Guide to provide PatchRAM optimisations of the RF parameters required for RF testing.
3/ Issue the following HCI command to reset the device:

Opcode: 0xC03 Length: 0x00 (Reset)

4/ Issue the following HCI command to enable RX Test mode:

Opcode: 0xFC52 Length: 0x0E Parameters:
 
Remote_Device_BD_ADDR: 0x00 0x02 0x72 0xC9 0x14 0x9D (Example Remote Device Bluetooth Address)
 
Report_Period: 0xFA to 0x7D0 (Report Period in Milliseconds from 250ms to 2000ms)
 
Frequency: 0x00 to 0x4E or 0xF0 (Channel 1 2402MHz to 79 2480MHz or Fixed Pattern)
 
Modulation_Type: 0x00 (0x00 8-bit pattern) / 0x01 (0xFF 8-bit pattern) / 0x02 (0xAA 8-bit pattern) / 0x03 (0xF0 8-bit pattern) / 0x04 (PRBS9 pattern)
 
Logical_Channel: 0x00 (ACL EDR) / 0x01 (ACL Basic) / 0x02 (eSCO EDR) / 0x03 (eSCO Basic) / 0x04 (SCO Basic)
 
BB_Packet_Type: 0x00 (NULL) / 0x01 (POLL) / 0x02 (FHS) / 0x03 (DM1) / 0X04 (DH1/2-DH1) / 0X05 (HV1) / 0X06 (HV2/2-EV3) / 0X07 (HV3/EV3/3-EV3) / 0X08 (AUX1/PS) / 0X09 (DM3/2-DH3) / 0X0A (EV4/2-EV5) / 0X0B (EV5/3-EV5) / 0X0C (DM5 / 2-DH5) / 0X0D (DH5/3-DH5)
 
BB_Packet_Length: 0x00 (Any Length up to allowed Packet Type Length)

 

Firmware Patch Guide – LM506

The LM506-0518 features at its core a Broadcom BCM20702 Bluetooth 4.0 HCI USB IC.

The BCM20702 is shipped from the factory with a generic firmware that will allow for communication between the IC and the host via HCI commands, however, this firmware does not include design-specific RF optimisations, the latest bug fixes or additional functionality. It’s therefore important for the sake of RF testing and production that the host load on to the module a ‘PatchRAM’ firmware file.

  • It’s important to note that this patch is applied in volatile RAM memory and as such, must be re-applied each time the device is power-cycled. Needless to say the below routine should be integrated into the host solution that is to be deployed on the end-product.

This guide assumes that the user knows how and has the capability to issue a HCI command and to read a HCI event on their platform.

Overview

  • Open HCI command socket over USB or otherwise.
  • Issue the HCI reset command (OGF 0x03, OCF 0x003 or 0x0C03 together), wait for the command complete event and check that the return status code is zero.
  • Issue the vendor specific HCI command ‘Download_Minidriver’ (OGF 0x3F, OCF 0x02E or 0xFC2E together) and wait for the command complete event.
  • Wait for 50ms for the device to enter Download Mode.
  • Parse each HCI command from the HCD firmware file and send it over the HCI command socket, checking that each command is run successfully.
  • Wait 250ms for flashing to complete.

Issuing commands & command complete event

In all cases, the user should wait for the corresponding Command_Complete event when issuing a command and check the command’s return status parameter for errors.

On some platforms, there may be a convenience function which waits for the Command_Complete event, as a wait is often required with most HCI commands.

HCD file format

The HCD file consists of a set of HCI commands in the following format:

OpcodeUnsigned 16-bit integer in little endian byte orderBluetooth HCI command identifier
Parameter lengthUnsigned 8-bit integerLength of the parameter data for this command in bytes
Parameter dataByte arrayZero or more bytes as specified by parameter length

All the data is tightly packed, so each field begins directly after another as does each command.

HCD file

BCM20702A0-0a5c-21e8.hcd

References

BlueZ; the Bluetooth stack used by the Linux kernel contains a working example of the patchram procedure:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/btusb.c

There is also a patch ram utility for Linux/Android which can be found at the following link:
https://code.google.com/p/broadcom-bluetooth/source/browse/

 

Reflow – LM506

The LM506-0518 module is produced using standard temperature lead-free solder. For this reason, we recommend the use of a low-temperature solder (< ~217°C) to avoid causing a second reflow of the module components, increasing the likelihood of a higher yield.

We understand that some applications and manufacturer limitations prevent the use of a low-temperature solder, in this instance, please follow the below guidelines to form your own custom reflow profile:

Reference Reflow Profile (standard-temperature lead-free)

LM506_0518_reference_temperature_reflow_chart

  • If the host PCBA is double-sided and passes through reflow twice, reflow the module on the final pass only.
  • Do not exceed a reflow temperature of 250°C and refer to your solder paste vendor’s guidelines.
  • Temperature Ramp-up and Ramp-down times should be within the range of 1 to 4°C/s, attempt to not exceed 3°C/s.
  • This chart is for reference only, results will vary from manufacturer to manufacturer and machine to machine.

Customising the Reference Reflow Profile

The reflow profile shown in the above section is for reference only. It is expected that refinements and customisations to this profile will be needed during trial sampling to achieve an acceptable yield.

Moisture Sensitivity and Pre-Baking

The LM506-0518 is rated at moisture sensitivity level 3 (MSL-3). It is recommended to pre-bake the module before SMT placement.

Please see the following IPC/JEDEC J-STD-033B.1 guidelines, which offer recommended bake times dependant on the time the module packaging has been unsealed for and the baking temperature that will be applied:

Bake @ 125°CBake @ 90°CBake @ 40°C
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
Exceeding
Floor Life
By > 72 hours
Exceeding
Floor Life
By <= 72 hours
9 hours7 hours33 hours23 hours13 days9 days

 

SMD/SMT Placement – LM506

The LM506-0518 is a double-sided USB module that finds its design origins as a PCBA suitable for fitting into an adapter housing.

Despite this non-SMT origin, many of our customers find the cost savings of combined adapter and modules sales, paired with the simplistic development pipeline of moving from the LM506 Adapter for initial work to the LM506 Module for production a worthwhile prospect. This has driven LM to work with its customers to find effective ways to treat the LM506-0518 as a surface-mount-device for cost-effective automated placement. Some of these solutions are detailed below.

Recommended Placement Solution

Through a process of trial-and-error in mass-production, LM has identified with its clients, the following placement solution as one that provides good yield:

LM506_smd_1 LM506_smd_2

  • The host PCBA features a cut-out that allows for bottom-side components to avoid interaction during placement and for minimal antenna interference.
  • The cut-out features a small resting area for the antenna end of the module to add stability during the placement process.
  • The cut-out is sized and placed to minimise impact on the antenna and to allow model and production date details to be clearly visible.
  • Copper tracks are run along the host PCBA (highlighted in pink) from the edge of the module all the way to the cut-out, at which point they meet plated half-vias.
  • The plated half-vias allow for superior solder strength and offer a route for additional solder to flow, reducing the likelihood of uneven placement.

Mechanical Specification

The below to-scale mechanical specification of the LM506-0518 can be used to aid in PCB mounting and positioning. Also included are maximum height dimensions and tolerances.

LM506_smd_3

 

Factory Guide – LM505

Firmware Flashing

Testing

Install

Firmware Flashing

Testing

  • Use the Windows Vista / Windows 7 PC.
  • Connect only one port of the LM505 Test Jig to the PC via USB.
  • Connect the LM048 Test Adapter via USB and RS232.
  • Install LM151_Test_Tool_Setupv1.4.exe

Production Run Setup

Firmware Flashing

1/ Open the LM505_Flash folder on the Desktop.
2/ Edit BTWKeys.TXT and place one Bluetooth address on each line, followed by 00000000 00000000 00000000 00000000, for example:

AABBCCDDEEF0 00000000 00000000 00000000 00000000
AABBCCDDEEF1 00000000 00000000 00000000 00000000
AABBCCDDEEF2 00000000 00000000 00000000 00000000
  • Once a Bluetooth Address has been used (flashed onto the module), the program will append the line with the * symbol.

Production Run

Firmware Flashing

1/ Open the LM505_Flash folder on the Desktop.
2/ Run the batch file 2046.bat:

LM505_factory_guide_1

3/ Place an un-flashed LM505 module into the LM505 Test Jig and provide power using the metallic flip switch:

  • If there is a request for drivers, please install the driver located in LM505_Flash\drivers

LM505_factory_guide_2

4/ Remove power using the metallic flip switch, remove the module and repeat step 3 until production is complete.

  • If any error occurs or the flashing process freezes, please close the cmd.exe program, remove power using the metallic flip switch and begin again from step 2.

Testing

1/ Run LM151_Test_Tool.exe
2/ Enter the name of the person performing the testing and the Factory Bay Name/Number followed by OK (for traceability):

LM505_factory_guide_3

3/ Place a flashed LM505 module into the LM505 Test Jig and provide power using the metallic flip switch:
The address and name of the device will appear, along with confirmation that it is successfully loaded into LM151.

LM505_factory_guide_4

4/ Select Search Devices to begin discovery of the LM048 Test Adapter, a list of Bluetooth devices will be displayed:

LM505_factory_guide_5

5/ Double-Click on the Bluetooth Address representing the LM048 Test Adapter.

  • If a request to connect or pair with the LM048 Test Adapter appears, accept it.

LM505_factory_guide_6

6/Confirm that the test Passed, remove power using the metallic flip and remove the module. Repeat step 3 until production is complete.

7/ After production, e-mail the new test results stored in the installation directory of LM151 to: ahmad@lm-technologies.com

LM505_factory_guide_7

For more information and troubleshooting, please refer to the guide

LM505-0513_Test_Procedurev1.1.pdf

 

LM Bluetooth Test Software

This page covers various topics pertaining to the LM Bluetooth Test Software. The source code for the software is in a git repository hosted on Bitbucket.

Code documentation and annotation

The source code itself (including C++ and QML) is annotated with doxygen compatible comments. There is also a doxygen config file in the root of the source code directory.

Note

As a general rule all the C++ documentation comments reside inside .cpp files. The exception to this is signal signatures which would be a pain to document inside the .cpp files. 

Code layout

The application is a standard QtQuick project with QML and C++ components. Application flow starts in main.cpp and then moves on to main.qml and AppRoot.qml before becoming event based. Inside the couchapp subdirectory there is some couchdb stuff which uses a tool called couchapp to automate uploading CouchDB Javascript to a running instance.

lm-bluetooth-tester-2015-arch.svg

Server Deployment

The couchdb server, which acts as a central hub for the clients, currently resides on a AWS (Amazon Web Services) instance.

Accessing AWS

The usernames and passwords for AWS are kept inside an encrypted database on dropbox, which I (Richard) can give out on demand. There is just one instance running at the moment which is accessible from ec2-52-28-13-105.eu-central-1.compute.amazonaws.com. There is no password, but you will need the private key (inside the password database) and it only accepts SSH connections from LM’s IP address, this can be changed from the AWS console. Although there is one instance, there are two storage volumes, one volume is used by the instance’s OS and the other contains the database.

Docker

CouchDB does not run directly on top of the AWS Linux instance, it runs inside of a Docker container which was started with a couple of arguments to forward ports and mount a volume. This is quite confusing so it needs to be better documented at a later date. After performing updates to the AWS host, make sure the docker container is running!

Configuring CouchDB

If you use a docker instance then the initial installation and configuration of CouchDB is taken care of, you just need to do the stuff specific to LM. If you already have a set of database files from an existing server, all you need to do is copy them to the right directory and follow step one.

  1. Create an instance admin user with the user name and password in the password database
  2. Create users for each test site and add them to the tester group (or just the developer user to begin with)
  3. Create a config database for the developer user e.g. config-lmlondon-developer and make developer a database admin
  4. Create activity, identity and results databases with developer as admin and give the tester group access.
  5. Trigger a replication from the developer client (see below), this should populate the databases you have just created.

Client Deployment

Deploying the client software is currently a tedious process which we may need to better automate in the future. It consists of a number of steps including setting up a local CouchDB instance.

  1. Install Linux with QT5, the BlueZ libraries and obviously a desktop
  2. Compile the application on a development machine and copy the lmbtest executable across.

This is all that is required to actually run the application, but it also needs the local couchdb instance to function properly which is where the fun begins.

  1. Install CouchDB.
  2. Login to the CouchDB admin web interface.
  3. Add a config database.
  4. Add an ‘identity’ document with the details “_id”: “identity”, “bay”: “<the bay name>”, “site”:”<the factory site name>”
  5. Add a ‘replication’ document with the details “_id”:”replication”, “host”:”https://<user name>:<password>@ec2-52-28-13-105.eu-central-1.compute.amazonaws.com:6984″
    Run lmbtest then close it after a few seconds.

The bay name and factory site name should correlate with the name of a config database on the server e.g. config-lmlondon-developer where lmlondon is the site and developer is the bay name. The user name and password are for a user on the server which has access to the aforementioned config database and is in the testers group.

When you run the lmbtest executable it will trigger a replication causing all the appropriate databases to be copied across.

 

LM Bluetooth Test Software Requirements (superseded)

Superseded notice

Target Release: 0.1

  • JIRA Issues Macro: com.atlassian.sal.api.net.ResponseStatusException: Unexpected response received. Status code: 404

Goals

  • Allow n adapters to be tested at once
  • Increase diagnostic data collected during testing
  • Present data in a better format for analyses
  • Protect data from tampering

Background and strategic fit

Testing one adapter at a time is expensive, testing a large number of adapters at once has negligible cost. Better data diagnostics may result in quicker resolutions to manufacturing problems and disputes.Being able to analyse data quickly reduces cost further. Finally: we want to know if data has been massaged so that we can challenge the reasoning behind any changes to test results made by the factory which may help in dispute resolution.

Assumptions

  • We will choose the hardware and software.
  • The user is capable of turning a PC on, pugging some USB sticks in and following mildly technical instructions to use a GUI based application.
  • The target dongle (that is the BT radio being tested against) is plugged into a different physical or virtual machine running another simple app with a separate spec.

Requirements

TitleUser StoryImportanceNotes
Tester identity We get the factory testers name and bay numberMust have
Test dongle list/chooser A list or table of dongles to be tested which are plugged inMust haveMay display all the dongles details and actions in the list view or make the user click on it to go to a separate page. Mainly depends what is easier for me.
Manually add dead dongles Allow user to manually add dongles to the test results which are not functioning at allMust have
target BT device Allow user to enter the address of the target BT device for the dongles to be tested against.Must haveCould also just be a dongle on the same system.
Output test results to CSV Output any useful data to a CSV file which can be opened by Excel without much trouble.Must haveExcel works better with a particular CSV style, meaning the file can be opened by just double clicking it rather than having to do an import and tell Excel what format to use.
Found target device in scan Output whether the target device could be found during the scan.Must haveAlso the amount of time it took and signal strength as part of extended test data
Open rfcomm connection to target Output whether or not an rfcomm connection could be establishedMust have
Send file over rfcomm Output whether a file could be sent over rfcommMust haveAlso the time it took and error rates as part of extended test data
watermark or encrypt the test results Probably just output an encrypted version of the results which the factory must send to usNice to haveThey probably won't go to any serious lengths to try and reverse engineer our encryption or hashing algorithm, so it should be easy.
LoggingLog everything the app doesNice to have
Extended test dataSignal strength and all available device and connection propertiesNice to haveJust take the low hanging fruit first to match the old testers profiling.
USB level device loggingCheck the system for USB devices which are functioning on some level, but haven't been initialized by the stackNot sureDon't want to do it because it will require interrogating the HAL (or similar) separately. Maybe could just run a script which calls the lsusb command for occasional diagnostics if necessary.
Choose data to send Choose the data sent over rfcomm Not sureIt was included in the old one, but I don't know why... Might as well just hard code the data or make it a bit more flexible by hard coding a file name which is loaded from disk.

User interaction and design

Most of these screens are out of date

Input tester identity details:

bluetooth_test_software_requirments_1

Same thing but using the Ubuntu QT components

bluetooth_test_software_requirments_2

Yet another version, but using QT widgets.

bluetooth_test_software_requirments_3

Test setup screen where the user selects and configures the connected bluetooth USB devices to test and can manually add devices which are not working so they can be included in the report.

bluetooth_test_software_requirments_4

bluetooth_test_software_requirments_5

Finally the test results and export page. I don’t think it is necessary for the user to be able to add and remove rows on this screen, but I included it in the mock up anyway. This was done in Visio because I was getting dragged into implementation with QML and especially QT widgets.

bluetooth_test_software_requirments_6

Factory Test Flow

bluetooth_test_software_requirments_7

Not doing

  • Hopefully flashing the device because that is not even testing anyway.

Design

The following are not requirements, but more a guide for the implementation.

Data Model

Below is a diagram illustrating the applications data content. The named rectangles could, but do not necessarily correlate with classes in the code.

bluetooth_test_software_requirments_8

Everything is outputted into the export file with minimal processing and lots of duplicate data. This allows someone to open it in Excel and means that I don’t have to create a database. As the test tool is used and we get feedback from the person analysing the results; data filtering and transformation can be written into the app if it will have a high payback.

Feasibility

After testing straight Qt QML, Ubuntu QML and Qt widgets, I have decided that straight Qt QML and a C++ back end is the best way to go. The Qt C++ Bluetooth library will fill all the Must Have requirements so there is no need to use BlueZ directly. Unfortunately the Qt QML/Javascript Bluetooth library is not capable of handling multiple radios so we have to resort to C++.

The QT C++ Bluetooth library does not work! It silently fails to do anything. Under the hood it uses the DBus interface to BlueZ which I have tested and works so I have no idea what is going on. We could use the DBus interface to BlueZ, but instead I decided to try using the BlueZ C API, which despite not having any documentation I could find, I got working fairly quickly by just looking at the source code to the C tools (http://git.kernel.org/cgit/bluetooth/bluez.git/tree/tools). At least with this approach we know there won’t be any features missing from the interface because this is the most direct way of using BlueZ in a sensible manner.

Notes

Article on programming with BlueZ by someone at MIT: http://people.csail.mit.edu/albert/bluez-intro/c404.html

Don’t need to create an RFCOMM socket, can use L2CAP which RFCOMM sits on top of. It probably makes no difference either way though. We certainly don’t need to create a special device file like when using the command line and terminal applications to test a Bluetooth connection.

Can get a local device id from an address with hci_devid(char*)

hci_enquiry() scans for remote devices

hci_read_remote_name() gets the name of a remote device

Dongle destruction

If a setting isn’t mentioned it was left as zero.

Dongle NoOTP SettingsEffect
1Address=BD:BD...,VID = 0xa5c, PID = 0x21e8, LED = 23, usb desc = 3Appears to have corrupted it, now has seemingly random settings
2Address=BD:BD..., LED = 23, usb desc = 3VID and PID set to zero so it isn't recognised as a BT device. Green LED started working though.
3Address=BD:BD...,VID = 0xa5c, PID = 0x22be, LED = 23, usb desc = 3VID & PID are OK, BD address changed OK, Green LED works.
3" ", LED=1" ", LED stopped working and OTP read says LED=19 not what was entered!
3" ", LED=31" ", Only Red LED works
3" ", LED=255" ", Red LED flashed a bit, LED=223
3" ", LED=16" "
3" ", LED=32" "
3" ", LED=23LED=223; it appears the OTP is not writable anymore.
4" ", LED=32" ", No LEDs
4" ", LED=24" ", No LEDs and LED=56
5" ", LED=24" ", No LEDs, but LED=24. It appears OTP does not cope very well with being written to multiple times as would be expected.

firmware

Program which can set the BD address and upload firmware:

https://code.google.com/p/broadcom-bluetooth/source/browse/brcm_patchram_plus_usb.c

Test procedure

1/  Set testee to connectable and remote loopback mode

2/ connect tester to testee

3/ Tx test, top, middle and bottom frequencies. modulate (prbs9 pseudo random), logic channel ACL-EDR, packet type DH5, power levels

4/ Rx test

5/

 

SPP Library and Binary AT Protocol for Apple LM048

Objective

Create an interface between the LM048 and iOS devices. This includes an API for the end user and a communication protocol between the LM048 and iOS.

08 Jul 2015 We are not targeting iOS presently because Apple don’t like SPP.

Links

Design

Protocol

This is a simple binary protocol which closely mirrors the ASCII AT command protocol previously used for the LM048s and other LM products.

Packet structure

Generic representation of an AT command data structure

+———————————-+
|                        Header                 |
+——————+—–+– – — – ———–+
|      Mandatory             |       Optional           |
+—-+———–+——+——–+– – – – – –+
|type|checksum|mode| length |    body      |
+—-+———–+——+——–+– – – – – –+

Above is a diagram of the layout of our AT command packet. The bottom line shows the actual fields, the top two are just to be used as guides. Each dash represents 2-bits and the plus symbols simply denote the beginning and end of a field, they do not imply any padding. Fields are simply delimited by their length, hence the length of the body has to be specified in the header (when there is a body).

The fields are as follows:

Type: Unsigned 8-bit int, this is analogous to the AT command name.

Checksum: Unsigned 16-bit int, CRC error checking

Mode: Unsigned 8-bit int, indicates if this is a response or a request and what type of request. It is similar to the ‘?’ and ‘=’ symbols added to the end of many AT command names.

Length: Unsigned 16-bit int, The length of the body in bytes. This field is not present if the command type and mode can not have a body. Some commands have a known body length, so do not need the body length specifying. However, for the sake of simplicity, the length is always present and should be the correct value.

Body: An arbitrary string of bytes.

Request – Response

Below is the model timeline for a request and response:

Client transmits request Host processes request Host transmits response Client processes response
|———————–>|———————–>|———————–>|————————-> …
1                                     2                                      3                                     4
The host may close the connection after sending the response if appropriate or the client can close the connection or send more requests. The client is the iOS device and the host is the LM048.

Below is the timeline for when no response is received, but the message was transmitted according to the underlying connection

Client transmits request Client waits for time out Client signals the error to the user
|———————–>|—————————>|————————————–> …
1                                      2                                           3
A similar sort of thing should happen when any other kind of timeout occurs, Etc.

Host events

When something connects to the LM048 it will send an event to the iOS device. An event just being another type of request, but one which the host sends rather than the client. It is conceivable that the client will receive a host event while waiting for a response, so this has to be taken into account when validating incoming messages. Obviously the host should not start sending an event half way through sending some other message.

Checksum

http://www.menie.org/georges/embedded/crc16.html

 

Linux: Reverse ssh tunnel

This is a method of circumnavigating NAT and firewalls in order to establish a SSH connection with a Linux device.

AWS/Server setup

You will need a SSH server with a permanent IP address. Setup a user on that server for the SSH connection and add the following to the sshd_config

Match User tester
    ChrootDirectory /var/jail

Use ssh-keygen to create a new public-private key pair. The public key goes in ~/.ssh/authorized_keys on the server and the private key goes on the device where the tunnel will be established from.

Remote device setup

The remote device which will be behind a NAT or firewall will need to automatically establish a SSH tunnel with the internet server. Assuming it is using ArchLinux or another Systemd based distribution you can set up a service unit to do this:

[Unit]
Description=Maintain SSH tunnel
After=network.target
 
[Service]
ExecStart=/usr/bin/ssh -i /opt/keys/tester.pem -N -C -R 2222:localhost:22 tester@52.28.114.52
Restart=always
RestartSec=5min
 
[Install]
WantedBy=multi-user.target

Note that the private key file has been deposited in /opt/keys/tester.pem for easy access by root and that the local port 2222 will be used on the server. A unique port will need to be used for each client connecting to the server.

Known hosts setup

  • Before running the service for the first time, run `/usr/bin/ssh -i /opt/keys/tester.pem -N -C -R 2222:localhost:22tester@52.28.114.52` in an interactive prompt to add the host’s fingerprint to the known hosts file. It is very important that nothing drastic changes about the host (such as its IP) so that its fingerprint does not change.

Then do the following to enable and start it:

$ sudo systemctl --now enable ssht.service

Connecting

SSH into the AWS server (or where ever the tunnel terminates) and use the following command to connect to the device behind NAT

$ ssh -l developer -p 2222 localhost

Frozen connections

  • Leaving a connection through the SSH tunnel idle for too long can result in the ssh client freezing. So it is best to do the work and then exit it straight away.

 

PCB Design Guidelines for Contractors

File Naming Structure

All Projects are saved in Z:/R&D/Hardware/~Projects

At the top level the overall Top Project FOLDER naming standard is:

PCBXXXX [Chipset] [LMXXXX] [Short Description]

i.e.:        PCB0012 CSRB5342 LM951 CHIP ANTENNA

See example below:

pcb_guidelines_contractors_1

Project Sub-Folder Structure

Inside each one of these Project Folders there are Sub folders pertaining to each individual project.

An example Project folder is shown below. The LM Project structure and nomenclatures must be followed.

The folder contains 14 sub folders for organizing the file types in a Project.

pcb_guidelines_contractors_2

Most of the PCB work will be saved in the Folder “6. SCH & PCB”.

Folder “6. SCH & PCB”.

Only the latest and most relevant files are stored here. ALL old / extraneous Altium files must be moved to the “archive” Sub folder.

Then inside the “6. SCH & PCB” Folder:

The Project FILE .PrjPcb naming standard is:

PCBXXXX [Chipset] [LMXXXX] [Short Description]

i.e.:        PCB0012 CSRB5342 LM951 CHIP ANTENNA

 

The Schematic .SchDoc naming standard is:

CXXXX [Chipset] [LMXXXX] [Short Description]

i.e.:        C0012 CSRB5342 LM951 CHIP ANTENNA

 

The PCB .PCBDoc naming standard is:

PCBXXXXx [Chipset] [LMXXXX] [Short Description]

i.e.:        PCB0012a CSRB5342 LM951 CHIP ANTENNA

 

To help speed up and get this Project off the ground I have already named the files in the “SCH & PCB” folder for you. The following files are included:

pcb_guidelines_contractors_3

Folder “3. Reference & Investigations”

Any investigations and calculations carried out must be saved here

Folder “7. Datasheets”

Any new component datasheets to be saved in “7. Datasheets” . After review these will be moved to the central Datasheet repository and the individual files will be replaced by links. (This reduces the amount of space taken up on the server by duplicate datasheets)

SCHEMATIC

When you open the Schematic you will find an example Schematic for you to edit.

This is to help you get started quickly so that you can use some of components already saved in our company database.

The new schematics you produce should contain

  • Circuit clearly drawn out with labelled sections.
  • Notes describing any component choices.
  • Any datasheet component options that have been chosen should be clearly described
  • All new Schematic symbols created should be saved in a .SCHLIB file to be supplied with the project

You will obviously need to create some new components. There are some general components (like capacitors/resistors) of which you will need different values.

DO NOT simply edit the text field parameter of the current components to change the value. These new components need to be created with their own parameters.

NEW COMPONENT  Parameters

ANY NEW COMPONENT SCHEMATIC SYMBOLS MUST BE SAVED IN THE .SCHLIB FILE WITH THE MINIMUM FOLLOWING PARAMETERS:

pcb_guidelines_contractors_4

These are MINMUM parameters which we need in order to save a new component schematic on our system. Pay special attention to the syntax:

i.e: Manufacturer Part Number 1

not: Manufacturer Partnumber 1

I will amalgamate these into our company database at a later date using Microsoft Access.

PCB

When you open the .PcbDoc you will find an example PCB0012 for you to edit. We would like to keep a standard footprint for the finished PCB.

The PCB Footprint in the example .PcbDoc has I/O pads spaced at the standard 1.27mm (X) and 10.16 (Y) pitch. Keep to standard pitches and label all dimensions in mm.

If the PCB size needs to grow then perhaps we can leave the pads as they are and simply extend the board to the right.

The I/O pads are labelled by carrying over the Net Names from the schematic (IO1, IO2, AIO,GND etc). Ideally we would like to keep these the same on the LM951 where appropriate

Pay attention to the Layer Stackup and PCB footprints (i.e. no routing underneath 0402 components for example),

Design Rules

The Design Rules file is accessed using the shortcut keystroke (D,R). Pay attention to the minimum clearance rules and define any new rules necessary for routing to components with small pitches.

These rules MUST be specific to the area of the component they are intended for ONLY. Ensure that the priorities for the rules are correct to allow this

Component Silkscreens

Any component silkscreen designators which do not fit on the PCB must be drawn on the Top Comp ID layer. Below is a screenshot of the Layer names and Colors to be used:

pcb_guidelines_contractors_5

Some General PCB Considerations for DFM include:

  • Via Hole Minimum Size: 0.2mm (with minimum 0.4mm Via copper diameter)
  • Preferred PCB Track width: 0.15mm
  • Minimum PCB Track width: 0.1mm
  • No use of blind vias or via-in-land without specific permission for LM project manager

 

Linux WiFi Compatibility

Here lies a feature or compatibility table for RT wifi and combi-products on Linux based platforms. The features are explained after the table.

 LM006, LM809 & LM82x (rtl8188cus)LM811 (rtl8723bu)LM807 (rtl8192du)LM808 (rtl8811au)LM816? (rtl8188eus)
Linux x86 (PC)STA, AP, MON, IBSS (on new kernels). MESH should be supported by the in-kernel driver, but doesn't work at the moment.STA, AP & maybe partial IBSSSTA reliably & AP with difficultySTA & APSTA & ?
AndroidSTA, AP, MON and probably IBSS.Maybe?Probably atleast STA & AP?
Raspberry PiSTA reliably or STA, AP, MON & IBSS unreliably. I am currently working on a better solution.STA, AP & maybe IBSSprobably same as x86probably same as x86?
NotesThere are three available drivers: the in-kernel-drivers which are great, but are missing features on older kernels and are very buggy on the Raspberry Pi. Next there is an old, cut-down version of the vendor driver which works on Raspberry Pi, but only supports STA mode and finally there is the full featured vendor driver which I am porting to newer kernels.There are separate drivers for BT and WIFI.No in-kernel-driverNo in-kernel-driverNo in-kernel-driver

STA mode (Station mode)

This is how most people use WiFi; in this mode you can connect to an access point. It would be unusual if a driver didn’t support it.

AP mode (Access point or infrastructure mode)

This allows the user to create or extend a wireless network. Access points act as a hub which allows other (Station) devices to connect to a wireless network. They are commonly used in wireless routers and hotspots.

IBSS mode (Ad-hoc mode)

Stands for Independent Basic Service Set. In this mode each node in the network communicates directly with every other node. It allows you to create a network with no access points.

MESH mode (IEEE 802.11s)

Like IBSS, but a lot more useful because it also allows two nodes which are out of range of each other to communicate via nodes in between them. It will work very well with IPv6 and hopefully Realtek will provide support for it soon or I can get time to figure out how to enable it myself.