MAVLinkPFD User manual

Interface Overview

  1. Flight Mode & Status: Located top-left. Displays current state (e.g., AUTO). Displays also the state of Safety or Arming.
  2. Speed Tape: Shows Indicated Airspeed (IAS). Long boxed areas represent stall speeds; checkered areas indicate overspeed limits. Units are selectable.
  3. Altitude Tape: Displays current altitude. Units can be m/s or feet.
  4. Artificial Horizon (AHI): Central attitude indicator. Features a pitch ladder (horizontal lines) and a fixed aircraft symbol to show relative pitch and roll.
  5. Bank / Roll Scale: Displays the current roll angle. The moving triangle (pointer) indicates degrees of bank.
  6. Slip/Skid Indicator: Small bar below the bank pointer.
  7. Heading Indicator: A compass rose showing degrees (e.g., 165).
  8. Battery & Power Status: Top-right. Shows Voltage (V), Power (W), and Throttle percentage. Blinks during low-voltage, faster during critical voltage.
  9. GPS / RTK Status: Bottom-left. Displays fix type (e.g., RTKFLT) and satellite count (e.g., 18), flashes in case of GNSS loss.
  10. Wind Indicator: Shows wind speed and an arrow representing direction relative to the current heading.
  11. Rangefinder Altitude: Displays precise distance to ground if a Radar,LiDAR or sonar sensor is active.
  12. Home Indicator: Indicates distance and bearing back to the launch/home point.

Detailed Feature Descriptions

1. Speed & Altitude Tapes

The tapes are dynamic vertical scales.

  • 13: Ground Speed (GS): Displayed numerically above the speed tape.
  • Target Bugs: Visual markers on the tape indicate set cruise speeds or target altitudes.

2. Navigation Display (Active Flight Plan)

When a navigation is active, the following elements appear:

  • 14: Flight Director (FD): Crosshair or bar symbols on the AHI guiding the pilot to the target path.
  • Waypoint Info: Bearing and distance to the next waypoint are displayed as overlays.

3. Connection & Safety Alerts

  • MAVLink Status: If the data link is interrupted, a prominent “MAVLink lost” warning appears in the lower right with a disconnection timer.
  • App Status: Similar warning for the mobile/tablet application connection.

4. Hardware Monitoring

  • 15: Device Battery: The UI includes icons for the battery level of both the Rokid Glasses and the connected telemetry phone/tablet.
  • Status Log: The bottom area (not shown in snippet) scrolls STATUSTEXT messages from the Flight Controller, providing real-time diagnostic feedback.

Alerts and Notifications

The system provides both audible and visual alerts. The list below describes each alert, what triggers it, and whether it applies to copters, planes, or both.

Audible alerts

Stall alert
A repeating stall warning sounds when indicated airspeed drops below the configured stall-speed threshold. This alert is only active when the aircraft is armed, receiving MAVLink data, and in the air. On VTOL aircraft, it is only used in fixed-wing flight states.
Applies to: Planes only

Overspeed alert
A repeating overspeed warning sounds when airspeed rises above the configured overspeed threshold. The current implementation does not limit this by vehicle type.
Applies to: Copters and planes

Bank-angle alert
A repeating bank-angle warning sounds when aircraft roll exceeds the configured bank-angle threshold. It is only used for aircraft identified as planes, and only while airborne. It is suppressed if stall or overspeed alerting is already active.
Applies to: Planes only

Battery low
A spoken “Battery low” warning is issued after battery voltage has remained below the low-voltage threshold for 4 seconds. It repeats every 30 seconds while the condition continues.
Applies to: Copters and planes

Battery critical
A spoken “Battery critical” warning is issued after battery voltage has remained at or below the critical-voltage threshold for 4 seconds. It repeats every 30 seconds while the condition continues.
Applies to: Copters and planes

GNSS lost / GNSS fix restored
A spoken warning is issued when GPS quality drops below a 3D fix, and another spoken notification is issued when 3D-or-better fix returns.
Applies to: Copters and planes

MAVLink lost / MAVLink restored
A spoken warning is issued if MAVLink telemetry stops arriving for about 2 seconds, and another spoken notification is issued when telemetry returns.
Applies to: Copters and planes

App connection lost / App connection restored
A spoken warning is issued if the HUD/PFD app stops acknowledging forwarded packets for about 2 seconds, and another spoken notification is issued when the connection returns.
Applies to: Copters and planes

Arming / Disarmed
The system speaks when the aircraft arms and when it disarms. On disarm, it also speaks the total armed time.
Applies to: Copters and planes

Safety on / Safety off
The system speaks when the safety-switch state changes.
Applies to: Copters and planes

Flight mode change
The system speaks the new flight mode whenever the reported autopilot mode changes.
Applies to: Copters and planes

Speed callouts
The system can speak rounded speed values while below a configured speed threshold. In MAVLink mode, this only happens while the aircraft is armed and in the air.
Applies to: Copters and planes

Altitude callouts
The system can speak rounded altitude values while below a configured altitude threshold. The altitude source may be relative altitude, rangefinder altitude, or absolute altitude depending on configuration. In MAVLink mode, this only happens while the aircraft is armed and in the air.
Applies to: Copters and planes

Demo or trial reminder
In trial mode, the system periodically speaks a reminder message while armed.
Applies to: Copters and planes

Visual alerts and notifications on the HUD

Battery caution
The top-right battery, power, and throttle field slow-blinks when battery voltage is below the configured low-voltage threshold.
Applies to: Copters and planes

