Replies: 1 comment
-
| Just going through your documentation and see that Pi Pico is the only board you have tried so far, so I might have to wait a bit for a port to ESP32. That's not a problem, I have plenty of other stuff to be getting on with. fwiw I have also implemented my project on a Pico using PIO to generate the PPM stream, and it works a treat. The problem with the Pico is the dearth of ADCs. Only three. For a basic transmitter I need at least eight. (And one of my vintage transmitters has no less than fifteen pots...) Got around that with a 16 channel multiplexer connected to one Pico ADC, although I have read that the Pico ADC is not terribly accurate. (Neither are the ESP32 ADCs apparently.) So plan B is to use external 16 bit ADCs connected to the Pico via I2C. Tried that as well and finally got it working after much trauma. So, plenty of options! ;-) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
Seems pretty new here but thought I'd toss in my two cents worth.
My project is a R/C Transmitter for model aircraft, using an off the shelf RF module and home brew encoder (that reads all the controls and builds the output for the RF module to transmit.) Almost all RF transmitter modules for modern transmitters use the 2.4GHz band for communication. The input to these modules is a serial PPM (pulse position modulation) stream that consists of a set of pulses (forming a frame) with the width of each pulse equating to a servo position in the model, with a final, very long, sync pulse at the end. (There is a new breed of communication protocol available called ELRS, that I believe doesn't use PPM but a significantly more complex protocol that I have not yet explored.)
The ESP32 has a very convenient function called RMT that can be used to generate a PPM stream. However, while it is transmitting the stream to the RF module it blocks the processor from doing anything else. In my case, this means that all the analog reads (stick positions, trim levers, analog sliders etc) and digital reads (switches) and the calculation of pulse widths occur in between frames being output, which leads to the last pulse in the frame being the wrong length. I can fudge a workaround for this problem (by shortening the last pulse length) but I find this unsatisfactory, and I'm not sure how sensitive the receiver is to slight variations in frame length.
I'm hoping that by using freertos I can get the ESP32 to do all the reads and calculations to build the next frame while the last frame is being transmitted. Not sure exactly how to do it, but I'm thinking your system might offer a way.
My understanding is that, currently, Micropython does not implement all the freertos features, including access to the second core. So the ability to include C code functionality may be able to overcome that problem.
Thanks, Ian
Beta Was this translation helpful? Give feedback.
All reactions