On thinking about it I realise that there is already a TELEMETRY command for switching it on and off so it would need to be called something else, BTELEM for Beacon Telemetry or something like that.
I don't know how hard it would be, but if you had the ability to add an optional path to the command you could then request a telemetry packet and have that packet digied back to you via your selected path. Something like BTELEM <path>. Without the optional parameter it would default to the path set in the active profile. But just to have the ability in the scripting to send the telemetry by itself would be a great leap forward.
It sounds so easy when you don't have to write the code!
Just dreaming Scott, no pressure!!
--- In firstname.lastname@example.org, "tkomljan" <tkomljan@...> wrote:
> I have to agree. I've experienced the same issue resulting in perhaps 70% loss of TELEmetry packets. The beacon and telemetry packets cannot be sent sequentially without some random pause in between, or if I understand Mal, separate the two and let beacon and telemetry operate on independent timers.
> --- In email@example.com, "vk6mt" <vk6mt@> wrote:
> > I think the simplest way would be to introduce a' TELEmetry' command that operates just like the `BEAcon' one. A line in the script that looks like:- Exec "TELE", would then do the trick. It would then also be possible to request the Telemety from the OT2 remotely! Is this possible?
> > Mal