Teaser before everything that is hidden under the break:
It is time to spice up the sterile attire.
---------- more ----------
And in order to do that I had to first sketch out ideas and toss them around. Turns out rendering parts of the thing in FreeCAD with transparency and then pasting it all into GIMP allows you to paint different parts without affecting others. Neat!
Now, there are, like, at least three or five methods to make this into reality and since I'm absolutely not confident in my filament swap techniques to print decals in white and then fill the rest with red PLA, I decided to settle on image transfer. Specifically - UV DTF.
But first, gotta make a vector of decals, before sending it to the printing service. A couple of evenings in Inkscape gave me this: And it's off! I was surprised how actually these printing services sometimes can be confused with what you come up to them with. They don't know what Inkscape is, they expect you to give them Adobe Illustrator file or PDF, and even if you do render it - it's not a guarantee that they'll be able to see it properly because.. Idk honestly.
Anyway, UV DTF is a technique where the image is printed on a substrate and then covered with transparent carrier film which you then put on things - and image glues itself on said things, and unlike usual DTF, UV DTF does not require you to heat anything - it just sticks and cures in 24h. They make t-shirt art that way if you're not allowed to heat anything.
It looks something like this: After printing the whoooole exterior in red PLA, the task was to somehow transfer decals on case parts - and also do it with enough precision that holes aren't overlapped and covered just enough and so on so it doesn't look too janky and messy.
You can do it by hand, but it only works for smaller things, whereas bigger decals will stick to your fingers, deform and misalign, and you'll end up with this, straight out of OCD hell: At first I've tried to put it on a stretchy film and then stretch that film over some kind of frame - akin to silkscreen printing but the paint is already there and you have to veeery carefully align everything before doing the final touch. It went like this:
It worked better than doing it by hand, but it turns out that when you cut out bottom of a plastic container - it becomes even more wobbly and you get decal deformation anyway in addition to still present misalignment at times.
So, with the magic of 3x 2020 aluminum extrusions I put together this - an impromptu UV DTF transfer frame: Not only did I get a sturdy frame to stretch the film over, but the frame itself also can stretch the tape even more in both axes - blocks move as well as whole side of the frame, adjusted with corner bolts. And ofcourse, the positioning: ...which is still not the most ideal, because hinged nature of it introduces visual distortion. I also didn't use any reference/alignment points or markers (which I absolutely should have - a keen eye will spot that below), just went and aligned everything visually until it felt mostly alright. But that was enough to get me going: And some things were okay to do by hand: And after a brief reminder of what the deck looked like before and with a glimpse at what it is about to become, we do the dressing ritual. Don't think it was trivial - things were breaking along the way, forgotten test-fit prints failed to fit together, had to adjust this and that and it also required to re-label what was reprinted, wires were snapping all over the place and the thing obviously had to be rewired.
Fine folks at EdgeTX project are spearheading the H5 port base so consistently, I was able to enable DAC driven sound on my port almost fuss-free.
Uses external amp though - but that should be fixed in the next board revision, among othet things.
The project is alive, but power grid situation doesn't allow me to make steady progress - the infrastructure is constantly being damaged, temperatures fall and it's not fun.
It's not an FPV themed deck without something FPV proper, right?
---------- more ----------
A quick little iteration session later, the unit receives an FPV goggles holder caddy, together with cable clips and standard battery strap slots:Mounts instead of the auxiliary display:
Turns the deck into a mess, but keeps stuff together:
The deck got a tripod mount adapter, accepts 3/8 bolt and a thread insert that makes it 1/4.
Sadly i do not have a tripod that is able to hold this thing for long - this macro tripod is only rated for 2Kg max, while the thing can reach north of 2.5Kg itself and even more when with hands on it.
Video chain controls got a rework - lost a bit of identity because of there is no more knob-arrow with a magnetic latch, but it now has an extra LED and the PCB under it now makes much more sense. Plus it integrates a power switch for the whole video chain. The knob itself was moved onto an auxiliary screen as a module - because it supports modules - because i've maid it so. It's also now possible to make it's profile quite flat if you make gimbals foldable and flush switches with panels a bit.
The videochain itself was compacted into one PCB. Still missing 27Mhz quartz for OSD generator, but it switches and it splits and it takes up much less space. Speaking of wiring reorganization - switches are now mounted on separate grouping PCBs that not only make wiring take less space - but also let me forget about recompiling EdgeTX each time i disconnect them and connect back and realize switches now all over the place.
Even gimbals got little wire-gathering PCBs: And finally, i can now select what i want EdgeTX to be connected to - RPi or external USB host - with the magic of a USB multiplexer in a little compartment: A lil mischief with USB descriptors to confirm that it properly enumerates. Pls don't sue me, i have no idea how to do it properly and i do not claim my authorship over anything in OpenTX/EdgeTX codebase and do not plan to sell anything yet with this.
Also some shottky diodes to make it able to turn on without leaking power to other stuff on VBUS.
It has everything I need to more or less evaluate how well the project fares in RC department.
Still some features are missing like voice or working trainer port, but I can control a drone with what's available.
---------- more ----------
I also need to make several changes to PCB and assemble another version of it, but i will postpone it until after i'm done with some of the missing features.
And also do something about how messy it is to wire it now.
Behold how bad I'm at LOS flying
And since it's a full fledged ETX remote, it can act as a simulator controller.
If you hook it up to something that can run the actual simulator, because RPi4 can not and this is why it is connected to a laptop that runs Liftoff.
A bit of an update to keep the log alive, because next ping won't come soon.
With input processor done, project now moves to it's right side - the TX part.
And there are at least two ways to go about it.
---------- more ----------
And both are almost equally tricky:
port Edge-TX firmware onto my board;
write my own thing from scratch;
Porting existing thing will obviously require getting into someone's head, study the source project first, see it's ways, pull a handful of hair, then some more and then maybe, just maybe, it'll just click together and take off.
Pros - I will have a close approximation of a full-fledged remote firmware with all the cool stuff RC kids have - Lua scripting, best gimbal processing practices, audio playback, firwmware updates, existing transmitter protocols support and so on. Cons - ports are not trivial. At all. At best I'm looking at a 2+ months endeavor, no less, and most of this path I will have no idea if the board is correct, or should I respin it like I like to do sometimes.
I mean, sure, there will be a basic firmware to test if chips work and if the circuit itself is sound, but Edge-TX expects some things are done in certain way, and it may (and will) happen that whatever I did might not be compatible with those expectations - e.g. I already sorta see the key matrix on an IO expander might not fit well in input subsystem of the project.
That is not to mention that the project is structured radically different to what I'm used to in my simplistic playarounds.
Writing my own TX firmware, on the other hand has lower upfront cost, but It's a laborious process nonetheless, and just like with former case - it's another 3+ month of work, but even then I will have to borrow protocols implementations from other projects and so on. Only to be greeted in the end with a "bare minimum" that is needed to run a simple ELRS transmitter to control a vehicle with uncustomizable gimbal aspect.
Not ideal either.
Just when I thought it's over, comes a time to dig even deeper, but the bottom feels reachable now.
It's been a while. The input processor firmware has been more or less shaped up, some things still need work, but at least I do not have to keep this board on my table for now.
---------- more ----------
As soon as new boards arrived (had to rework connector cluster part) and were put to the test, it turned out, RP2040 module I used for that sample had a short on LDO output - which meant that sample had to be thrown away.
But after month and a bit more, the firmware now has:
- Working, widget-based GUI with various system settings.
- Basic input processing for SBC: joystick controllable mouse, clusters of keys that are bound to important key combinations.
- Configurable key chords: 3 macro buttons that can generate up to 3 key strokes (like Alt+F4, Ctrl+Alt+Del etc.) for more shortcut opeartions.
- Mission timing features: stopwatch with lap and countdown timer.
- RGBW torch with static "just light" and animated effects.
- PWM control: configurable, but now only supports 50 hz servo control and 3 adjustable duty cycle presets.
- OSD injection into main CVBS chain. Currently only shows mission timing stuff.
Kinda hard to demonstrate all this, and overall 2 months of time do not feel like much progress was made - so hopefully next time i will have something cooler to show.
Oh and i'm kinda settled on the name - it's ESC.VTOR ("escape vector"). Gotta come up with a sick logo or something.
It's a bit disappointing when it took a lot of time to do things but these things sort of can't be shown clearly because they are not visually significant and quite messy.
More after the break.
---------- more ----------
Those input boards were put together and inside their respective case places, like this primary screen part:
And that left part with some more modules, including all the wiring between input boards and input processor: No proper firmware for the input processor yet, but i did a little test that schematic is correct and soldering was done properly.
Then it was about the analog video signal chain: Cramming it all together inside, adding power distribution boards: I had to remake the frontal sidepanel that houses frontal connectors. It is now a split part and that eliminates the awkward process of installing or removing connectors for service: Back connector panel also got some attention (again), this time for the sake of ease of connector service. I now do not have to desolder or cut anything, just pass the grounding ring and the nut through the slots and fasten everything up: Since I have to also connect stuff to RPi, these things were made. Later i've added some JST connectors: Trying to put everything inside for tests: And it mostly works. Except that UVC issue and multiplexer behaves funny when second signal is connected - probably due to some overshoots.
Now i can write a proper firmware for input processor, but first it is paramount to move that analog video chain onto a separate PCB because i really do not dig how ugly it all looks when packed.
Some eRr Gee Bee action to make things fresh. Everything else below the break.
---------- more ----------
Small stuff first: aux screen connector panel was rearranged a bit to fit a USB to both provide 5v power and signalling to all the accessories that can be mounted on that screen. In hopes that it will be enough.
The boards are here. Some of them. I completely forgot about axis trim groups and will order them later with another thing I will mention below. Here they are in different state of being assembled: Putting together transmitter connector, I was a bit nervous because I had no idea if everything was done right position wise, but in the end it all fits together after a dance or two:
Still no idea if it works though. Interface distances are much longer than i'd like but what can you do - I iterate more than contemplate at this point.
And that said "iteration over contemplation" brought in an oversight. Turns out I completely forgot about adding actual holes over "documented" circles that supposed to mark where they should be. Oh well, got an order above anyway and work can be split i guess. Life is kind of too short to drill it by hand. Some case changes. This left case part was kinda boring so it was spiced up a bit with a WS2812 array window and a mounting point for a pushbutton with flip up cover. Magnets included!.
And here how it looks from the inside: Printing new framing was surprisingly hard, because new panels added a lot of holes in them and it only means more walls and small fill polygons on bottom and top layers, and that, in turns, adds a ton of frequent retractions - this contributes to heat creep and hotend clogs much, much more often than i'd consider normal. Even when it prints in 17C environment.
I've switched to FreeCAD v1.0 and to be honest - I'm not entirely on board with many changes. Some are welcomed, other are a mixed bag. Constraint solver seems to have become much smarter, but overall perfomance and it's proclivity to do recalculations even on a newly opened project that consists only of historyless bodies leave a new patch to be desired. And i'm not even talking about it's inability to migrate exact projects that i was working on with v0.21 - it sees weird feature attachment points and dies, bringing the project with it. I guess i can start wiring stuff now and bring up HID functionality for that basic input action?