You can operate it either way.
Most ergonomic shape would be a large 2 finger throttle trigger centered towards the start of the last finger pad (not the tip), long brake trigger at ~45 degrees off vertical.
Relax your hand in midair. Your thumb isn’t in line with the rest of your fingers (on top). The hand default position is with the fingers in a generally circular shape, with the thumb off to the side. It pivots most strongly from the base of the hand, not the individual finger joints.
We basically need a truncated flight stick. Aircraft cockpits and ergonomic computer mice are a great inspiration for this sort of thing.
I enjoy thumb wheels, but i don’t think that motion is ergonomic at all.
6 Likes
I was thinking something more like this (obviously not this, but in general shape). You would hold it and the wheel would be perpendicular instead of forward/back, thus using the natural rolling motion rather than pushing/pulling.
1 Like
I wonder if I can find some already modeled joysticks and just bastardize them enough.
3 Likes
A side rotation wheel is better than a traditional puck-style wheel, but a down-press trigger is the ideal that matches your normal hand grasp movement.
Our most used movement is grasping things to pick them up. Moving your fingers side to side is more rare.
2 Likes
Using that same flight stick as inspiration;
So, what if we staggered the thumb trigger to the inside of your grip, where the 2 button is on that joystick? Would that solve the issues while also possibly being even more comfortable?
4 Likes
I’ve had this thought in mind for a long time now, wanted to design it for a dual trigger remote but haven’t found one good enough to design it for
This one might be my opportunity, I had the concept in my brain already
I’m still waiting for the electronics and everything to be solidified though
4 Likes
Now that I’m actually thinking about the internals, it makes a lot of sense even without looking at the ergonomics(which are also good)
1 Like
I was thinking about that today.
Also found this model.
Which looks like it might work. The limiting factor in these tends to be the pcb, and the kinematics for the triggers. If there is an off the shelf trigger that can be bought, or even a linear switch, it would make life a lot easier. I don’t know what switch is used in handheld cordless drills, but that is pretty much exactly what I’m looking for.
4 Likes
Something like this. It’s cheap enough, but I don’t think it will play nice with the voltages we are dealing with.
2 Likes
Slimmed it up, fixed the trigger. Is this what y’all were thinking about for a thumb brake? It’s obv not finished, but positioning and such.
5 Likes
if you ask me its done when the electric would fit just into the grip of this joystick. That would be awesome. I wouldnt change anything, even the knob like botom part could be a slide puck, and the upper front could get a flashlight. Button break with thumb. One button and or two button power brake
2 Likes
yeah, awesome.
This is EPIC!
Yet again another Champ taking things to a new level!
Said it before but have to say it again! ^ ^ ^
3 Likes
Have been looking through the project, looks awesome so far.
A few comments, note that I don’t have a huge amount of experience so could totally be missing things.
I noticed that the LoRa module is using the explicit header (default set up in setupLoRa()). Since there is only fixed size packets you could try using the implicit packet length with
setPacketParams(12, LORA_PACKET_FIXED_LENGTH, 255, LORA_CRC_ON, LORA_IQ_NORMAL, 0, 0);
That will reduce the time on air for the packet from 2.74ms → 2.34ms for no real loss.
What is a good target for time on air? The datasheet for the semtech sx1280 shows you can increase the sensitivity by adjusting bandwidth and spreading factor at the cost of time on air. If a remote can operate well with a larger time on air the increased sensitivity might help dropouts a lot. For example increasing the spreading factor from 7 → 8 results in an increase in sensitivity of 3dBm but increases the time on air from 2.74ms->5.48ms. You said you had the throttle update down to 50Hz so maybe just need a time on air under 20ms?
Last one, have you considered encrypting the packets at all? In its current for the receiver has no method to check for malicious packets. Someone could read the Identity off a transmitted packet and then transmit packets containing 100% throttle or something else bad. Maybe not a likely outcome but worthwhile considering.
You could also use the encryption key for preventing collisions without transmitting an identity in the packet. The receiver could decrypt an incoming packet with its own key and then check whether the packet makes sense (correct range of throttle, or maybe have a known first byte for the packet) and reject any that don’t since they weren’t encrypted with the same key. The main downside here is that both receiver and transmitter need to know the key which could either be baked into the code like the identity is currently or handed off during pairing.
12 Likes
Very valid points and I will definitely try to minmax the LoRa settings to strike the best balance between time on air and sensitivity. Haven’t had dropouts at all though, but making it even more robust can help folks in noisier areas.
Yeah, pairing and encription is very much the biggest TODO at the moment. Ideally I don’t want to bake anything into the firmware and have a dedicated “neutral” channel where unpaired tx/rxs can exchange the required information, but I haven’t had the chance yet to put some time into it.
Thanks for taking the time to look at the code! This is how this project gets better for everyone.
9 Likes
Yep, there is probably an ideal point but it might take some experimentation to find.
Makes sense not to bake anything in, but does unfortunately increase the amount of code that needs to be written.
No worries, its all very interesting so I’m happy to help
4 Likes
IMO full encryption and decryption is overkill.
It would be sufficient to simply use public key signing (or whatever it’s called) and a checksum to verify that:
- The packet came from the correct/expected transmitter
- The packet didn’t get muddled along the way.
Signing should be sufficient because at the end of the day who cares if someone reads the packets we are sending back and forth? All we need to do is verify their authenticity and integrity before doing anything with the data.
I wouldn’t mind researching and throwing together a proof of concept if this seems like a reasonable solution.
2 Likes
I like it! Just remember that we are short on RAM, CPU cycles and in some cases program memory 
2 Likes
You mean I can’t just tell azure that I need more memory when it starts running low? lol
This is the primary reason I suggested we skip full encryption and go for trust instead.
4 Likes