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.
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.)
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 (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.)
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 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 datasheet.) – watch the cell/voltage pack reading unless you are sure you did configure it properly for Li-Po
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)
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.
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 upgrade and can upgrade/downgrade firmware regardless existing of version. You should NOT attempt to use “avrdude”, “winavr” or “avrdudess”, or any other tool/commands 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.
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, 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.
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)
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).
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:
FLIR ONE, a nice product, with 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 force an upgrade.
Goals: 1: remove the need for battery and charging. 2: replace the MicroUSB with USB-C
Tools: You will need one security T5 (Torx5 with a hole in the middle)
Using a Dremel multi-tool, I expanded the slot it the black connector retainer and the main body. Using adapter (2): after de-soldering it’s female MicroUSB – I glued the USB-C connector inside the black retainer using epoxy.
Assemble, throw away battery.
There is no more need for charging or switching on the device. Also, it does not run out of juice after 5 minutes anymore 🙂
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
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.
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.
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.
The solution is to remove D3, which provides power to the pull-up, then the laser will not be “default on” anymore.
There are many photos showing of damage around lifting points due to misaligned, or missing jack pads.
Tire shops are very sloppy about it. And to make your average garage jack lift it correctly, requires fine placement.
My jackpad, is made using 3cm high quality , industrial rubber sheet from Dunlop.
Then I add an Thermoplastic polyurethane part, that makes sure it can only fit one way,(the correct way) to the jack pad.
Finally, some strong neodymium magnets will hold it in place, while you place the garage jack under.
Simple, easy, convinient.
Once you get familiar with it, and where the jackpoints are, you don’t really need to look under the vehicle. Just move it around till it snaps into the spot.
Now the garage jack can be placed roughly beneath, and will still lift the car exactly as supposed, not touching anything else.
The massive natural rubber will most likely last longer than the Tesla, the magnets/mount, however, could be destroyed. So it needed a clever, collapsible design:
Update: As of Arducopter 4.0.0 for Solo, the motor slew rate is available, and this mod is NOT required if you are happy to use slew rate.( which gives a little less responsive copter, lust like the original 3DR fix.)
3DR Solo Cube (Pixhawk 2.0) outputs 3.3v PWM, the IO buffers run off 3.3v on both sides, while they are perfectly capable of delivering 5v. Using 5v is safer when using 3DR Solo firmware with PWM slew rate, and required for ArduCopter code on Solo.
The simple solution is to purchase “Green cube” (usually sold out) or modify Pixhawk 2.1
The alternative solution, is to modify Solo’s Pixhawk 2.0 Cube.
This does require some soldering skills, and can be done by any semi-decent repair shop if you cannot do it yourself.
(The width of the buffer chip is 4.5mm)
The two first images show two different PCB layouts of the Pixhawk 2.0 cube, so everybody should recognize, and stick to one 🙂
Open the cube, and locate the rightmost buffer ic. (TXS0108E marked YF08E)
Desolder the buffer (here seen on another PCB layout):
Cut the trace that feeds the upper left pad:
Re-solder the buffer:
Attach a thin wire to the pin. (provide 5v to the buffer’s VccB)
The other end of wires are routed to the clearly labelled 5v pad in the upper right corner of the Pixhawk2.0 :
Finally, clean and cover wire using conformal coating, to prevent vibrations to damage it: (UV inspection below)
Congratulations, output 1…8 output is now 5v.
Final note: the UV inspection picture picture shows another buffer, not used for PWM, the photos are taken on different occasions, and while batch processing many, not only one, so the time is not 30minutes between desolder and resoldering one device as timestamp may suggest.
Should you use a professional to do this job, it should take <15 minutes.
Modified files for uploading using Solex (Just copy into /Solex/download/package) – The only modification is to make Solex ignore the fact that the modified cube still runs the old 3DR fork of ArduCopter.
Once you upgrade to the 3.5.2 I provided here, you can continue to upgrade to newer versions using SSH /Solex and/or OpenSolo as if you had the greeen cube.
firmware upgrades for all (and no incompatible versions)
Buy boxed version ($35 +worldwide Shipping $4)
In stock, shipping next day, as usual.
3DR Solo battery packs have lots of information that the average user will never see, they are also very nicely calibrated for voltage (cells and pack) as well as current.
Some of the information, like capacity, cell voltages, cycles, past low voltage condition, cell voltage difference, and manufacture date may be very useful.
Health data is very useful as well.
Below: two devices, one as delivered, the other with an XT60 connector for charging.
It’s easy to solder on XT60, charger cables, or other connectors right on the main connector. The XT60 is there just for illustration purposes, it’s easy to solder on most of the typical connectors (XT60, EC3) directly, the rest can be soldered on with wires.
“Hard” edition means it comes in a nice case designed by Purplemon on Thingiverse:https://www.thingiverse.com/thing:2841916
The device is not doing any calculations on it’s own, data is read from the battery, and presented.
Values and information details:
Pack Voltage Charge level in % Remaining capacity Internal temperature. Charging current. (Negative value indicate discharging current)
Cell voltages for cell 1…4 – should be self-explaining, any healthy pack will have very similar voltages after a flight. Design capacity is what the pack was designed to be. Actual capacity is shows the actual capacity as the pack ages. Relative charge level is based on actual capacity of the pack. Absolute charge level is based on design capacity of the pack.
Manufacturing date in Y-M-D format. Made by BMTPOW The device name is MA03, serial number follows (not the same as the barcode on the pack) TTF: Time To Full, if not charging, will display “-1” Cycles: how many times have this pack been used. This is increased when discharged_capacity_since_last_increase > design_capacity.
The status word is bitmapped at least two bits we know are used, one indicating charging/discharging, the other tell if the factory calibration data is OK.
Should factory calibration data ever be corrupted, then you can never know if a reported voltage/current (used for capacity calculation !) is correct, and it’s dangerous to fly with such a pack. A very clear warning will be displayed.
Firmware >=1.5 say “Initialized” when BMS is calibrated&configured properly, or “NOT” initialized” if not.
There is also a warning for internal resistance deviation. There is a “Cell Change” warning, I do not know what can cause it, or what exactly it means – both warnings above are for illustration purposes, I have no packs with such condition.
Status is expected to be 128(charging) or 192(discharging) , 16608 is a fully charged battery. (Thanks to Bob that found that).
Since firmware 1.5, status understanding is much better, and most data is presented as text.
Health is 18 for all good packs (I do not have one that is bad) , but there are 16bit of data that can indicate quite a lot…
I’ll update this page based on user reports.
Lowest voltage record. – Displays eight last low voltage records, some values are initialized as 3.5v, but it is the lowest values that indicate if the battery has ever been close to deep-discharge.
If the battery pack is connected, but not charging – after 180seconds, the DONE message will show, two minutes later the battery will switch off. (Shutdown feature is inhibited at any time by pressing battery button to toggle screen.)
This dataset is being outputted to FTDI interface at 115200baud, one at 1hz. The device will not go to sleep once you used the battery button to select an screen.
This allows for nice graphing of charging/discharging, and full monitoring using DataExplorer with the plugin I’ve made: Solo_Batt_Tool
Of course, you are free to do whatever logging you wish, the format is basically semicolon delimited, and temperature, cell voltages are multiplied with 100/1000 so you don’t need to parse thru commas.
Plug into battery , switch on battery. or: Plug into battery , and provide charging current. You can use any standard charger, select Li-Po 4cell program with no balancing (the battery have internal balancing circuit)
There is an custom bootloader on the device, so when I figure out more about the battery, it’s possibly to upgrade it using a standard FTDI cable and the avrdude tool (for Linux,Mac,Windows).
FTDI cable, with an extra pin header.
Insert pin header into FTDI cable, the protruding, short pins will fit into the SoloBatt_OLED’s six pins on the edge of the PCB. You will need to cut away or puncture a little bit of shrink-wrap to access the edge.
The upper & lower of the six pins on PCB are marked BLK (black) and GRN(green) – make sure that matches the orientation of the FTDI cable. (reversing does no damage)
Observe that there are two files in the firmware package:
“VG” is for displays with pin order: “VCC, GND, SCL, SDA” “GV” is for displays with pin order: “GND, VCC, SCK, SDA”
To write the new firmware you will need the avrdude application.
On Linux, it’s installed by: “sudo apt install avrdude”
/dev/ttyUSB0 is most likely correct, the number will be higher if you have more than one USB serial device
If you are using windows, replace /dev/ttyUSBx with COMx , also, in windows, you’ll need some FTDI drivers.
Please note that the programming protocol is Arduino compatible just enough to make it work with avrdude, but it’s not really Arduino.
Longer auto-off delay (was 2min , now 4min)
Longer time per screen 3s->6s
Serial output using FTDI cable at 115200 baud
Warning if the battery has detected uneven internal resistance.
Warning named “change cell” (not sure when that is supposed to kick in)
Low voltage records.
Three digits in cell voltages.
Fahrenheit & Celsius temperature.
Serial logging for Dataexplorer plugin (and any other data collection).
Shorter splash screen timeout.
Cosmetic fix for long status numbers on OLED display.
manual page flip. lets user skip forward to a certain page, and stops automatic rotation. (connect a momentary switch between pin8 and pin9 – or – if you are using a microcontroller , just pull pin9 low.)
Found out more about battery status, and presenting it as text. , among others, you may see “Fully Charged”, “Fully Discharged”, “Charging”, “Discharging”, “Initialized” “NOT initialized”, “Term.Disch.Alarm” and “Terminate Charge”
The old status “Calibrated” is now replaced by “Initialized” – which means not only that the voltage/current sensors are calibrated, but also that the BMS is configured for proper operating limits and parameters. A “NOT initialized” battery means improperly set/default BMS configuration.