Compatibility Testing Method
Why we publish our test method
We run "device compatibility testing" — taking intimate devices on the market and testing whether the FeiEgg app can connect to and control them.
Without a description of the method, readers cannot judge the credibility of such test reports. So we publish the pass/fail criteria, the test environment and the limitations in full, so you can reproduce the tests yourself and challenge our conclusions on that basis.
A test report is not a partnership statement, nor a product recommendation. A report states only "what results we obtained with a Bluetooth test at a specific time, on a specific app version and a specific device firmware". It does not assess a device's quality, design or value for money.
Test environment and preconditions
| Item | Explanation |
|---|---|
| Test client | A phone with the FeiEgg app installed (one iOS, one Android) |
| App version | Each report states the specific version number |
| Connection method | Bluetooth 5.0 |
| Source of test devices | Purchased by us, or submitted by the vendor |
| Test location | Ordinary indoor environment (not a shielded laboratory) |
| Repetitions per test | At least 3 times, taking the consistent result; inconsistent results are recorded honestly as variation |
Known limitation: our environment is not a laboratory. Bluetooth behaviour is affected by phone model, system version and surrounding 2.4GHz interference (WiFi routers, microwaves, other Bluetooth devices). Latency and stability figures in a report are therefore indicative of order of magnitude only and cannot be treated as absolute metrics.
Pass/fail criteria
Judged level by level along the connection chain, and every level must be measured:
Level 1: Device discoverability
| Result | Verdict |
|---|---|
| Appears in the FeiEgg app's Bluetooth scan list | ✅ Discoverable |
| Visible in system Bluetooth settings but not in the app | ⚠️ Partially discoverable |
| Not found by any scan | ❌ Not discoverable |
Level 2: Connection establishment
| Result | Verdict |
|---|---|
| Pairs and holds the connection for ≥ 60 seconds without dropping | ✅ Connectable |
| Pairs but drops frequently (≥ 2 drops within 60 seconds) | ⚠️ Unstable connection |
| Pairing fails | ❌ Cannot connect |
Level 3: Basic control
Test the following control capabilities item by item, recording whichever ones can be tested:
- Power on/off
- Vibration / operating-mode switching
- Intensity level adjustment
- Heating control (if the device has that hardware)
- Remote control (if that function exists)
Level 4: Response behaviour
| Metric | How it is measured |
|---|---|
| Command latency | Time from tapping in the app to the device responding, graded subjectively (immediate / slight delay / noticeable delay) |
| Connection stability | Continuous operation for 10 minutes, recording the number of drops |
| Effective range | Walking away step by step, recording the distance at which the connection drops (ordinary indoor environment) |
The four possible conclusions
Every report's conclusion falls into exactly one of these four:
| Status | Meaning |
|---|---|
| 🟢 Fully compatible | All four levels passed and every basic control item can be performed |
| 🟡 Partially compatible | Connects, but some control items cannot be performed (specified item by item) |
| 🔵 Discoverable, not adapted | Discoverable over Bluetooth, but no standard protocol characteristics were recognised; usable once the device side performs adaptation |
| ⚪ Testing not completed | Test conditions could not be met (e.g. the device needs a proprietary charger, cannot be powered on), with the reason recorded honestly |
"Adaptation required" does not equal "the device is faulty". In most cases the device uses a proprietary Bluetooth protocol and integration requires the manufacturer to adjust firmware or provide protocol documentation. This is a technical adaptation issue, not a product-quality issue — we distinguish strictly between the two in our reports.
Disclaimer and correction mechanism for reports
Every report ends with the following statements:
- Results apply only to the specific conditions: the results under the App version, device firmware version and test date listed
- Manufacturers may request a retest: if a manufacturer considers the test result inaccurate, they may contact us to arrange a retest,
and the retest result is published alongside the original, without deleting the original report
- No quality assessment: this test covers only Bluetooth connection and control capability, and assesses no other aspect of the product
- No recommendation implied: brands appearing in this testing do not, by virtue of the test result, constitute a recommendation or endorsement by FeiEgg
Point 2 is a self-imposed constraint: the original report is never deleted, and retest results are published side by side. This is the precondition that makes a test report credible — otherwise it becomes selective publishing.
How manufacturers submit devices for testing
If you are a device manufacturer and would like us to test your device:
- Contact us through the partnership entry point on the official site, stating the device model and the Bluetooth solution
- We confirm whether we can meet the test conditions
- Once the device arrives, we schedule the test and issue a report
- Submitting a device costs nothing, and does not mean we will give a positive conclusion — the result is issued honestly
Contact details for submissions are in the Factory Partnership FAQ.
Related Pages
- Compatible Devices List — summary of results for tested devices
- Devices & Connection — how FeiEgg connects
- Factory Partnership FAQ