Battery critical
The same top-right field fast-blinks when battery voltage is at or below the configured critical-voltage threshold.
Applies to: Copters and planes

GNSS caution
The lower-left GPS status field slow-blinks when fix quality is below 3D.
Applies to: Copters and planes

Flight mode, safe, and disarmed indication
The top-left field shows the current flight mode. When the aircraft is disarmed, the label is prefixed with SAFE: or DISARMED:.
Applies to: Copters and planes

Status-text messages
Incoming MAVLink STATUSTEXT messages are displayed in the long status-text area and retained in recent history.
Applies to: Copters and planes

Demo or trial banner
In trial mode, a reminder message is shown in the long status-text area and added to history.
Applies to: Copters and planes

Test-data indicator
When manual test data is being used instead of live MAVLink telemetry, the top-right field shows TEST DATA with a slow blink.
Applies to: Copters and planes

Android system notification

MAVLink Relay Active
On Android, the app may show a persistent foreground-service notification labeled MAVLink Relay Active while background MAVLink relay is running. This is a system-status notification, not a flight alert.
Applies to: Copters and planes

Notes

Stall alerting is intentionally plane-only. Overspeed alerting is currently not vehicle-filtered, so it can trigger on either copters or planes if enabled and the configured threshold is exceeded.

The HUD also supports visual emphasis codes in incoming text fields: solid invert, slow blink, and fast blink. These are used internally for attention-grabbing status and caution displays.

Privacy Policy for MAVLinkPFD

Last Updated: March 17, 2026

1. Overview

MAVLinkPFD (the “App”) is designed to function as a Primary Flight Display using the MAVLink protocol. We value your privacy and believe that your flight data belongs to you. This policy explains our stance on data collection and privacy.

2. Information Collection and Use

MAVLinkPFD does not collect, store, or transmit any personal information or flight data.

  • No Personal Data: We do not collect names, email addresses, or contact information.
  • No Flight Tracking: The App processes MAVLink data packets locally on your device to display flight telemetry. This data is never recorded by the App or sent to the App author or any third party.
  • No Location Tracking: While the App may display GPS coordinates provided by your flight controller, it does not track or store your location history.
  • No External Transmission: The App does not communicate with any external servers. All data processing happens entirely “on the edge” (locally on your device).

3. Permissions

The App may request certain permissions (such as Bluetooth or Network access) solely to facilitate the connection to your MAVLink-enabled hardware (e.g., telemetry radios or flight controllers). These permissions are used strictly for real-time display purposes.

4. Third-Party Services

The App does not use third-party analytics, advertising networks, or tracking SDKs (Software Development Kits). There are no “hidden” cookies or trackers.

5. Data Security

Because we do not collect or store any data, there is no risk of your personal information being compromised from our systems. Your flight data stays within your local hardware environment.

6. Changes to This Policy

We may update this Privacy Policy from time to time. Any changes will be reflected by the “Last Updated” date at the top of this page.

7. Contact Us

If you have any questions or suggestions about this Privacy Policy, do not hesitate to contact the author at: support@madhacker.org

Adding Zigbee to a common smoke detector.

he Chinese brand Kingdunalarm has produced the LM-101LG for years. These detectors have been imported into the EU since at least 2013, often marketed under names like No-Flame and Nor-Tec. It is a reliable, linked optical smoke and heat detector, making it a good candidate for this modification.

This modification adds Zigbee compatibility, allowing you to receive a notification whenever the alarm sounds. This can be triggered either by its own sensors or by a test button signal forwarded from another linked alarm.

For this modification, I am using a Tuya ZG-102ZL Door/window hall-effect sensor.
https://www.zigbee2mqtt.io/devices/ZG-102ZL.html

This is the modified ZG-102ZL. The Hall-effect sensor connects where the white wire goes (you’ll need to desolder the original sensor)

This is the smoke detector’s PCB:

Red wire goes to Tp11.
White to Tp12.
Blue to ground.

A suitable spot for the Zigbee device (I’ve desoldered its battery holder):

Customised view in Home Assistant:

BMSOne 2 – Universal 2S-6S BMS for ArduPilot

BMSOne (4S) $42 [wp_DISABLEDcart:BMSOne-4S:price:42:shipping:4:end]

BMSOne (5S) $42 [wp_DISABLEDcart:BMSOne-5S:price:42:shipping:4:end]

BMSOne w/XT60 $47 [wp_DISABLEDcart:BMSOne-6S:price:42:shipping:4:end]

20cm balancing cable JST-HX $1 [wp_DISABLEDcart:Balancing cable:price:1:shipping:0:end]

[show_wp_shoDISABLEDpping_cart]


THIS PRODUCT IS ONLY AVAILABLE THRU https://jonbrotherton.fws.store/product/bmsone-v2-plug-and-play

Description:

This device is not limited to 3DR Solo, but build to work with any 2S-6S battery and ArduPilot.

Provides a realistic state of charge and individual cell voltages.

3DR Solo can use any Li-xx battery in 4S to 5S configuration. (The Solo gimbal is not compatible with 6S)

The PCB is less than 50x40x9mm (the balancing connector is the highest component) The weight is only 7.9g

The device in 4S, 5S, and 6S configurations is exactly the same, fully populated with all components. The only difference is the balancing connector.

Super-Simple, Plug & Play version:

If you dislike configuration, finding a suitable battery, etc.. please see the super-user-friendly version made by some nice people at: https://jonbrotherton.fws.store/product/bmsone-v2-plug-and-play
Basically: It gives you a simple plug-and-play solution, none of the setup/configure/install/mount stuff.

