1. Research Topic: 2022 USASOC 08 FRIENDLY FORCES ID 

2. University and Department: Stevens Institute of Technology; Department of Electrical/Computer Engineering and Department of Mechanical Engineering 

3. Customer: US Department of Defense, US Army Special Operations Command 

4. Objective: To greatly reduce friendly fire incidents by creating a pair of transceivers capable of sending and receiving encrypted signals that contain identification and location data while using multipath propagation to mask the location of the sender from a hostile direction-finding network.  

5. Objective notes (something about how we are obscuring the presence and location of friendly forces to hostile actors) 

6. Organization  

1. Team Members: 

• John Jobin McAuliffe – Team leader and mechanical design 

• Matthew Petrin – Documentation and ray simulation 

• Kenneth Kim – Data encryption and ATAK integration 

• Benjamin Holko – User interfaces and signal processing 

• Drew Pearlstein – Signal processing and circuitry 

2. Faculty Advisors: 

• Kevin Lu – klu2@stevens.edu 

• Dov Kruger - dkruger@stevens.edu  

3. University Capstone Coordinators 

4. Put lu here 

Execution 

5. Statement of Work 

The team intends to produce a device which will be capable of scanning the nearby area for friendlies and displaying any detected friendlies on a map. Scans will be performed using multipath reflective signaling. The device will also allow the user to scan a specific target if LOS is established. Friendlies may choose not to respond using a manual response mode. Signals will be largely untraceable. 

1. Prior to finalizing designs, the team will conduct interviews with military experts regarding the following topics: 

• Minimum required device battery life 

• Maximum allowable device weight 

• Minimum expected scan radius 

• Preferences regarding scanning-mode map display 

• Preferences regarding targeting-mode ID 

• Preferences regarding auto and manual-reply modes 

• Environments in which the device might be used 

2. The team currently intends for the device to be: 

• Capable of holding a charge for 3 days 

• Capable of scanning an area 1 km in diameter 

• Composed of 1 transceiver, 2 antennae, 1 microcontroller, 1 digital display, 1 battery, and some number of wires/connections 

• Be able to send signals using the minimum power required to achieve the required range in order to lower chances of detection and save power 

The team currently plans to implement the following features (see the Intended Features document for more detail): 

• Multipath area-scanning capabilities 

• Ability to display scanned allies on a map 

• Multipath ID of a single target 

• Automatic and manual scan reply modes 

• PIN/biometric-based device security 

• Integration with ATAK software 

• Reflective signaling to avoid tracking 

• Encryption of transmitted data 

Testing of the device will primarily be performed in Hoboken, NJ. We expected the device to be used in urban/suburban areas. 

Constraints to be added 

3. CONOPS: 

  Refer to Concepts section 

4. Prototypes:
   MATLAB Prototype: 

MATLAB may be used to simulate the design in a virtual environment. Signals using OFDM, various mapping techniques, and data encryption may be simulated using MATLAB. Power loss due to reflections and other environmental conditions may also be simulated. The degraded signal will be demodulated and decrypted, allowing for error rate estimations. A MATLAB prototype may serve as proof of concept of the system. 

NI-USRP/LabVIEW Prototype: 

The system will be simulated using NI-USRP 2901 software-defined radio kits and LabVIEW virtual instruments. Instead of just simulating path-loss, signals may be truly wirelessly transmitted between SDRs. The prototype may be iterated to allow for multiple transceivers. This prototype should be relatively accurate to the final deliverable but will be larger and less convenient to use. 

5. Design Reviews: 

• Present viability of reflective/multipath signaling 

• Present ability to calculate path of reflected signal 

• Present ability to encrypt and mask origin of reflected signal 

• Present multi-user system 

• Present multi-user system employing cognitive radio 

• Present potential mode-selection designs 

• Present potential data-display designs 

6. Proposed User Interfaces: 

Scan mode: A small digital map (on a tablet or helmet-based display) will display the surrounding area. When a scan is initiated, any identified allies will appear as glowing points on the map 

Targeting mode: When line of sight exists between the user and a potential ally, the user will aim at the target and press a button to initiate a targeted scan. A positive response will result in a small LED on the weapon lighting up. Alternatively, the device will vibrate. We are aware of the issues with requiring the user to aim at a potential ally. 

Manual Response Mode: When set to manual-response mode, whenever the user is scanned, a small LED will light up. Pressing a button will respond to the scan. Alternatively, the scan’s user ID will be displayed on the map. If the request comes from a compromised user, it may be ignored.  

