NanoLongRange with integrated battery tray

DARWINFPV DRONE USING THIS DESIGN
It came to my attention that DarwinFPV sells the "18650 3-inch Micro FPV Drone" that resembles this particular design in many small details.
I believe this is a breach of a very liberal "CC-A" license this design is published under as
they have never contacted me on this matter and I haven't granted any permission to produce or sell this frame without attribution to anyone.
That said, I will not proceed with any takedown actions, this market is tiny and they make some competitive stuff. Just shame on you, DarwinFPV.

THIS THING IS OBSOLETE, SEE THE LATEST ONE HERE

Top part with the integrated battery tray is more rigid than the original so it may be printed a bit thinner and lighter while keeping overall stiffness. Short nylon screws may be used to keep top and bottom parts together as battery won't detach even if screws break in flight.

Mine is printed with CF Nylon, 0.4 nozzle / 0.2 layer, 2 bottom + 1 wall + 25% octet infill + 2 top (inc. 1 top skin) with slightly increased flow for walls and top skin and concentric pattern for initial bottom layer and top skin.
I've annealed the top part at the 130c for two hours in the oven.
It survived a few high drops on the maiden flight because of thermal shutdowns.
Battery terminals are taken from the aliexpress clone tray, other terminals may fit as well.

Bottom part is also a bit lighter and allows more airflow for ESCs and VTx but it is weaker than the original, I've made it mainly for slow indoors flights.

Overall weight savings compared to the original are about ~8-12g which is a considerable amount for a 100g quad.

THERMAL SHUTDOWNS BONUS PART
If you're experiencing temperatures >100C after a minute in air with Zeus5 FC then you've probably reflashed your ESCs. You may try to fix it by reflashing once more with any suitable firmware with a higher deadtime (e.g. S_H_120. JESC, JazzMaverick or Bluejay have such builds, there's also my build of vanilla blheli_s in the thread linked below).

If you're building your own firmware then deadtime=125 should be fine. Deadtimes > 127 require code patch to work properly on H versions but difference between 125 and 150 is barely measurable so there's no real benefit in going that high.

See also the thread under this comment.