4-6S Support with older ArduPilot:

The older ArduPilot and Solo support 4S batteries.
If you connect BMSOne with 5 or 6 cells to an older ArduPilot it will automatically spoof a 4S battery consisting of four of your lowest-voltage cells – while providing the full 5/6S voltage of your pack.
This way, it is perfectly backward-compatible, and safety is maintained by always reporting the lowest cells.

4-6S Support with newer ArduPilot:

Newer ArduPilot can use the 4-6s capability of BMSOne.
You will see all cells.


This is the BMSOne:

The backside. B+/− is where you connect the battery, if you do not use a Solo power connector, (or not a Solo) – then the output is +/- and SDA/SCL is clearly labeled.

Old hardware 2.3 to the left, and 3.1 (Current version) to the right.

Configuration:

Configuration, like firmware updates, is done using the USB-C port.
Configuration commands in BOLD:

When you connect to it at 115200kbps, (8N1) and power it up, you will see:
BMSOne v2.0
Set the capacity of the battery in mAh using the command:
SM10000
it will respond:
Set capacity: 10000
Now, you have defined a 10Ah full capacity.

The device can provide remaining capacity information based on one of the methods:

S0 //remaining capacity is estimated based on voltage.
S1 //remaining capacity is reported based on mAh consumed (assumes you start with a fully charged battery of defined capacity on boot)

S! // No thermistor, fake 22.5°C temperature
SH //100K Thermistor
SW //write configuration to flash – until you do this, all your changes/calibration are temporary and can be reverted by rebooting the device.

SN //Use new Protocol (up to 6S)

SO //Use old protocol, 4S – you can still use 5S/6S batteries, but only 4 lowest cells will be listed, and BMS will emulate a 4S battery.

SR //read config from flash (it happens on every boot)
SS //Prints voltage and percent tables, capacity values, thermistor and protocol settings.
SD //Show internal data,  rints ADC readings, cell multipliers, pack voltage, temperature, current, etc.

S~ // erase EEPROM (reset the configuration to firmware defaults/factory reset)

ST // invert current multiplier

On hardware >2.x:
SWx / SRx //Write bank (x) 1-3 and save to bank 1-3
SW! // Write current config to all banks.

S# // Reboot MCU

Displaying Configuration:
Voltage table: 104, 110, 113, 116, 119, 122, 126, 129, 132, 135, 138, 142, 145, 148, 168,
Capacity table: 0, 4, 12, 20, 29, 37, 45, 53, 62, 70, 78, 86, 95, 99, 100,
SoC by Voltage
Cell voltages(mV):3727,3731,3739,3744
Pack voltage(mV):14941
Current (mA):-152
Full capacity: (mAh)10000
Remaining capacity by Voltage: (mAh)9900
Remaining capacity by Current: (mAh)10000


Calibration procedure.

Important: since September 2023 each device is calibrated individually prior to shipping, do not calibrate, or use S~ command unless you plan to do the calibration.

With a battery hooked up, you can measure its cells, then provide a command like this: the numbers are voltages in millivolts.
let’s say you measured 3.256v, 3.231v , 3.255v and 3.263v then enter:
SC3256,3231,3255,3263 // calibrate cell voltage in millivolts for 4 cells.
If you can’t measure with 3 digits, – let’s say you can measure with lower precision “3.21v” then enter “3210”

SI10220 //Calibrate current sensor, value in mA “SI10220” = 10.220A
Again issue the command with a known current flowing through the device. It is better to calibrate while sensing 10A than 100mA.

SJ<value> // set current multipler directly, foe example: SJ-30.5 (set Imul = -30.5)

Capacity by voltage linearization table:

For Li-ION:

SV 10.4, 11.0, 11.3, 11.6, 11.9, 12.2, 12.6, 12.9, 13.2, 13.5, 13.8, 14.2, 14.5, 14.8, 16.8 //set 15-point percent linearization table
SP 0, 4, 12, 20, 29, 37, 45, 53, 62, 70, 78, 86, 95, 99, 100 //sets 15-point percent table.