7. Block Diagrams: 

See Concepts Section

8. Processes for: 

1. Subsystem component development, fabrication, testing: 

• Transceiver: In prototypes, signal processing will be performed using LabVIEW and MATLAB. It will most likely be tested using one of the labs at Stevens or via sending signals off buildings in Hoboken and listening for a return signal. The receiving antenna will be tested to ensure it can consistently receive the required frequencies in operation and send this to the microcontroller for demodulation. The transceiver will be capable of scanning frequencies, receiving data, and sending directed signals in a 360 degree radius. 

• Microcontroller/Physical System: We plan to have the microcontroller and display on an existing device such as an Android phone or a laptop to save on having to make new hardware. If we decide to use an Android device, encryption and modulation/demodulation algorithms will be programmed in Android Developer Studio. The microcontroller will take as inputs the omnidirectional antenna data from the transceiver, orientation data from a gyroscope, information from the software, and the user’s commands from the UI and send commands to the transceiver for which direction to send signals in and the power required for those signals while also outputting the received data on the user interface.  

• Software: The data that the software will be processing will be vector maps of existing 3D terrain data. 3D terrain data will be broken down into a grid and on each square vectors containing their square of origin will be drawn going out in all directions. When each vector encounters an obstacle, a reflected vector will be drawn at the point of intersection containing the same grid coordinates as the previous vector. Process will be repeated until all vectors encounter 3 obstacles. The software on the usable device will orient the user on the terrain grid and find all vectors pointing to its position, using the origin square of the vectors and their direction to calculate the optimal directions for transmitting the signal while encompassing the entire area.  

2. System integration: 

• Transceiver: One of the receivers will be dedicated to listening for open frequencies to hop to. The frequencies it picks up will be sent to the microcontroller and considered as occupied channels. Anything this receiver doesn’t pick up will be considered open channels and the microcontroller can select these to hop to.  

• Microcontroller:  

See system block diagram. Additional detail to be added. 

• Software:  

See above. Additional detail to be added. 

3. All-up system testing:
   To be done. 

4. Demonstrations: 

• Demonstrate microcontroller’s ability to encrypt, decrypt, modulate, and demodulate a signal. Then ensure cognitive radio functionality. 

• Demonstrate transceivers’ and antennas’ ability to transmit/receive and communicate effectively with the microcontroller.  

6. All team members are expected to contribute to all areas of the project. However, a rough division of labor is described below: 

John Jobin McAuliffe – Team leader responsible for team organization, decision making, and contact with customers. Will also lead development of physical and mechanical systems (antenna adjustment, weapon mounts, wearable components, etc.) and will oversee any testing, ensuring safety guidelines are followed. 

Benjamin Holko – Will direct user interface design, taking input from military contacts. Additionally, will contribute to signal processing systems (modulation, prefixing, etc.)  

Drew Pearlstein – Will contribute to signal processing systems as described above. Will also lead development and integration of any hardware systems. 

Kenneth Kim – Will perform data encryption and decryption. Will also integrate radio systems with existing software (ATAK) and take the lead on any software-related aspects of the project. 

Matthew Petrin – Responsible for documentation of team activities. Will also calculate and model ray propagation and develop cognitive radio models. 

7. Resources and Facilities: 

• SIT Design Laboratory located in the Gateway North building.  

• SIT senior design funding ($400) 

• 2 NI USRP 2901 SDR kits 

• LabVIEW, MATLAB, and other various software provided by SIT 

• Professor Yu’s Wireless Communication’s Lab (Burchard) 

• Funding granted by the SIT Capstone Program/DoD 

• Software Defined Radios provided to SIT by the US Air Force.  

8. Spend Plan: 

• 2x Omni-directional antenna - ~ $200 ea. 

• 2x directional antenna - ~ $200 ea. 

• 7x P259 Coaxial cables - ~$30 ea. 

• 2x precision GPS system -~$500 ea. 

• Components to rotate and position antennas electronically - ~$500 

• Miscellaneous cables - ~$70 

• 2x Batteries - ~$200 

• 4x Radio Modules - ~$25 

• 2x Raspberry Pi kits - ~$400 

• User Interface materials - ~$100 

• Delivery fees - ~$200 

• Publications - ~$100 

• Auxiliary - ~$500 

7. Schedules and Reporting 

1. Gantt Chart: