I encode the packet type identifier into the packet ID sequence field achieving "two birds" with one stone...
Currently I am evaluating the interrupt driven capture of the ppm stream from the RC TX (from the trainer port) and what impact this has on the integrity of the flow of the data to the RF TX pin. I want to make certain that the system is not compromised by the processor servicing the interrupt and being unable to service the Manchester encoded TX stream in a timely manner. Maybe it's as simple as enable interrupts, capture ppm stream, turn off interrupts, transmit 27MHz packet, rinse and repeat as any additional ppm stream received will not be used until next 27MHz transmission...
On the hit list to include in the project
- Telemetry to allow evalution of what is going on inside the sub - especially RSSI, dropped packets, chechsum errors
- Some form of dynamic antenna tuning (ATU) - lots of ideas to trial from my SWL days 50 years ago (how time flies). Servo controlled air spaced cap(s) - or suggestion from SubJohn to use a Varicap
- Failsafes - low voltage, lost comms, some sort of intelligence around compromised packet sequence (>x), checksum errors (>y)
- Review size of primary control parameters (8,10,16 bit or mix) with regards to efficieny vs. control resolution
I am playing with the ideas of using either a direct WiFi RF link back to shore for telemetry realising that the associated antenna (whip) may interfere (+ or -) with the 27mhz RX or perhaps using a "light" comms link from the sub to a model boat of the water which then relays the telemetry back to shore via RF
I have also wondered about the merits of having a "repeater" model boat communicating with the sub. Second (first controls boat manoeuvres) 2.4GHz link to boat, boat repeats transmission to sub on 27MHz |458MHz | xxMHz using onboard TX with antenna slung underneath hull...