Senior Embedded Systems / BLE / RF Engineer for Vehicle Consumer-Electronics Prototype

Senior Embedded Systems / BLE / RF Engineer for Vehicle Consumer-Electronics Prototype We are seeking a highly experienced embedded systems / wireless engineer or small engineering team to help advance an existing vehicle-based consumer electronics prototype. A working proof of concept has already been developed using an ESP32-based hub and an iPhone application. We are now preparing the next major development stage: a reliable standalone consumer prototype using small wireless tags to determine whether important personal items are actually present inside a vehicle. Important: We Want Engineering Judgment, Not Just Implementation We are not simply looking for someone to reproduce or extend our existing ESP32/BLE architecture. We want an experienced engineer who will critically evaluate the current direction and tell us if there is a: • Simpler solution • More reliable solution • Better wireless architecture • More consumer-friendly architecture • Lower-cost architecture • Better path toward eventual manufacturing If our current assumptions are wrong, we want to know that before significant additional development is performed. This is not a beginner-level Arduino project. Desired Experience Strong experience in several of the following areas is preferred: • ESP32 / ESP32-S3 or comparable embedded processors • Nordic nRF52 or comparable low-power wireless devices • Bluetooth Low Energy advertising and scanning • BLE/RF signal analysis • Low-power battery-operated wireless products • Antenna/RF behavior in real-world environments • iOS/Bluetooth integration • GPS/GNSS or other location technologies • Embedded displays • Audio/voice alerts • Persistent embedded storage • Vehicle electronics / vehicle IoT • Consumer electronics prototyping • Real-world system testing Custom PCB and RF/antenna design experience is a plus but is not necessarily required for this prototype phase. Existing Development The project is not starting from zero. Existing development includes: • Working ESP32-based proof-of-concept hardware • Existing firmware • Existing iPhone application/source code • BLE item-detection functionality • Technical documentation • Demonstration/testing materials The selected engineer will be able to review the existing system. Detailed proprietary information and source code will be provided only to serious finalists after confidentiality requirements are completed. Development Objective The objective is to develop a standalone vehicle-based system capable of automatically determining whether multiple important tagged items are present when the vehicle is started. Examples of monitored items could include: • Keys • Wallet • Briefcase • Lunch box • Backpack • Smartphone • Other important personal items The consumer should not have to manually initiate a scan. The intended general behavior is: Vehicle starts → System powers on → Automatic item check → Warning if an important item is missing Our current target is approximately 3–8 seconds from startup to a useful missing-item determination under realistic operating conditions. We want applicants to tell us whether this target is reasonable and what tradeoffs are involved. Critical Technical Challenge: Inside the Vehicle vs. Nearby This is one of the most important engineering problems in the project. The system must distinguish between: A tagged item actually inside the vehicle and The same item physically nearby but outside the vehicle. For example, a vehicle may be parked next to a house. A tagged wallet could remain inside the house while still being close enough for the vehicle system to detect its wireless signal. The system should not routinely conclude that the wallet is inside the car merely because its signal can be detected. We are particularly interested in engineers with practical RF experience who understand that real-world BLE/RF behavior can be very different from bench testing. Simply saying “use RSSI” is not enough. We want to understand how you would make the determination reliable and how you would prove that reliability experimentally. Consumer Installation Must Remain Simple The eventual product is intended for ordinary consumers. Our preferred commercial direction is a single primary vehicle unit that is easy to install and power. We do not want the consumer to: • Mount antennas throughout the vehicle • Install separate receivers in the trunk, doors, or seats • Run wires throughout the vehicle • Perform complicated RF calibration • Modify the vehicle's electrical system If your proposed technical architecture uses multiple antennas, receivers, sensors, or radio technologies, explain how they could eventually be incorporated into a simple consumer product. We are open to sophisticated engineering inside the product, but installation must remain simple for the customer. Prototype Stage — Expected Functions The next prototype stage is expected to address approximately: • 10 physical prototype wireless tags • Unique identification for each tag • Standalone vehicle detection/scanning hub • Automatic startup scanning • Simultaneous monitoring of multiple tags • Architecture supporting at least 16 items, preferably expandable toward 32 • Dashboard display/interface • Audible and/or voice alerts • Persistent settings/memory • Location capability • Recognition when a previously missing item returns • False-alert reduction • Smartphone detection considerations • Real-world vehicle testing • iPhone application updates for configuration/setup where appropriate • Complete technical documentation and engineering handoff For the first prototype tags, use of suitable existing wireless modules is acceptable. We are not requiring production-ready custom PCBs during this phase unless the applicant believes that is technically necessary and explains why. We Are Open to Different Technologies Our current proof of concept uses BLE and ESP32. Do not assume these must remain the final architecture. We are open to consideration of: • ESP32-S3 • Nordic nRF52 • Other embedded processors • Different BLE architectures • Multiple internal antennas or receivers within one consumer unit • BLE combined with another sensing/proximity technology • Different approaches to smartphone detection • Different approaches to location • Combining the hub and display • Other architectures we have not considered Any alternative should be evaluated for: • Reliability • Consumer simplicity • Tag size • Battery life • Detection speed • Hardware cost • Complexity • Future manufacturability Smartphone Detection The driver's smartphone may itself be one of the important items being monitored. At the same time, the core vehicle system should not depend upon the smartphone application in order to perform normal missing-item detection. We understand that iOS may impose Bluetooth/background-operation limitations. We want applicants to explain candidly what is technically achievable and recommend the most reliable practical approach. Location Capability Location functionality is also being considered. GPS/GNSS is one possible approach, but we are open to alternatives or hybrid solutions. Location functionality must be secondary to the primary item-detection system. The primary system must continue operating in locations such as: • Garages • Underground parking • Areas with poor satellite reception Detailed location-related product behavior will be discussed with finalists under NDA. Real Vehicle Testing Testing must occur in an actual vehicle, not only on a workbench. Testing should include tagged items in locations such as: • Front passenger compartment • Rear seating area • Glove compartment • Center console • Closed trunk • Difficult or partially shielded locations Testing must also include tagged items located outside the vehicle but nearby. One important RF test will involve a tag associated with or located inside a metal object in a closed trunk. We want repeated, measurable testing—not one successful demonstration. False-positive and false-negative behavior should be measured and documented. Development Approach We are open to an engineer recommending that the project begin with a smaller technical validation milestone before proceeding with the complete prototype. For example, if the most difficult technical risk should first be proven through a focused RF/vehicle experiment, we would rather discover that early than spend substantial money building the remainder of the system around an unproven assumption. We value engineers who identify technical risk before writing large amounts of code. Testing and Acceptance The project will use defined milestones with written pass/fail acceptance criteria agreed upon before each milestone begins. The engineer will be responsible for development testing. Before submitting a milestone as complete, the selected engineer should provide, as appropriate: • Test performed • Expected result • Actual result • Measurements • Number of repetitions • Pass/fail result • Known limitations • Demonstration video where appropriate Customer testing will be acceptance testing. It should not be the first time basic development problems are discovered. Complete Technical Handoff At project completion, we must receive everything necessary for another qualified engineer to independently continue development. This includes, as applicable: • Tag firmware/source code • Hub firmware/source code • Dashboard software/source code • iPhone application project/source code • Build and configuration files • Programming instructions • Wireless protocol documentation • Hardware specifications • Bill of Materials • Location-system documentation • Test reports/results • Setup and operating documentation • Other necessary technical/project files The project must not become dependent upon one individual engineer. What Is Not Required at This Stage This project is currently focused on proving a reliable consumer prototype. Unless specifically recommended and separately agreed, this phase does not require: • Final production PCB design • Final industrial design • Injection-molding tooling • FCC/regulatory certification • Production manufacturing setup • Mass production Those may become later phases after the core product architecture has been validated. Proposal Requirements Please provide: • Your recommended overall technical approach • Any major changes you would make to the apparent architecture • Estimated development schedule • Proposed milestone structure • What would be demonstrated/tested at each milestone • Your independent fixed-price quotation • Estimated prototype hardware/component costs • Any portion requiring another specialist Please do not simply tell us that you can complete the project. We are particularly interested in understanding how you think about the technical problem. The budget displayed on Upwork is a planning estimate only. Please submit the price you independently believe is appropriate. Selection will be based on technical capability, engineering judgment, relevant experience, testing methodology, consumer simplicity, schedule, communication, and cost—not simply the lowest bid.