So by the example above 11.3v (third value) equals to 12% , (while 11.5v will be interpolated to a little less than 20%.

For Tattu 4S1P 5200mAh 35C

Thanks to Gary Pang’s generous donation of such battery, here is a configuration for this battery:
S0
SV 14.0, 14.1, 14.2, 14.3, 14.4, 14.5, 14.7, 14.8, 14.9, 15.0, 15.2, 15.3, 15.8, 16.0, 16.8
SP 0, 8, 21, 27, 41, 49, 57, 64, 72, 80, 85, 88, 98, 99, 100
SM5200
SW

ArduCopter 4.x battery safety settings:

These settings are for ArduCopter 4.x , which you should be using with OpenSolo 4.0 or newer. The BMSOne does work with OpenSolo 3 and AC3.6.x too, but it does not work with the original, old, forked 1.5.x versions of the autopilot, (nor should you fly the old versions)

If you use S0 mode(default), set low and critical-voltage thresholds:
BATT_LOW_VOLT
BATT_CRT_VOLT
If you use S1 mode(capacity based), also set low and critical-capacity thresholds:
BATT_LOW_MAH
BATT_CRT_MAH
Finally, these parameters define what action is taken:
BATT_FS_LOW_ACT
BATT_FS_CRT_ACT

SoC Voltage mode explained:

S0 = State-of-Charge by Voltage
This mode is beautifully simple and reliable, as you can use any number of battery packs, with the same type of cells, and have perfectly fine SoC estimation (see battery percentage drop)
The advantage of this mode is that it works by voltage under load, so you can have one BMSOne and any number of packs, and any state of charge on those, and still, it will “just work”

We all remember how fast the remaining capacity drops on a Solo battery at the end, 20% can fall to 3% within one minute.

The first graph is made using these packs’ first flight.
It estimates energy as consumed a bit fast in the beginning, then just a little faster after 19/20 minutes.

Then the voltage/capacity table is corrected.. and watch the second graph, beautiful linear estimation, no surprises there even as the battery gets to 2.5v/cell.

Another aspect of SoC by voltage is that it is most accurate when at normal cruise/hover. During a fast climb, the voltage will drop, and while climbing, you will see a lower estimate, and during a fast descend, you will see a higher estimate.

21minute flight example:

(I flew in bad wind conditions, now I see that the flight had the 4.0.3 PID issue that surely affected the flight time in a bad way)
4S3P Samsung INR18650-30Q (12 cells) 620grams with BMSOne.
GoPro Gimbal with Gopro 4 Black. AUW 1950g
Cells bought from Banggood (please observe that this is not a referral link, I get no kickback, nor can I guarantee the authenticity of a later batch).

1297 sec (21min) long flight in light rain and 2-4m/s wind.
I landed at 2.6v/cell, yet the manufacturer’s datasheet use 2.5v as the cutoff.

How to make a linearization table:

Let’s say you have a battery with given chemistry that you want to charge to 16.8v max and fly down to 14.0v minimum voltage. None of the known tables work well for it.

On a day with calm or no wind, fly slowly or hover well out of ground effect.
Monitor the voltage of the individual cells and fly the pack down to the desired 0% state, for example, 14v.

The most important part is not to affect the discharge curve by hard flying or rapid climbs/descends. You want to see the pack’s normal voltage drop under normal load.
Get the log from the Solo, and plot BAT. Volt using APMPlanner2 or similar tools.

Now imagine, or draw some number of data points you want to read out, they can be spaced out by time on the x-axis, or better, you can increase density where the voltage is less linear as illustrated with red lines below:

Your first data point would be full pack voltage 16.8v, 100%
The next one, the voltage that is measured right after takeoff, you can see the voltage drop to 16.25v under a given load, but you know it is still full, so the next data point is 16.2v, 99%
The next data point may be read out at the second red line, 15.7v, and the red bar’s position, maybe for example 10% into the flight, – then the remaining capacity(flight time) is 90% – so the next data point is 15.7, 90%
several data points later you land at desired 14.0v … you end up making a final data point 14.0v , 0%.

Now let’s convert the data points to the table: x are points we did not bother to calculate in this example:

SV 14.0, x, x, x, x, x, x, x, x, x, x, x, 15.7, 16.2, 16.8
SP 0, x, x, x, x, x, x, x, x, x, x, x 90, 99, 100

Firmware upgrades:

To flash the new firmware you will need the avrdude application.
On Linux, it’s installed by: “sudo apt install avrdude”
The firmware upload command is:
avrdude -patmega328p -carduino -P /dev/ttyACM0 -b115200 -D -Uflash:w:BMSOne.2.0.hex :i

Windows users may need drivers and the avrdude application: http://download.savannah.gnu.org/releases/avrdude/avrdude-6.3-mingw32.zip and the firmware (download link below). Extract both firmware and avrdude to the same directory.
Then replace the “/dev/ttyACM0” in the example command with the “COMx” name of your serial port, and execute the command.

2.0 Initial release(named 2.0 in order to avoid confusion with BMSOne1.x)
– using 5S/6S spoof 4S for compatibility

BMSOne2.0Download

2.1: Supports up to 6S – Updated protocol provides all 6 to Ardupilot.
Cell count is auto-detected.

BMSOne2.1Download

For 3DR Solo, to see 5S/6S : upgraded ArduPilot

copter4.3.2SoloBMS-6SDownload

3DR Solo iMX6 as video and telemetry link

3DR Solo, have a great onboard computer, the IMX6 runs Yocto Linux : link to the Linux source: https://github.com/OpenSolo/imx6-linux

Among it’s best features is the HDMI-in, USB, and mini-PCIe port which can easily use rather powerful MicroTik router/Wi-Fi modules.

I reverse-engineered the remaining pins, as only the 3 and 6 pin headers were known to the community.|

Battery 7-24v, is the main power source.
+5v input does not seem to be essential for normal operation.
First USB host (D+,D-) is a normal USB2.0 host, compatible.
SEL(select) and OE(output enable) are two GPIO pins used by Solo to select where this USB host is connected: During normal operation the OE control if it is connected to any device (or not) and SEL controls if it is connected to the Cube (for firmware upgrade via bootloader) or the gimbal bay connector.

Unless you need more than two USB devices, you can ignore SEL and OE, and just use D+/D- for the USB host as usual.

Then there is the USB-OTG port. If you pull down the “Sink to GND…” pin, then the USB-OTG port becomes another USB host port. Otherwise, the USB-OTG port is in OTG mode, and will act as a slave/device – so that you can connect it directly to another host(usually a computer) This pin is not routed to anything on the Solo main board I tested.

The default onboard Linux is compiled only with FTDI and CDC-ACM (Communication Device Class – Abstract Control Model) profile, so it will instantly work with all kinds of Arduino/STM32’s that normally show up as a ttyUSB or ttyACM device.

DSM outputs a Spektrum RC control signal from the Solo Controller, it is optional to use it.

Finally, there is the usual RTS, CTS, RX, TX that is used for MAVLink telemetry, the hardware flow control is optional.

There is one more pin “not used by Solo” that is not routed anywhere, but on the iMX6 it is certainly connected to something, maybe another GPIO

As-Is, you can take out the iMX6 from a Solo, and use it and a Solo controller with any MAVLink source.
If no MAVLink stream is presented, everything else will still work, but the controller will auto-sleep after 10minutes or so. This could probably be easily fixed/changed in the controller’s software.

Simple desoldering of the Solo Battery Connector

Users of BMSOne can find it hard to remove the special Solo battery connector from a dead battery, this is a guide on how to do it, with a focus on simplicity.

No desoldering vacuum station, preheater, or reflow oven required. 🙂
Or: you can just buy it here (somebody else is selling, I am just providing the link for your convenience I am not paid to do so)

Safety First :

People are afraid of the dreaded thermal runaway, where the Lithium-Polymer/ion battery spew gasses & fire when shorted/damaged.

Basic physics tells us that the energy to do that, must be available, or else, there will not be smoke/fire hence:

Drain the battery – method 1:


Connecting a small 12v ,5-10W bulb to a bad battery (no reason to open it like I did in the photo below)

DO NOT think a 50W bulb will drain it better, it will make the voltage drop faster(and battery will switch off) – in the end , slower discharge is better.

In this case, I stuck the wires into the +/- connector. Switched on the battery, and let it sit on a concrete floor until it dies.

Drain the battery – method 2:

You may as well hover the Solo till it can’t fly no more, then let it be on until the battery dies completely

The BMS will fail to keep the FET’s on at somewhere around 5.7v or so, When the pack voltage falls that low, it will switch off, .. feel free to let it recover for a while then switch it on again..

When the battery is empty:

Solo Battery tool tells me that this battery is drained, no cell is even near 3.0v even an hour after it switched off
I have seen the voltage drop far enough to it to switch off more than once.
A properly drained battery, where all cells are low, do not have the energy to cause any fireworks, let me prove it to you.:

Opening the battery shell:

(will describe the process later – many have already done it.. if YOU did a video on it, feel free to let me embed it here.)

Extracting the connector:

I used an electronic hotplate, set to 300°C
You can use a cooking plate just fine.
The plate should not be red hot, let the PCB sit there for a few minutes, then start pushing the PCB down (so that the pins get a better thermal connection, and get pushed thru in the end.)


BMSOne – the universal BMS

This image has an empty alt attribute; its file name is BMSOne11top-2.jpg

This product is discontinued.
Version2 is here: https://madhacker.org/bmsone-2-universal-2s-6s-bms-for-ardupilot/

This BMS is very flexible and universal, you can fly any 4-cell battery chemistry/capacity that the Solo can handle in terms of voltage & weight, anything that produces 10-20v(I did not actually research/test Solo’s upper voltage limit)

The PCB is less than 50x40x9mm (the balancing connector is the highest component) The weight is only 7.6g

There are three mounting holes that should enable nice mounting inside the GPS bay (I did not test it, just measured it.)

It is very user-friendly, and requires very little prior knowledge about computers/serial communication to follow.

20 January 2020: Firmware 1.4
Verified support for Solo 1.3.1…1.5.4 – this firmware corrects a minor typo in 1.3 that prevented it from working on Solo 1.x.x as advertised thanks to the people behind a much more PnP version: https://jonbrotherton.fws.store/BMSOne_Plug_and_Play/p5973142_21044679.aspx

23 September 2020: Firmware 1.3-test.
This is not a release, because it does not do anything new for OpenSolo users, it does, however, respond to messages Solo 1.3.1…1.5.4 request – so if anyone flying those versions can confirm that it works – it will become a release.
There are no other changes in features/adverse side effects, only this additional code.
Another Bonus of that is that the Solo Battery tool can read the main voltage properly. 🙂

13 June 2020: Firmware 1.2 released. Thermistor was added for monitoring of battery temperature. All new devices are delivered with a thermistor.
All boards ver1.2 (with “Temp” input) can use a 100k NTC thermistor.
All boards ver1.1 devices can be modified with an NTC between GND and pin22 of the microcontroller, and a pullup resistor of 100k with a pullup to +5v.
I have also added some LED blinking.

16 Mai 2020: The first FIRMWARE UPDATE is out! (1.1) And I have published a configuration for Tattu 5200mAh battery (see below) – from now on, this will be the default configuration, as I have the impression that more people fly with Li-Po than Li-Ion.

Important information: (for devices shipped before 16 Mai 2020):The BMSOne comes configured for Li-Ion cells, (down to 2.5v/cell – check the datasheet.) – watch the cell/voltage pack reading unless you are sure you did configure it properly for Li-Po

Operation modes:

The device can provide remaining capacity information based on one of the methods:
S0 : remaining capacity is estimated based on voltage.
S1 : actual capacity reported based on mAh consumed (assumes you start with a fully charged battery of defined capacity on boot)

Firmware upgrades:

It can be fully configured using an FTDI cable (or any USB<>Serial cable with RX,TX and DTR signal- DTR is only used to enter the bootloader, and only useful for flashing, although it is possible to flash it without DTR too)

All firmware versions apply to all BMSOne hardware versions unless stated otherwise.

To flash the new firmware you will need the avrdude application.
On Linux, it’s installed by: “sudo apt install avrdude”
The firmware upload command is:
avrdude -patmega328p -carduino -P /dev/ttyUSB0 -b115200 -D -Uflash:w:BMSOne.1.1.hex :i

Windows users need drivers for the serial<>USB cable, avrdude application: http://download.savannah.gnu.org/releases/avrdude/avrdude-6.3-mingw32.zip and the firmware (download link below). Extract both firmware and avrdude to the same directory.
Then replace the “/dev/ttyUSB0” in the example command with the “COMx” name of your serial port, and execute the command.

Please note that the programming protocol is Arduino compatible just enough to make it work with avrdude, but it’s not fully Arduino compatible as a bootloader, (and much smaller).

Firmware 1.1: Perfectly nice interpolation and smooting.

With firmware 1.0, this would be a graphical representation of the spent percentage (SoC-by Voltage) with Li-Po , due to Li-Po’s low voltage range, the remaining % would jump a bit in certain areas.
With firmware 1.1 , the estimated SoC is very nice, less jumpy, maybe except for some flying I did, but very nice to watch in the display.

Firmware 1.1 also has some cosmetic changes in the terminal and comes with the Tattu 5200mAh 35C linearization curve as standard.
It will NOT overwrite your existing configuration. To apply Tattu /Li-Po defaults, look up Tattu further down on this article.

CAUTION: The bootloader is well tested, it handles interruptions in upgrades and can upgrade/downgrade firmware regardless existing of version. You should NOT attempt to use “avrdude”, “winavr” or “avrdudess”, or any other tool/command except those described above. The only known case of messed up bootloader reported to me for BMSOne or SoloBatt tool, was caused by experimenting with such tools.

BMSOne.1.1Download

Firmware 1.2 : Battery pack temperature sensor:

BMSOne.1.2Download

Firmware 1.3-test – should work with Old Solo v1.3.1…1.5.4

BMSOne.1.3-testDownload

Firmware 1.4 – Works with the old Solo v1.x.x

BMSOne.1.4Download

/


Super-Simple solution:

If you dislike configuration, finding a suitable battery etc.. please see the super-user-friendly version made by some nice people at: https://jonbrotherton.fws.store/JBBMSOne_Liion_Edition/p5973142_20662335.aspx
Basically: It gives you a simple plug-and-play solution, none of the setup/configure/install/mount stuff.

This is the BMSOne:

On top, balancing connector, FTDI(configuration) on the left, Solo connector on the right, with the option to solder battery wires directly.
The backside. B+/− is where you connect the battery, if you do not use a Solo power connector, (or not a Solo) – then output is +/- and SDA/SCL is clearly labeled.

BMSOne+XT60 connector

The Silicone wires are 5cm long (measured from PCB to where they enter the XT60)

You can extract the gray power connector from a dead battery: Instructions here: https://madhacker.org/simple-desoldering-of-the-solo-battery-connector/

Direct connection to Solo motherboard. Instead of moving a Battery-Connector the BMSOne, you can remove the Solo’s male battery connector, and just solder in the BMSOne permanently.

Plug’n’Play:

A few people asked whatever BMSOne is “plug’n’play”.
Yes, it is kind of that, the simplest job is done right out of the box, once you connect a battery thru it, you will see the battery, and cell voltage, which is the most important information.
To have a nice, linear, SoC based on voltage or current used, some configuration may be required, there is no “one setup fits all” configuration. (but the default is pretty much food for most Li-Po’s) This is the price of having one BMS, many batteries, vs having a dedicated BMS for each pack.

As you no longer have the shutdown signal from the battery, the GoPro will remain on after pulling the battery, so you need to switch it off manually.

Power for programming/configuration:

Hardware version 1.3 uses a diode, and the device can be connected to FTDI regardless of battery being connected or not. For calibration, +5V from FTDI should be disconnected.

Hardware version <1.3 have a solder-jumper “JP1” on the solder-side of the PCB.

If JP1 is open, just connect FTDI , and provide power from a battery (FTDI’s +5v is disconnected)
If you wish to do programming/configuration without a battery connected, solder a blob over JP1 then connect FTDI cable with +5v – it will power the device. – do not apply battery powered from FTDI.

Configuration:

Configuration, like firmware updates, is done over FTDI-adapter.
For configuration, any USB-Serial adapter will do.
You could use the typical 6-pin FTDI adapter, but you can also just connect a 3-wire adapter, using GND,RX,TX, while powering the device from a battery.

When you connect to it at 115200kbps, (8N1) and power it up, you will see:
BMSOne v1.1
Set the capacity of the battery in mAh using the command:
SM10000
it will respond:
Set capacity: 10000
Now, you have defined a 10Ah full capacity.

You can type:
S0 //Select voltage-based SoC (State Of Charge)
S1 //Select capacity-based SoC
S! // No thermistor, fake 22.5°C temperature
SH //100K Thermistor
SW //write configuration to flash – until you do this, all your changes/calibration are temporary and can be reverted by rebooting the device.
SR //read config from flash (it happens on every boot)
SS //Show config

Displaying Configuration:
Voltage table: 104, 110, 113, 116, 119, 122, 126, 129, 132, 135, 138, 142, 145, 148, 168,
Capacity table: 0, 4, 12, 20, 29, 37, 45, 53, 62, 70, 78, 86, 95, 99, 100,
SoC by Voltage
Cell voltages(mV):3727,3731,3739,3744
Pack voltage(mV):14941
Current (mA):-152
Full capacity: (mAh)10000
Remaining capacity by Voltage: (mAh)9900
Remaining capacity by Current: (mAh)10000


SD //Show internal data

You can also perform AD calibration.
When calibrating voltages/current sensor, it is important NOT to provide power from the FTDI connector. (otherwise, the precision will suffer.)
On the solder side of the PCB, there is a solder jumper “JP1” – to ensure a correct calibration, you can remove its solder blob – OR, simply disconnect the +5v pin from the FTDI connector.

With a battery hooked up, you can measure its cells, then provide a command like this: the numbers are voltages in millivolts.
let’s say you measured 3.256v, 3.231v , 3.255v and 3.263v then enter:
SC3256,3231,3255,3263 // calibrate cell voltage in millivolts for 4 cells.
If you can’t measure with 3 digits, – let’s say you can measure with lower precision “3.21v” then enter “3210”

SI10220 //Calibrate current sensor, value in mA “SI10220” = 10.220A
Again issue the command with a known current flowing through the device. It is better to calibrate while sensing 10A than 100mA.

Capacity by voltage linearization table:

For Li-ION:

SV10.4, 11.0, 11.3, 11.6, 11.9, 12.2, 12.6, 12.9, 13.2, 13.5, 13.8, 14.2, 14.5, 14.8, 16.8 //set 15-point percent linearization table
SP0, 4, 12, 20, 29, 37, 45, 53, 62, 70, 78, 86, 95, 99, 100 //sets 15-point percent table.

So by the example above 11.3v (third value) equals to 12% , (while 11.5v will be interpolated to a little less than 20%.

For Tattu 4S1P 5200mAh 35C

Thanks to Gary Pang’s generous donation of such battery, here is a configuration for this battery:
S0
SV14.0, 14.1, 14.2, 14.3, 14.4, 14.5, 14.7, 14.8, 14.9, 15.0, 15.2, 15.3, 15.8, 16.0, 16.8
SP0, 8, 21, 27, 41, 49, 57, 64, 72, 80, 85, 88, 98, 99, 100
SM5200
SW

ArduCopter 4.x battery safety settings:

These settings are for ArduCopter 4.x , which you should be using with OpenSolo 4.0 or newer. The BMSOne does work with OpenSolo 3 and AC3.6.x too, but it does not work with the original, old , forked 1.5.x versions of the autopilot, (nor should you fly the old versions)

If you use S0 mode(default), set low and critical-voltage thresholds:
BATT_LOW_VOLT
BATT_CRT_VOLT
If you use S1 mode(capacity based), also set low and critical-capacity thresholds:
BATT_LOW_MAH
BATT_CRT_MAH
Finally, these parameters define what action is taken:
BATT_FS_LOW_ACT
BATT_FS_CRT_ACT

SoC Voltage mode explained:

S0 = State-of-Charge by Voltage
This mode is beautifully simple and reliable, as you can use any number of battery packs, with same type of cells, and have perfectly fine SoC estimation (see battery percentage drop)
Advantage of this mode is that it works by voltage under load, so you can have one BMSOne and any number of packs, and any state of charge on those, and still, it will “just work”

We all remember how fast the remaining capacity drops on a Solo battery at the end, 20% can fall to 3% within one minute.

The first graph is made using these packs’ first flight.
It estimates energy as consumed a bit fast in the beginning, then just a little faster after 19/20 minutes.

Then the voltage/capacity table is corrected.. and watch the second graph, beautiful linear estimation, no surprises there even as the battery gets to 2.5v/cell.

Another aspect of SoC by voltage, is that it is most accurate when at normal cruise/hover. During a fast climb, the voltage will drop, and while climbing, you will see a lower estimate, and during a fast descend, you will see a higher estimate.

21minute flight example:

(I flew in bad wind conditions, now I see that the flight had the 4.0.3 PID issue that surely affected the flight time in a bad way)
4S3P Samsung INR18650-30Q (12 cells) 620grams with BMSOne.
GoPro Gimbal with Gopro 4 Black. AUW 1950g
Cells bought from Banggood (please observe that this is not a referral link, I get no kickback, nor can I guarantee the authenticity of a later batch).

1297 sec (21min) long flight in light rain and 2-4m/s wind.
I landed at 2.6v/cell, yet the manufacturer’s datasheet use 2.5v as the cutoff.

How to make a linearization table:

Let’s say you have a battery with given chemistry that you want to charge to 16.8v max and fly down to 14.0v minimum voltage. None of the known tables work well for it.

On a day with calm or no wind, fly slowly or hover well out of ground effect.
Monitor voltage of the individual cells and fly the pack down to the desired 0% state, for example, 14v.

The most important part is not to affect the discharge curve by hard flying or rapid climbs/descends. You want to see the pack’s normal voltage drop under normal load.
Get the log from the Solo, and plot BAT.Volt using APMPlanner2 or similar tools.

Now imagine, or draw some number of data points you want to read out, they can be spaced out by time on x axis, or , better, you can increase density where the voltage is less linear like illustrated with red lines below:

Your first data-point would be full pack voltage 16.8v, 100%
The next one, the voltage that is measured right after takeoff, you can see voltage drop to 16.25v under a given load, but you know it is still full, so the next data point is 16.2v, 99%
The next data point may be read out at the second red line, 15.7v, and the red bar’s position, maybe for example 10% into the flight, – then the remaining capacity(flight time) is 90% – so the next data point is 15.7, 90%
several data points later you land at desired 14.0v … you end up making a final data point 14.0v , 0%.

Now let’s convert the data points to the table: x are points we did not bother to calculate in this example:

SV14.0, x, x, x, x, x, x, x, x, x, x, x, 15.7, 16.2, 16.8
SP0, x, x, x, x, x, x, x, x, x, x, x 90, 99, 100

FLIR One: USB-C and battery mod.

FLIR ONE is a nice product, with an extremely limiting battery and bad software. (Luckily, third-party software is much better)

You may say the battery has two reasons to be there:
1: Limit useful time: pushing users to a more expensive product.
2: Obsolescence by design: become useless as the battery age and stops working.

Goals:
1: remove the need for battery and charging.
2: replace the MicroUSB with USB-C

Special tools: You will need one security T5 (Torx5 with a hole in the middle)

The original USB connector extracted from FLIR One
Fast mapping of the connections between USB and mainboard.
1: By heating the MicroUSB up, I removed it from the retainer.
2:USB-C OTG to MicroUSB adapter will be the donor for USB-C
3: This 4-pin motherboard connector will be re-used.

Using a Dremel multi-tool, I expanded the slot it the black connector retainer and the main body.
Using adapter (2): after de-soldering its female MicroUSB – I glued the USB-C connector inside the black retainer using epoxy.

Please note: A reader of this article told me that I got the D+/D- swapped in this post.
If what you do does not work: swap D+/D- (it’s harmless to swap them, but only the correct way will work)

The new connector in place, wires soldered to the motherboard connector.
Mainboard in place, observe the orange wire providing power where needed.
No more battery.

Assemble, and throw away the battery.

USB-C in place.

There is no more need for charging or switching on the device. Also, it does not run out of juice after 5 minutes anymore 🙂

Solo/Ardupilot SMBUS BMS

Latest progress:

See https://madhacker.org/bmsone/ – the resulting product.

13 January 2020:

It’s working as expected. (The balancing connector header had 2mm pitch on PCB (my bad), therefore, this test version got a wire.)

All Calibration/setup/programming and firmware updates are done over the FTDI header.

Please do not think much about the poor flight time I got during early tests, the cells had a bit too high internal resistance and produced heat/dropped voltage too much. Better cells could be used.

11 January 2020:

Preliminary documentation for configuration over Serial port (serial port is used for configuration and firmware updates):
Example commands in bold.

SC3256,3231,3255,3263 // calibrate cell voltage in millivolts for 4 cells.
Users can also omit any cell to if one-by-one calibration is desired for some reason, like SC,,3300, – this may be useful if calibrating by a single, precise voltage standard source.

SI10220 //Calibrate current sensor in mA “SI10220” = 10.220A

SV11.3, 11.7, 12.6, 13.3, 14.3, 14.7, 14.8, 15.7, 16.0, 16.2, 16.3, 16.4, 16.6, 16.7, 16.8 //set 15-point voltage linearization table

SP0, 5, 10, 15, 25, 45, 55, 79, 84, 88, 91, 94, 96, 98, 100 //set 15-point percent linearization table

SF9000 //set design capacity in mAh , here: 9Ah

GV //get firmware version
SW //write valibration/linearization tables to flash

5 January 2020: designed some initial PCB’s – now with individual cell measuring and current sensing.

(I hope to start selling them as a product before March 2020)

15 December 2019:

Currently handled I2C requests (all that Solo is requesting:)

0x08 TEMPERATURE
0x10 FULL_CHARGE_CAPACITY
0x1C SERIAL_NUMBER
0x0F REMAINING CAPACITY
0x23 MANUFACTURER_DATA
0x28 CELL_VOLTAGE
0x2A CURRENT

This is an early version of a BMS for any 0-5v/cell chemistry 4-cell pack for ArduPilot.

Right now, it is more correct to call it an BMS emulator, than a BMS.
A final product would measure individual voltages and the actual current. I started this way because it does not require a custom PCB and a minimum of discrete components.

This early version does handle all the communications, and makes the autopilot set the actual capacity (9Ah), reports voltage, and calculated individual cell voltages.


It does also calculate and report remaining capacity by doing a 15-point linearization and then interpolating a “voltage_to_capacity_table”. This method is good enough once one knows the battery characteristics and fly at about the same current later.

Test Flight1:

I did not wait for the 4S3P Li-Ion pack to charge fully. (Samsung 3Ah 18650-30Q cells) The outdoor temperature was about -5°C, batteries. Flight time was 17 minutes. With GoPro4Black + the brushless 3DR Gopro gimbal. The battery pack was 677gram. Included in that weight is 22gram that is the BMS microcontroller PCB, Solo battery connector and wires/connectors to battery.

The predicted SoC percentage (blue) is clearly not perfect (yet) it was good at the end, not at the beginning, but that is not a problem, as it is easy to change by modifying the table.

Notice that it can still climb at as low as 10.5v , not exceeding 70% of throttle.

Post-flight thermal image: (somewhat affected by some kapton tape on the battery pack.)

TODO / Future:

Given enough interest, I plan to make a fully standalone BMS that can be user-customized to any chemistry, (min/max voltages) and so on.
With balancing, real current sensing, fuel gauge etc.

SW-LD73 Laser driver modification.

This laser driver board seems to be common for many <20W LED lasers used for cutting/engraving.

Whenever powered on, it defaults to full power due to a rather strong internal pull-up.

Most CNC machines have a laser TTL PWM output that goes into high-impedance mode on boot. In that case, any connection to, or reboot of the microcontroller will make the laser output full power for about 2 seconds while the user may not be prepared for that.

D3, in the red ring, provides power for the pullup.

.

The solution is to remove D3, which provides power to the pull-up, then the laser will not be “default on” anymore.