universal dipole,
use 4x brass tube from 25 cm long + 2 nuts and make 2 or 3 cm M3 inside the tube. In this tube you use 25 cm M3 brass and while turning these around inside the tube you able to tune nearly any frequency you like between 100 - 1000 MHz. the M3 nut is to fix the whole after finish tuning. (sorry english not my native)
Dipole is one of the best antennas to experiment and when vertical its 360 degrees radiation or when use horizontal, you have a small directional pattern
Is the new year started 
Yeah, new year new tasks.
Those dipole usually has excellent performance, could be used for station application. I have seen some professional antenna using this kind of concept, but controlling the internal mechanical tuner by using the bias tee’s DC voltage. Therefore, you could tune the antenna remotely.
Up to now, antenna technology still has been difficult to achieve miniaturization and high performance. The theory has not been broken through, so human beings still need to work hard. 
Got these dipoles, surplus army tuneable in 4 moving parts 25 - 2500 MHz inside is worm-wheel.
Update:
I just received the first batch of samples from the manufacturer for testing, the mechanical strength of this design is very good. It was 3:00AM, I didn’t have the enough energy to set up my Tektronix VNA, so I used the Nano VNA to test the performance of the lora antenna.
The RF model is very accurate due to the precise measurements of the material, PCB/case in 3D. This is the result of the PCB lora antenna without any matching network.
The old problem is still there, the impedance bandwidth is relatively small due to space limitation.
In the end, the design work will be slower than originally planned, as we put a lot of effort into the next high-power version with max TX power 33dBm to 36dBm TBA.
I’m very interested in these.
Options for a larger display, and rotary encoder would be great.
The more user buttons / sensor interfaces you could ‘expose’ the better.
I just wonder, it seems a lot of people interesting in bigger screen, why screen is necessary if the smartphone is required for meshtastic operation? I just did not get the point Did I miss something?
By the way, I was thinking about designing the high power LORA RF front end operations on the FRS channels, which allowed to transmit with 2W power without license or 50W with license. 
I agree with you here.
And more broadly, I often wonder what is the rational behind the line drawn between the “Lora module logic” and the “Client (phone, computer through webui …) logic”.
At first glance, I notice that the client has plenty of computing power, memory, screen space, battery etc. Moreover, programs on Android (or JS) can leverage a lot of libraries, and be developed in higher level language.
The lora module has low computing power, low memory, small or no screen, usually low battery etc. And must be developed in lower level language.
Yet it seems that in the current meshtastic design, the lora module does a lot of the heavy work, and clients are very limited. Again, at first I would have thought that the easiest design would be to have the lora module be “a dumb lora radio accessible through BT/WIFI/USB”, and do the heavy work on the client.
Is there a thread or a page where I can read more about the design decisions behind that please ?
The devices themselves do all the mesh work, the clients are a view into the what the device knows. The device above still has a small OLED screen, the big screen is a NanoVNA device and is just measuring the antenna.
Indeed, this design is visible.
I wonder : why so ? Why this take on the matter, to put as much logic into the device, and therefore as little into the client ? This is surprising, since the client is more powerful on every aspect, and only lacks the LoRa radio.
I have in mind, for instance, the multi-channels on same radio band. The device could be almost agnostic about these questions, it would just broadcast a payload prepared by the client, and the client would do the heavy lifting, encryption, decryption, signatures etc.
Also, that would allow to have multiple clients with multiple identities on the same device, which is not possible AFAIK with the current design. That would make sense, for instance, for a home device used by husband and wife, with their own phones, under their own respective identities.
So, yes, broadly, I am curious what drives the design. 
EDIT : maybe I should move this discussion elsewhere, to leave this thread for Neil and his beautiful work.
The whole point of Meshtastic is the LoRA mesh for long range communications. I honestly don’t get the utility of texting via lora in a house where you likely have cellular and wifi. These devices are mostly used outside.
For current device under the testing stage, it is ported from my previous project lora messenger with manufacturable modification, here this the wiki page for lora messenger project: loramessenger:project [Unit Engineering Wiki]
For the high power edition, I will also create a wiki page for the project once the design work of the prototype has been finished.
Same reason we want more buttons / input, so you can send messages without a phone.
This is indeed the most convenient solution, except balancing BOM cost and international language input can be a problem. Due to the small volume of production, the device will be relative expensive when we have to design it based on Android or Linux.
Having done PCB assembly and inspection for over 5 years, I’d say from a physical standpoint it’s looking great so far. The only important tweaks would be adding thermal relief, probably 4 spoke, on the ground pins of larger parts like U1, the ESP and the internal pins of the USB connector.
The USB shield connections would benefit from no relief (direct connect to ground), and extending the ground pour right up to the board edge, on both sides, stitched with vias for extra mechanical strength. It’s always beneficial for strength to extend the copper under more resist.
Another tweak you might want to make to the ground pour is to ‘cut off’ the corner next to C43 slightly, to give the mounting hardware a little more distance.
From a tinkering standpoint I’d love to see the spare ESP32 pins broken out to through holes, even if only at a 1.27mm pitch.
Also having ground and power on a 2.54mm pitch set of through holes, would be great for streamlining power delivery (hardwired) and reducing risk of damage being caused through the USB connector. In a similar vein it would be nice to have another set of bolt holes as close to the USB connector as possible, for right angle bracing/fixtures.
If any of that is dumb due to RF reasons I defer back to you and apologise for wasting your time reading all that! I’m not an electrical engineer (yet) and don’t I have the brains to even consider becoming an RF one!
I think the best way forward with this could be to use bluetooth keyboards, as they typically have weeks of battery life on a couple of AAs.
LoraWAN devboards with BT are available, and in this case BT could be added as a peripheral of the ESP32. Even without the spare pins broken to dedicated pads, they’re accessible enough from the top with a steady hand!
Personally I think Bluetooth keyboards are a nice option but a poor over all solution. For outside activities it is rather cumbersome.
Using a few on device buttons / rotary encoder selector allow quick responses without really increasing current device sizes and costs.
Would have to be BLE not classic Bluetooth and hid libraries are probably bigger than the firmware can support currently.
Would HID USB keyboard input be a more realistic goal? It would be a tad clunky with a cable but the roll up keyboards are typeable on with gloves (plus a flat surface), it would be compatible with cheap macro pads and enable other custom controllers easily.
I2C keyboard like the CardKB is the most likely option. While it looks like a regular USB port the actual part it is a usb to serial adaptor.
