First I’d like to thank SolidGeek for his great Firefly remote and all the people in that thread for providing tons of useful information. When I printed the remote, it felt kind of big for my hand since I got used to Ownboard/WowGo remote. So I decided to design a smaller version around Feather M0 RFM69 board. Update: Heltec v2 with the same built-in screen is also suitable, I’m currently re-designing remote to accommodate this board.
Changes:
Bigger battery, up to 1000mAh.
Bigger screen (128x64). Allows seeing speed, distance, battery, and distance at once.
Second page shows throttle, motor amps, and battery amps.
In the bottom half of the remote, there is room for a 51x34x6mm battery. Simply connect a 4.2/3.7V Lipo or LiIon battery to the JST jack. When the USB power is powered, Feather will automatically switch over to USB for power, as well as start charging the battery at 100mA.
I’ve tested the receiver with Flipsky Dual ESC 4.20 and it’s working without a logic level converter.
I am confused. U are talking about sending every 50ms data to the reciever, but don’t include there refreshing display and getting UART Data…
What is your total cycle time between one and another transmission in worst case? If u have Refresh the display AND getting UART data?
Some more thoughts:
u use only one encryption key?! No automatic generated encryption key for each user? No ID for the board handling? U just use one default keys in one remote with all the same boards?SUPER DANGEROUS! U cannot trust people changing this manually.
u have absolute no menu? Nothing to reset or set any values? Nothing to store or restore?
Sorry but this code is definitely not ready to release there are many things inside u need to rework urgently!
I CANNOT SEE ANY WARNING THAT THIS CODE IS DEFINTY IN A SUPER UNSAFE AND ERALY STATE AND NOT FOR DAYLY USE. My code is much further and I ll still not comfortable to release it…
But of course. Still great work. But the way how I released it is not ok. Please overthink this. The remote is a fucking important safety feature…
I didn’t measure it yet, but response feels on par with other “dumb” remotes. I didn’t include duration into frequency. That 50 ms comes from this line of SolidGeek’s code:
if ( millis() - lastTransmission >= 50 )
Getting UART data happens only 4 times per second and potentially while waiting for the next packet of data. I’ve separated drawing and sending buffer to the screen since there is no point of redrawing the same data every 50ms. So, I think the probability of these operations happening at the same time is rather low, but of course, there should be a more optimal way (timers?).
I’ve just removed the default key, now a new random key had to be included to compile the code. Will implement menus and pairing soon, probably before anyone builds this remote
I don’t agree that it’s “super unsafe”, there were no delays or disconnections during my testing (~50 km, up to 40 km/h). But early state for sure
The physical design of the remote is REALLY nice! Nailed it.
The radio and software aspects I am a little skeptical.
915 MHz - 7.8 cm antenna is an interesting choice, its good for going through stuff and long distances but how good is at rejecting noise? I assume that’s all in software, is there any provisions for noise rejection, packet loss, error correction type stuff?
Hmm, are they the long lever type (30mm)? I have a few of the standard switches from a previous Firefly build - I guess I could MacGyver an extension to the lever? Unless you’re up to shipping some out?
Thanks! I’ll update the code in the future to match your RemoteDisplay.cpp file, so it would be easy to change the display and use this mod, for example:
I found that switch in Jaycar store and assumed that it would be easy to get a similar model on Aliexpress, but it’s not the case. The lever size is ~17mm.
The transceiver chip performs CRC check and noise filtering:
SX1231 packet handler performs several packet oriented tasks such as Preamble and Sync word generation, CRC calculation/check, whitening/dewhitening of data, Manchester encoding/decoding, address filtering, AES encryption/decryption, etc. This simplifies software and reduces uC overhead by performing these repetitive tasks within the RF chip itself.
The role of the channel filter is to filter out the noise and interferers outside of the channel. Channel filtering on the SX1231 is implemented with a 16-tap Finite Impulse Response (FIR) filter, providing an outstanding Adjacent Channel Rejection performance, even for narrowband applications.
There are also different modulation types and data rates available:
there are many things inside u need to rework urgently!
