I want to work with @DroidSector together… we ll decide this in the next days. He is more the good designer than me. Awesome remote design. I am more focused on stability and functions.
The ESTOP workes perfect for me. Never had any fault. Scary to switch off the remote while driving full speed At the moment u have to switch off and on the board again. But i ll implement an option where u can recover from ESTOP (UART must send good values || RMP == 0 for 3 seconds || 10 good tranmissions with trigger at full break… ) something like this.
You should also try it with the thumb wheel because in my case is what makes the standard firefly a bit on the over size for me. On this remote the range of motion of the wheel is a thing, which is great for the smooth throttle, but you need to extend you thumb quite a lot. If you hold it as you do, you could feel not comfortable on full accellaretion. Just my two cents
Have you thought about implementing FHSS (frequency hopping)? Probably not 100% necessary but it’d be a nice addition to the new safety features that you added.
Basically frequency hopping is a software trickery that allows the receiver and the emitter to synchronously “hop” between subfrequencies (for example the 2.4ghz spectrum allows about 100 subfrequencies) tens of times per second.
The main benefits are 1) the probability of 2 devices transmitting on the same set of frequencies is super low; thus even if one freq. is very crowded and packets fail to transmit, there is no problem since the next few milliseconds a new packet will be sent on the next freq.
2) it offers a somewhat second layer of data security: the potential hacker has to know when to hop and to which freq. to read the message you are transferring.
The main programming challenges are: 1)receiver and transmitter have to be synchronized with an error margin of few milliseconds. This could be achieved for example by including in the packets a clock info (adjusted for transmission delay);
2)if you want to have a new set of subfreq. on each reset (for further security) receiver and transmitter have to agree on that too.
This feature would be a huge win for any esk8 remote! I really don’t know how easy it is to run that on arduino type hardwares? I hope someone can figure it out.
I use the GT2B because of this feature. Coming from the RC model world frequency hopping gives you a rock solid connection even in very noisy environments.
Chirp Spread Spectrum was developed for radar applications in the 1940’s. Traditionally used in a number of military and secure communications applications; over the past twenty years this modulation technique has seen increased adoption in a number of data communications applications due to its relatively low transmission power requirements and inherent robustness from channel degradation mechanisms such as multipath, fading, Doppler and in-band jamming interferers.
In LoRa modulation the spreading of the spectrum is achieved by generating a chirp signal that continuously varies in frequency. An advantage of this method is that timing and frequency offsets between transmitter and receiver are equivalent, greatly reducing the complexity of the receiver design.
LoRa modulation is both bandwidth and frequency scalable. It can be used for both narrowband frequency hopping and wideband direct sequence applications. Unlike existing narrowband or wideband modulation schemes, LoRa can be easily adapted for either mode of operation with only a few simple configuration register changes.
The new remote mostly works, but likes to reboot by itself so much Some kind of conflict between radio and display libraries. Migrated to AdaFruit display library and now it’s more stable, more FPS as well. This ESP32 board also has more sensitive inputs, due to 12-bit ADC I think. Overall, it’s harder to develop for, but has greater potential.
Are these results while using the TTGO LORA32?
I decided to go with adafruit for the receiver, will you continue to support that (in as far as you are able to, I mean )
Yes. I’ll continue to test and support all suitable boards. They all use the same libraries for display and radio transmission, so the board-specific code will be minimal.
Spent the whole day looking for the reason of those reboots, turns out ESP32 processor doesn’t like the massive code that RadioHead library has inside an interrupt routine. Had to replace it with LoRa library. Good thing is, now there is like 10 times less code in the radio and display libraries.
Just tested LoRa frequency hopping by putting Feather remote right next to the LoRa one (using the same 915 Mhz frequency). Only 1 packet of 20 was lost every 1 second or so. No packets were lost when I moved the remote 1 meter away.
Basically the only downside of Lora is that it runs on frequencies that are either legal in Europe (800khz) or the US (400khz), but not both. So you’d have to make 2 different designs for the 2 continents.
They also came up with a new chip (sx1280) which runs lora on 2.4ghz (that is fine for US and Europe) but it is more expensive and there arent much modules available.
At the moment u have to switch off and on the board again. But i ll implement an option where u can recover from ESTOP (UART must send good values || RMP == 0 for 3 seconds || 10 good tranmissions with trigger at full break… ) something like this.
That pdf has a lot of interesting info.
Some kind of conflict between radio and display libraries. Migrated to AdaFruit display library and now it’s more stable, more FPS as well. This ESP32 board also has more sensitive inputs, due to 12-bit ADC I think. Overall, it’s harder to develop for, but has greater potential.
)
just waiting on the magnets and I’ll be ready to test.